ERROR during WAL replay
От | Gurjeet Singh |
---|---|
Тема | ERROR during WAL replay |
Дата | |
Msg-id | 65937bea0801122044xf3159b3qf5689f92e9e1b93b@mail.gmail.com обсуждение исходный текст |
Список | pgsql-hackers |
Hi All,
We were trying to move a big database from one machine to the other using PITR mechanism. We hit the following LOG message in during the recovery (WAL replay) process"
LOG: incorrect resource manager data checksum in record at 111/A7738C8
I had used this procedure to do such migrations in the past, and never had any problem. This particular DB is pretty huge, and under load, so I would like to consider other options before even trying to redo the whole process.
Here's the whole scanario:
The DB is about 420 GB in size. We want to move it to another box with more storage. I have set up WAL archival, executed pg_start_backup(), started $DATA/ copy (took just over 24 hours), executed pg_stop_backup(), and while the WAL archival is still enabled I started recovery on the second machine, using the $DATA/ copied earlier....
I have the compressed WAL file, so if someone wishes to take a peek at it it will be available...
Considering this is a weekend, any help/suggestion at all would be great.
Thanks and best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad
18° 32' 57.25"N, 73° 56' 25.42"E - Pune
37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco *
http://gurjeet.frihost.net
Mail sent from my BlackLaptop device
We were trying to move a big database from one machine to the other using PITR mechanism. We hit the following LOG message in during the recovery (WAL replay) process"
LOG: incorrect resource manager data checksum in record at 111/A7738C8
I had used this procedure to do such migrations in the past, and never had any problem. This particular DB is pretty huge, and under load, so I would like to consider other options before even trying to redo the whole process.
Here's the whole scanario:
The DB is about 420 GB in size. We want to move it to another box with more storage. I have set up WAL archival, executed pg_start_backup(), started $DATA/ copy (took just over 24 hours), executed pg_stop_backup(), and while the WAL archival is still enabled I started recovery on the second machine, using the $DATA/ copied earlier....
I have the compressed WAL file, so if someone wishes to take a peek at it it will be available...
Considering this is a weekend, any help/suggestion at all would be great.
Thanks and best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad
18° 32' 57.25"N, 73° 56' 25.42"E - Pune
37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco *
http://gurjeet.frihost.net
Mail sent from my BlackLaptop device
В списке pgsql-hackers по дате отправления: