大型插入會導致 3 節點 MySQL 數據庫集群崩潰嗎？

我們有一個 3 節點 MySQL 數據庫集群，而不是在 Percona 上執行。我有一個儲存過程，可以一次插入很多行，可能超過一百萬行。

我（我們的 DBA）已經警告過這可能會導致集群崩潰，但我在網上找不到任何關於這個或暗示這可能會發生的資訊。

誰能提供一些見解？

一些一般性的考慮，首先：

1. MySQL，我特別是在談論 InnoDB，針對 OLTP 負載進行了優化，特別是針對點 SELECTS 和寫入的良好性能。這並不意味著您不能進行批量插入（我在我的桌面級 SSD 上每秒插入 600 000 行），但這會影響其他操作的性能，主要是通過在事務中獲取額外的鎖和額外的資源處理/索引合併/等。
2. 當通過網路在緊密的集群解決方案（對於 MySQL 模型）上分發這些事務時，大型事務處理成本會加劇。您必須在多個節點上同步載入大量行的事實通常需要大量記憶體，這使得它們成為 NDB 和 Galera 等緊密連接節點解決方案的問題。

現在進入 Galera 細節：

• 您將面臨的第一個限制是預設情況下ws_max_size_rows為 128K（128 000 行）並且wsrep_max_ws_size為 1GB。儘管這些值是可配置的，但如果事務大於配置的值，載入過程將直接失敗。
• 我不會對集群可能崩潰感到驚訝 - 您可以在此處看到一個在導入期間發生的範例 - 最終有 2 個節點獲得 OOM，即使該特定問題後來得到修復。為了在實際執行之前驗證所有節點之間的每筆交易，需要額外的記憶體。
• 如果您希望集群充分工作，我建議使用多個事務分塊載入文件。有類似的事件工具[pt-fifo-split][1]可以幫助您做到這一點。作為替代方案，您可以在每個節點上單獨載入這些文件，同時它們暫時不同步。

這是一個不應該爭論的問題——如果你有一個生產集群，你應該有一個測試集群，你可以先在其中嘗試你的論文。最好的情況下，您將獲得可怕的性能/死鎖。通常，您將耗盡記憶體並且 1+ 個節點將崩潰，從而導致整個集群崩潰。

要了解更多關於 galera 行為背後的原因，以及如何以犧牲性能為代價避免停機，您應該閱讀：

• Percona XtraDB Cluster for MySQL 中的 Galera 流控制
• Galera：在大量事務上使用過多的記憶體
• http://www.percona.com/forums/questions-discussions/percona-xtradb-cluster/10106-xtradb-limitations-wsrep-max-ws-size-and-wsrep-max-ws-rows

引用自：https://dba.stackexchange.com/questions/97286