It never fails that when on “FAA Data Reload Day” (which occurs every 56 days on the ICAO cycle), I manage to screw something up and end up staying up late. It doesn’t matter how early I start.
Today’s screw up was after loading the data, I realized that I’d done something wrong, and needed to restore the database to the state it was before I started the load. For reasons too complicated to go into here, I load the data on my home Linux box, and then scp it up to my colo box where the web site lives. The database that lives on my home box doesn’t have all the same tables as the one on my colo box, just the tables that are important to data loading.
So, I thought, the easiest way to get back to the data as it was before the data load is to upload the script I use to export the appropriate tables on the home box to the colo box, run it there, copy the file back to the home box and load it. Except after I loaded it, I noticed a distinct lack of data on my home box. As a matter of fact, it appears that the load went way too fast, like it had no data at all. A quick look at the export file confirmed that there wasn’t any data in it, just some table deletion and creation stuff. Oh oh.
That’s when I realized that one of the consequences of having different versions of PostgreSQL on the two boxes was that “pg_dump … -t waypoint -t comm_freqs -t runway…” works on my home box, but not on the colo. Not thinking too straight, I then used a ‘for table in …” command to run pg_dump on each table individually. When I copied them home, I discovered that this messed up the foreign keys rather badly. So I tried to manually stitch all the files together. That wasn’t working very well, because I had things in the wrong order and the foreign key stuff still wasn’t right.
That’s when it suddenly hit me. Duh. The whole reason I have an external drive on my machine is so that I can do hourly rsync backups. I have a copy of the postgis.dump file that I copied over 56 days ago. As a matter of fact, I have dozens of copies of it. The only reason I was avoiding it was because I had done a few small manual modifications to the database since then. But those were still in the history buffer of psql, and so they were easy to reproduce. I restored the backup, made the changes at around 10:45, ran the updates again, and now here it is at 11:30 and everything is finally done.
I just hope this doesn’t happen again in 56 days, although I’m sure it will.