New answers tagged

0

To avoid the problem in the future, turn on sync_binlog. What is happening is that the replication stream had not yet gotten to the Slave when the Master shutdown. The offset into the binlog had been bumped up, but the data was not on the Slave. After coming up, move to the next binlog and set the position to 0 (or 4, either one works).


0

It seems that setting the position to 4 (master_log_pos=4) has reignited the sync.


-1

Since your other slaves are running fine, this is possibly caused by user error. Some row was probably changed on this slave manually, which was meant to be changed on the master. The slave then encounters something like duplicate key constraint 10 times and fails. If the transaction causing this error is slow or it effects a lot of rows combined with ROW ...


0

pg_rewind connects to the new master and locates the latest checkpoint it shares with the old master. Then it examines local WAL to find all blocks that have been modified since and copies these blocks from the new master. So the procedure is slow if promotion happened a long time ago, so pg_rewind has to dig through many WAL files or many blocks have ...


Top 50 recent answers are included