diff options
Diffstat (limited to 'design-documents/011-auditor-db-sync.rst')
-rw-r--r-- | design-documents/011-auditor-db-sync.rst | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/design-documents/011-auditor-db-sync.rst b/design-documents/011-auditor-db-sync.rst index fb2e3bea..71d0762a 100644 --- a/design-documents/011-auditor-db-sync.rst +++ b/design-documents/011-auditor-db-sync.rst @@ -1,5 +1,5 @@ -Design Doc 011: Auditor-Exchange Database Synchronization -######################################################### +DD 11: Auditor-Exchange Database Synchronization +################################################ Summary ======= @@ -62,7 +62,7 @@ Proposed Solution ================= * Use "common" incremental database replication (whichever is - approproate for the exchange database setup, synchronous + appropriate for the exchange database setup, synchronous or asynchronous) to make a 1:1 copy of the exchange database at the auditor. This should work for any full-featured modern database. This "ingress" copy cannot be trusted, as constraint @@ -89,9 +89,9 @@ Proposed Solution * The auditor's "ingress" database should be well isolated from the rest of the auditor's system and database (different user accounts). The reason is that we should not - assume that the Postgres replication code is battle-tested with + assume that the PostgreSQL replication code is battle-tested with malicious parties in mind. -* The canonical Postgres synchronization between exchange and the +* The canonical PostgreSQL synchronization between exchange and the auditor's "ingress" database must use transport security. The above solution does not gracefully handle mutable tables on which @@ -148,10 +148,10 @@ A good order for replicating the tables should be: Alternatives ============ -* Copy the Postgres WAL, filter it for "illegal" operations +* Copy the PostgreSQL WAL, filter it for "illegal" operations and then apply it at the auditor end. Disadvantages: WAL filtering is not a common operation (format documented?), - this would be highly Postgres-specific, and would require + this would be highly PostgreSQL-specific, and would require complex work to write the filter. Also unsure how one could later recover gracefully from transient errors (say where the exchange recified a bogus DELETE). |