All Scheduled Transactions Disappear

[John Ralls]

> On Dec 23, 2016, at 9:15 PM, John Ralls <jralls at ceridwen.us> wrote:
> 
>> 
>> On Dec 23, 2016, at 7:52 PM, aeneas <receiver at gowdygroup.net> wrote:
>> 
>> John,
>> 
>> I've done some programming with MySQL databases which includes the use of
>> transactions (multiple SQL statements) that are subsequently either
>> "committed" or rolled back".  However, this refers to logic built into the
>> program.  I'm not familiar with the idea of rolling back a database
>> administratively.  Possibly you are referring to the idea of restoring a
>> full backup of the database and then finding the newest one without any of
>> the tables with "_back" suffixes (i.e., your reference to foo_back tables). 
>> If you have something different in mind I'd be grateful for some
>> elaboration.
>> 
>> I should point out that most of the tables in the current DB have mates with
>> the "_back" suffix.  Based on your explanation that causes me to think that
>> the problem may not be confined to my scheduled transactions.  In that, is
>> the whole DB corrupted?
>> 
>> I haven't created my own backups.  This is something that I generally rely
>> on my hosting service to undertake.  I'll have to check with them regarding
>> restoration options but I doubt they're running MySQL backups.  Theirs would
>> likely have to be at the filesystem level.
>> 
>> I have noticed that as the DB has grown the bandwidth limitations on my
>> Internet service are suspected of severely slowing down response times.  I'd
>> be inclined to think that service interruptions are also quite possible
>> which seems, to me, like it might fit with your explanation.
>> 
> 
> Yes, it seems likely that your whole database is corrupted. 
> 
> I don't actually know what facilities MySQL provides for undoing commits. "Roll back" was perhaps a poor choice of words because it has that meaning in the context of a database transaction. If restoring from a backup is the only choice then that's what you have to do. Relying on your hosting service for that without making quite sure that they're doing it and testing the backups periodically was a poor decision on your part. I do hope that they can come through for you.
> 

It occurred to me that you have another option: First, make sure that all of the tables come in plain and foo_back. If they do you can drop the plain tables and rename the foo_back tables to foo. That will restore the database to its condition immediately before the full save. You may have to redo a bit of work if you've made any changes since the failed full save. For absolute safety you may want to save the database to a local XML file before doing anything to it.

Regards,
John Ralls