Add docs for sync replication
This adds documentation for enabling sync replication in the
HA tutorial.
@@ -198,6 +198,41 @@ If it returns `true` (or `t`), then the Postgres instance is a primary!
What if PGO was down during the downtime event? Failover would still occur: the Postgres HA system works independently of PGO and can maintain its own uptime. PGO will still need to assist with some of the healing aspects, but your application will still maintain read/write connectivity to your Postgres cluster!
+## Synchronous Replication
+
+PostgreSQL supports synchronous replication, which is a replication mode designed to limit the risk of transaction loss. Synchronous replication waits for a transaction to be written to at least one additional server before it considers the transaction to be committed. For more information on synchronous replication, please read about PGO's [high availability architecture]({{<relref "architecture/high-availability/_index.md" >}}#synchronous-replication-guarding-against-transactions-loss)
+
+To add synchronous replication to your Postgres cluster, you can add the following to your spec:
+
+```yaml
+spec:
+ patroni:
+ dynamicConfiguration:
+ synchronous_mode: true
+```
+
+While PostgreSQL defaults [`synchronous_commit`](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT) to `on`, you may also want to explicitly set it, in which case the above block becomes:
+
+```yaml
+spec:
+ patroni:
+ dynamicConfiguration:
+ synchronous_mode: true
+ postgresql:
+ parameters:
+ synchronous_commit: "on"
+```
+
+Note that Patroni, which manages many aspects of the cluster's availability, will favor availability over synchronicity. This means that if a synchronous replica goes down, Patroni will allow for asynchronous replication to continue as well as writes to the primary. However, if you want to disable all writing if there are no synchronous repliacs available, you would have to enable `synchronous_mode_strict`, i.e.:
+
+```yaml
+spec:
+ patroni:
+ dynamicConfiguration:
+ synchronous_mode: true
+ synchronous_mode_strict: true
+```
+
## Affinity
[Kubernetes affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) rules, which include Pod anti-affinity and Node affinity, can help you to define where you want your workloads to reside. Pod anti-affinity is important for high availability: when used correctly, it ensures that your Postgres instances are distributed amongst different Nodes. Node affinity can be used to assign instances to specific Nodes, e.g. to utilize hardware that's optimized for databases.
