Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
>> We are investigating the possibility of using DRBD to perform >> synchronous replication of our PostgreSQL database server. After >> reading the Replication modes section of the DRBD features >> documentation we concluded that we would need to use protocol C, which >> is describes writes to be considered complete only after both the >> local and the remote disk writes have been confirmed. However, during >> our testing we were able to continuously write to the primary device >> after disabling network traffic on the secondary. > >http://www.drbd.org/users-guide/s-node-failure.html > >> We also noticed that during high write loads on the primary the >> number of kilobytes out of sync would grow, but eventually the >> secondary would catch up. > >Only when in disconnected mode. And then after the connection is restored, you resync: >http://www.drbd.org/users-guide/s-resync.html > >> After reading the documentation, we were surprised at the testing results. > >Um, sorry, you seem to not have reviewed the documentation in sufficient detail. :) > >> Is this expected and/or correct behavior, or have we incorrectly >> configured something for the DRBD device? > >Perfectly expected. > >Now, if you're looking for PostgreSQL HA, the alternative to DRBD is obviously to use Postgres synchronous replication, available since 9.1. Also integrated with Pacemaker. Since that option forgoes >DRBD, though, a discussion of that option would be off-topic for this list, and if you're interested in pursuing that option I'd encourage you to take this discussion to the Pacemaker or linux-ha >mailing list. Thanks for the links. After re-reading them it sounds like protocol C is synchronous when in a connected state, otherwise it suspends replication until the connection is restored, and it then performs a resync. Thanks again, -- Nathan.