同步同步和負載平衡 InnoDB 數據庫的最佳解決方案是什麼
我正在嘗試找到最佳設置來水平擴展目前位於單個專用伺服器上的電子商務，但即使閱讀了 DBA 上的一些回复，我仍然對什麼是我的案例的最佳解決方案感到困惑。同步應該是同步的（我認為但我在這裡可能錯了）並且它將與 HAproxy 集成以進行負載平衡（HAProxy 還將管理 WWW 負載平衡，這就是我提到它的原因，但是如果我必須使用 MySQL Router o SQLProxy 那就是也可以）。我還需要在所有 MySQL 實例之間進行相同的自動增量程序（更多見下文，在 M\M 部分中）。最後，如果任何節點出現故障，應該很容易恢復。
這些是我通過Google搜尋找到的選項：
- MySQL 複製 M/M
- MySQL 複製/組複製
- Percona XtraDB 集群 / Galera
- MySQL NDB
MySQL 複製 M/M
我過去使用過這個，但我在使用 auto_increment_increment/offset 設置時遇到了問題，導致訂單/購物車/等 ID 不連續。AFAIK 它不能配置為同步複製。也不是最專業的解決問題的方法，有很多缺點。
MySQL 複製/組複製
我不完全理解兩者之間的區別，除了後者似乎有更好的方式來管理/控制集群。但這似乎可以完成我需要的工作。如果我理解正確的話，在 rpl_semi_sync_source_wait_for_replica_count 等於 MySQL 實例數量的半同步模式下使用它就像在同步模式下執行一樣。那是對的嗎？另外，我對 Single o Multi Primary Mode 有點困惑。我認為每個實例都必須是 RW，所以 MultiPrimary，如果我還想平衡寫查詢。或者最好有一個單一的主 RW 節點並僅重定向輔助節點上的讀取查詢（如果 HA 可能的話，我不知道）？
Percona XtraDB 集群 / Galera
這看起來像一個組複製，具有附加功能和管理工具，使其更容易，可能表現更好。如果我理解正確，這裡會強制執行同步模式，以獲得更高的一致性。我不太確定與 MySQL 相比還有什麼不同，這是我困惑的一部分。
MySQL NDB
我讀到這是同步複製的最佳解決方案。但是，我不知道它是否可以安全地與使用 InnoDB 編寫的 PHP 應用程序一起使用。我知道我可以使用 NDB 引擎重新導入整個 InnoDB 數據庫，但它與我可以在 InnoDB 上執行的任何 MySQL 查詢兼容嗎？這是我最大的疑問。我不想在 NDB 上移動一切，以便以後發現我無法做某事，甚至更糟糕的是我的應用查詢中的錯誤。
所以，我在這裡，對於為我的案例選擇最佳選項充滿疑問，因為這是我無法撤消的選擇。我希望我沒有忘記任何有用的知識。任何 DBA 專家都可以幫助我做出正確的選擇嗎？謝謝。
NDB 是您提到的唯一支持水平可擴展性的解決方案。也就是說，部分數據駐留在每個節點上，所以你擁有的節點越多，寫入容量就越大。
其他都是複制類型，因此每個節點都有自己的完整數據集副本。您可以通過將讀取查詢委託給副本來獲得一定程度的讀取可擴展性，但前提是讀取查詢能夠容忍複製滯後。
沒有完全同步的複制解決方案。每一步之間總是有延遲：你更新一行，然後事務送出並寫入二進制日誌，然後二進制日誌由副本下載，然後副本對自己的副本重放更改。如果數據庫可以強制每個步驟同步，那麼應用程序客戶端將必須等待所有操作完成，然後才能更新行返回。對於大多數應用程序來說，這將是一個交易破壞者。
您知道有半同步，但這並不能確保副本上的寫入已完成，只能確保副本已收到日誌。無法保證將日誌應用到副本上需要多長時間，在這種情況下，延遲甚至可能增長到數小時。我也不建議在長網路（即跨區域）上進行半同步，因為網路可能會降級或中斷，這會導致主節點上的事務送出被阻止。
Galera 解決方案可以選擇強制讀取查詢等待複製滯後趕上。這與同步寫入不同，它可能導致讀取查詢出現意外延遲。
InnoDB Cluster 監控複製延遲，如果延遲超過 1 秒，則阻止對集群的進一步寫入，直到副本趕上。
您沒有列出的另一個解決方案是 PlanetScale 的 Vitess 和相關產品。該解決方案確實具有水平擴展功能，並且可以解決您提到的許多痛點。
所有水平擴展或“分片”數據庫（NDB、Vitess）都有一個必要的缺點：由於數據是拆分的，因此可以通過到達一個節點來解決的查詢與需要解決的“扇出”查詢之間存在很大差異到達許多節點。有必要仔細設計您的數據拆分策略，以便您需要最高效的查詢一次只能從一個節點獲取結果。這在關係數據庫中可能相當複雜，並且在某些情況下沒有乾淨的解決方案（例如多對多表）。
這意味著，將現有數據庫設計為假設所有數據位於同一位置，並將其簡單地上傳到分片數據庫基礎設施並期望它表現良好，幾乎永遠不會成功。
唯一的準則是TANSTAAFL。每個解決方案都有其優點和明顯的缺點。由您來選擇一個解決方案，它的優點對您的項目很重要，並且其缺點不會因您的需要而破壞交易。
您尚未描述您的工作負載，例如事務速率、讀寫比率、數據庫大小、查詢延遲要求。您也沒有描述您需要多大的可擴展性：數據增長率和流量增長率、地理分佈、客戶端數量等。這些都是選擇解決方案的重要因素。
我建議您要麼需要使用測試數據庫嘗試每個解決方案，以了解它們如何滿足您的需求，要麼您需要聘請數據庫性能顧問來完成這項工作。
InnoDB Cluster（使用 MySQL 8.0）或 Galera（最好使用最新的 MariaDB 版本）
M/M（Primary-Primary）是HA和縮放的部分解決方案；鑑於上述選擇，不值得考慮。
NDB 適用於小眾應用。可以為非 NDB 解決方案提供幫助的人要多幾個數量級。
對於 HA，計劃在 3 個不同的地理位置中的每個位置至少擁有一台伺服器。
然後，您需要在各種路由機制中進行選擇。
此外，使用慢日誌找出可以加快哪些查詢。這有助於您是否進行物理縮放。
簡單複制可以“無限”擴展，但用於擴展讀取，而不是寫入。
分片
一些（不是全部）應用程序可以通過在每台伺服器上擁有一些使用者來輕鬆擴展。想想 WordPress、Flickr 等。一個分片（單個伺服器或 HA 集群）處理部分使用者子集，並且大部分獨立於所有其他分片。
使用此解決方案，您可以將現有使用者留在現有伺服器上。為接下來的一百個客戶提供類似的配置。當它變得“滿”時，旋轉另一個。任意讀寫縮放。