2010-09-20 22:08:53 +02:00
|
|
|
src/backend/replication/README
|
2010-01-20 10:16:24 +01:00
|
|
|
|
|
|
|
Walreceiver - libpqwalreceiver API
|
|
|
|
----------------------------------
|
|
|
|
|
|
|
|
The transport-specific part of walreceiver, responsible for connecting to
|
2011-03-10 14:59:59 +01:00
|
|
|
the primary server, receiving WAL files and sending messages, is loaded
|
|
|
|
dynamically to avoid having to link the main server binary with libpq.
|
|
|
|
The dynamically loaded module is in libpqwalreceiver subdirectory.
|
2010-01-20 10:16:24 +01:00
|
|
|
|
2011-03-10 14:59:59 +01:00
|
|
|
The dynamically loaded module implements four functions:
|
2010-01-20 10:16:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
bool walrcv_connect(char *conninfo, XLogRecPtr startpoint)
|
|
|
|
|
|
|
|
Establish connection to the primary, and starts streaming from 'startpoint'.
|
|
|
|
Returns true on success.
|
|
|
|
|
2010-03-24 07:25:39 +01:00
|
|
|
bool walrcv_receive(int timeout, unsigned char *type, char **buffer, int *len)
|
2010-01-20 10:16:24 +01:00
|
|
|
|
2010-03-24 07:25:39 +01:00
|
|
|
Retrieve any message available through the connection, blocking for
|
|
|
|
maximum of 'timeout' ms. If a message was successfully read, returns true,
|
|
|
|
otherwise false. On success, a pointer to the message payload is stored in
|
|
|
|
*buffer, length in *len, and the type of message received in *type. The
|
|
|
|
returned buffer is valid until the next call to walrcv_* functions, the
|
|
|
|
caller should not attempt freeing it.
|
2010-01-20 10:16:24 +01:00
|
|
|
|
2011-03-10 14:59:59 +01:00
|
|
|
void walrcv_send(const char *buffer, int nbytes)
|
|
|
|
|
|
|
|
Send a message to XLOG stream.
|
|
|
|
|
2010-01-20 10:16:24 +01:00
|
|
|
void walrcv_disconnect(void);
|
|
|
|
|
|
|
|
Disconnect.
|
|
|
|
|
|
|
|
|
|
|
|
This API should be considered internal at the moment, but we could open it
|
|
|
|
up for 3rd party replacements of libpqwalreceiver in the future, allowing
|
|
|
|
pluggable methods for receiveing WAL.
|
2010-01-15 10:19:10 +01:00
|
|
|
|
|
|
|
Walreceiver IPC
|
|
|
|
---------------
|
|
|
|
|
|
|
|
When the WAL replay in startup process has reached the end of archived WAL,
|
|
|
|
recoverable using recovery_command, it starts up the walreceiver process
|
|
|
|
to fetch more WAL (if streaming replication is configured).
|
|
|
|
|
|
|
|
Walreceiver is a postmaster subprocess, so the startup process can't fork it
|
|
|
|
directly. Instead, it sends a signal to postmaster, asking postmaster to launch
|
|
|
|
it. Before that, however, startup process fills in WalRcvData->conninfo,
|
2011-03-10 14:59:59 +01:00
|
|
|
and initializes the starting point in WalRcvData->receiveStart.
|
2010-01-15 10:19:10 +01:00
|
|
|
|
|
|
|
As walreceiver receives WAL from the master server, and writes and flushes
|
2011-03-10 14:59:59 +01:00
|
|
|
it to disk (in pg_xlog), it updates WalRcvData->receivedUpto and signals
|
|
|
|
the startup process to know how far WAL replay can advance.
|
|
|
|
|
|
|
|
Walreceiver sends information about replication progress to the master server
|
|
|
|
whenever either it writes or flushes new WAL, or the specified interval elapses.
|
|
|
|
This is used for reporting purpose.
|
2010-01-15 10:19:10 +01:00
|
|
|
|
|
|
|
Walsender IPC
|
|
|
|
-------------
|
|
|
|
|
|
|
|
At shutdown, postmaster handles walsender processes differently from regular
|
|
|
|
backends. It waits for regular backends to die before writing the
|
|
|
|
shutdown checkpoint and terminating pgarch and other auxiliary processes, but
|
|
|
|
that's not desirable for walsenders, because we want the standby servers to
|
|
|
|
receive all the WAL, including the shutdown checkpoint, before the master
|
|
|
|
is shut down. Therefore postmaster treats walsenders like the pgarch process,
|
|
|
|
and instructs them to terminate at PM_SHUTDOWN_2 phase, after all regular
|
|
|
|
backends have died and bgwriter has written the shutdown checkpoint.
|
|
|
|
|
|
|
|
When postmaster accepts a connection, it immediately forks a new process
|
|
|
|
to handle the handshake and authentication, and the process initializes to
|
|
|
|
become a backend. Postmaster doesn't know if the process becomes a regular
|
|
|
|
backend or a walsender process at that time - that's indicated in the
|
|
|
|
connection handshake - so we need some extra signaling to let postmaster
|
|
|
|
identify walsender processes.
|
|
|
|
|
|
|
|
When walsender process starts up, it marks itself as a walsender process in
|
|
|
|
the PMSignal array. That way postmaster can tell it apart from regular
|
|
|
|
backends.
|
|
|
|
|
|
|
|
Note that no big harm is done if postmaster thinks that a walsender is a
|
|
|
|
regular backend; it will just terminate the walsender earlier in the shutdown
|
|
|
|
phase. A walsenders will look like a regular backends until it's done with the
|
|
|
|
initialization and has marked itself in PMSignal array, and at process
|
|
|
|
termination, after unmarking the PMSignal slot.
|
|
|
|
|
2011-03-10 14:59:59 +01:00
|
|
|
Each walsender allocates an entry from the WalSndCtl array, and tracks
|
|
|
|
information about replication progress. User can monitor them via
|
|
|
|
statistics views.
|
2010-01-15 10:19:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
Walsender - walreceiver protocol
|
|
|
|
--------------------------------
|
|
|
|
|
|
|
|
See manual.
|