Question

We use Postgres as database for our project and found that streaming replication fit our needs which works asynchronous. We have one server in write only mode (MASTER) and others in read only (SLAVES).

In most cases we send data to MASTER and forget about it. But sometimes we want to be sure that current chunk is synchronised between master and slave before continue. For new rows (INSERTS) it is trivial, script can check is new row appeared by simple SELECT query. But for UPDATEs it becomes problem.

So, is there any simple and legal way to check does slave catch up master or not? I know that every record should have own internal id but not sure that it will be the same between servers.

We use Postgres 9.2 with very similar configuration described in this great article.

Answer 1

So, finally I found solution by myself. So far postgres stores all changes is special log files, and then replicates changes over slave servers. Same time postgres has rich set of API methods that allows to read state of different internal processes. So in the end I use this queries:

-- On MASTER server current xlog location:

SELECT 
  pg_xlog_location_diff(pg_current_xlog_location(), '0/0') AS offset;

-- On SLAVE server current offset of received and applied changes

SELECT 
   pg_xlog_location_diff(pg_last_xlog_receive_location(), '0/0') AS receive,
   pg_xlog_location_diff(pg_last_xlog_replay_location(), '0/0') AS replay;

Getting this values from MASTER and SLAVE I can decide how big difference is between servers. And when I need to be sure that both servers are in the same state I can wait till offset on SLAVE becomes equal or bigger than on MASTER.

Probably this query can also be handy if you have the same problem:

-- Check is current server in cluster

SELECT 
  pg_is_in_recovery() AS recovery;

-- False — server is MASTER
-- True — server is SLAVE