Ok, thanks to @GeethaThatipatri-MSFT for helping me get to the bottom of this. It turns out the PITR actually worked just fine. And I learned an important lesson for the future:
The azure hostname has to be changed in two places when cutting over to restored machine from a backup.
Example:
I started with a db on a VM called mariadb-abu-dev
, intentionally deleted some data, then spun up a restored machine called mariadb-abu-dev-recover2
.
The mistake I made was forgetting that Azure requires you to specify a connection user as user@server
So, when connecting to the "restored" machine, I connected using:
mysql \
-h mariadb-abu-dev-recover2.mariadb.database.azure.com \
-u abuadmin@mariadb-abu-dev \
-p
Note that the -h host is correct, but the -u user has the wrong machine name.
In reality, I had created environment variables for all of this, so my actual connection command looked like this:
mysql -h $DB_HOST -u $DB_USERNAME -p
making it even harder to see what I had done wrong.
In future, the $DB_HOST needs to be changed (as I had done). And, the back-end of the user should have been changed -- (in this case, making it abuadmin@mariadb-abu-dev-recover2). The correct way to connect would have been:
mysql \
-h mariadb-abu-dev-recover2.mariadb.database.azure.com \
-u abuadmin@mariadb-abu-dev-recover2 \
-p
Geetha and the team that looked into it said that:
...adding the @Testta to the end of my overall user, it is able to essentially 'override' what client thinks is the server provided in the user name...
I'm sure there are scenarios where this is helpful -- for me, it ended up being a footgun.
In sum, it's a straightforward fix, but it's yet another example of the danger of "multiple sources of truth", and something we'll have to be very careful of in production.
Thanks again to Geetha and the folks who helped sort this out!