|
Here's what I'm trying to do in testing 9.2Beta1. The current configuration is a master and a hot standby at a diverse location for both hot swap and "online" backup. Both are archived regularly so if something goes south I can recover (to either as a master.) I am attempting to validate the path forward to 9.2, and thus tried the following: 1. Build 9.2Beta1; all fine. 2. Run a pg_basebackup from the current master machine (running 9.1) to a new directory on the slave machine, using the 9.2Beta1 pg_basebackup executable. 3. Run a pg_upgrade against that from the new binary directory, producing a 9.2Beta1 data store. 4. Attempt to start the result as a SLAVE against the existing 9.1 master. Everything is ok until I try to start the result as a slave. I would think I should be able to, since this is exactly the procedure (minus the upgrade) that I used to get the slave in operation in the first place (although I did the archive/dump/copy to the slave machine manually rather than use "pg_basebackup" to get it.) But the last step fails, claiming that "wal_level was set to minimal" when the WAL records were written. No it wasn't. Not only was it not on the master where the base backup came from, it wasn't during the upgrade either nor is it set that way on the new candidate slave. Is this caused by the version mismatch? Note that it does NOT bitch about the versions not matching. For obvious reasons I'm not interested in rolling the production master up to 9.2 until it's released, but running a second instance of my HA code against it as a slave would allow me to perform a very complete set of tests against 9.2Beta1 without any hassle or operational risks, yet keep the full working data set available and online during the testing. Do I need to run a complete parallel environment instead of trying to attach a 9.2Beta1 slave to an existing 9.1 master? (and if so, why doesn't the code complain about the mismatch instead of the bogus WAL message?) -- |
