Synchronous replication, network protocol
| От | Heikki Linnakangas |
|---|---|
| Тема | Synchronous replication, network protocol |
| Дата | |
| Msg-id | 4951108A.5040608@enterprisedb.com обсуждение исходный текст |
| Ответы |
Re: Synchronous replication, network protocol
Re: Synchronous replication, network protocol |
| Список | pgsql-hackers |
The protocol between primary and standby haven't been discussed or documented in detail. I don't think it's enough to just stream WAL as it's generated, so here's my proposal. Messages marked with "(later)" are for features that have been discussed, but no one is implementing for 8.4. The messages are sent like in the frontend/backend protocol. The handshake can work like in the current patch, although I don't think we need or should allow running regular queries before entering "replication mode". the backend should become a walsender process directly after authentication. Standby -> primary RequestWAL <begin> <end>Primary should respond with a WALRange message containing the given range of WAL data. StartReplication <begin>Primary should send all already-generated WAL beginning from <begin>, and then keep sending as it's generated. ReplicatedUpTo <end>Acknowledge that all WAL up to <end> has been successfully received and written to disk and/or fsync'd (depending on the replication mode in use). The primary can use this information to acknowledge a transaction as committed to the client in case of synchronous replication. (later) OldestXmin <xid>When a hot standby server is running read-only queries, indicates the current OldestXmin on the standby. The primary can refrain from vacuuming tuples still required by the slave using this value, if so configured. That will ensure that the standby doesn't need to stall WAL application because of read-only queries. (later) RequestBaseBackupRequest a new base backup to be sent. This can be used to initialize a new slave. Primary -> standby WALRange <begin> <end> <data>Response to RequestWAL or StartReplication message. After receiving a StartReplication message, the primary can send these messages when it feels like it. In synchronous mode, that would be at least at each commit. The standby should respond with a ReplicatedUpTo message to each WALRange message. (later) BaseBackup <data>A base backup, in response to RequestBaseBackup message. For example, in .tar.gz format. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: