>> 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. _______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
