From e9a22d38b366896034630ce6f0afee8b1468d97b Mon Sep 17 00:00:00 2001 From: libing2 Date: Mon, 14 Aug 2023 12:58:24 +0800 Subject: [PATCH] =?UTF-8?q?=E6=98=8E=E7=A1=AE=E8=A1=A8=E8=BE=BE=EF=BC=9A?= =?UTF-8?q?=E9=9C=80=E8=A6=81=E5=A6=82=E4=BD=95=E5=A4=84=E7=90=86=E7=9A=84?= =?UTF-8?q?=E6=98=AF=E2=80=9C=E8=80=81=E4=B8=BB=E5=BA=93=E5=B0=9A=E6=9C=AA?= =?UTF-8?q?=E5=A4=8D=E5=88=B6=E7=9A=84=E5=86=99=E5=85=A5=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ch5.md | 2 +- zh-tw/ch5.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ch5.md b/ch5.md index ad92a08a..bd00136b 100644 --- a/ch5.md +++ b/ch5.md @@ -110,7 +110,7 @@ 故障切换的过程中有很多地方可能出错： -* 如果使用异步复制，则新主库可能没有收到老主库宕机前最后的写入操作。在选出新主库后，如果老主库重新加入集群，新主库在此期间可能会收到冲突的写入，那这些写入该如何处理？最常见的解决方案是简单丢弃老主库未复制的写入，这很可能打破客户对于数据持久性的期望。 +* 如果使用异步复制，则新主库可能没有收到老主库宕机前最后的写入操作。在选出新主库后，如果老主库重新加入集群，又该如何处理这些老主库尚未复制的写入？在此期间，新主库可能已经收到了与老主库尚未复制的写入相冲突的写入。最常见的解决方案是简单丢弃老主库未复制的写入，这很可能打破客户对于数据持久性的期望。 * 如果数据库需要和其他外部存储相协调，那么丢弃写入内容是极其危险的操作。例如在 GitHub 【13】的一场事故中，一个过时的 MySQL 从库被提升为主库。数据库使用自增 ID 作为主键，因为新主库的计数器落后于老主库的计数器，所以新主库重新分配了一些已经被老主库分配掉的 ID 作为主键。这些主键也在 Redis 中使用，主键重用使得 MySQL 和 Redis 中的数据产生不一致，最后导致一些私有数据泄漏到错误的用户手中。 diff --git a/zh-tw/ch5.md b/zh-tw/ch5.md index 5ad94aa4..4f9a6f93 100644 --- a/zh-tw/ch5.md +++ b/zh-tw/ch5.md @@ -110,7 +110,7 @@ 故障切換的過程中有很多地方可能出錯： -* 如果使用非同步複製，則新主庫可能沒有收到老主庫宕機前最後的寫入操作。在選出新主庫後，如果老主庫重新加入叢集，新主庫在此期間可能會收到衝突的寫入，那這些寫入該如何處理？最常見的解決方案是簡單丟棄老主庫未複製的寫入，這很可能打破客戶對於資料永續性的期望。 +* 如果使用非同步複製，則新主庫可能沒有收到老主庫宕機前最後的寫入操作。在選出新主庫後，如果老主庫重新加入叢集，又該如何處理這些老主庫尚未複製的寫入？在此期間，新主庫可能已經收到了與老主庫尚未複製的寫入相衝突的寫入。最常見的解決方案是簡單丟棄老主庫未複製的寫入，這很可能打破客戶對於資料永續性的期望。 * 如果資料庫需要和其他外部儲存相協調，那麼丟棄寫入內容是極其危險的操作。例如在 GitHub 【13】的一場事故中，一個過時的 MySQL 從庫被提升為主庫。資料庫使用自增 ID 作為主鍵，因為新主庫的計數器落後於老主庫的計數器，所以新主庫重新分配了一些已經被老主庫分配掉的 ID 作為主鍵。這些主鍵也在 Redis 中使用，主鍵重用使得 MySQL 和 Redis 中的資料產生不一致，最後導致一些私有資料洩漏到錯誤的使用者手中。