MariaDB KB 上關於“轉換為 Galera 的提示”的問題
關於轉換為 Galera的優秀寫作技巧的一些問題。
“跨域寫作”是交叉連接數據中心的寫作嗎？
此外，您應該在適當的地方使用“START TRANSACTION READONLY”。
這意味著事務將僅由一個節點處理（無複製延遲）？。是否存在
SELECT不START TRANSACTION READONLY涉及多個節點的情況？SELECT標記它是閱讀？交易“規模”
（本節假設您在多個 colos 中有 Galera 節點。）由於討論了一些問題，明智的做法是將您的 write 語句分組為中等大小的 BEGIN…COMMIT 事務。每個 COMMIT 或自動送出都有一個延遲命中。因此，組合語句將減少這些命中。另一方面，進行大型事務（例如在單個事務中插入/修改數百萬行）是不明智的（出於其他原因）。
這是最大交易規模嗎？是否建議使用接近最大事務大小？你能給出一個值，你的意思是中等大小的 BEGIN…COMMIT 交易嗎？
MariaDB [(none)]> select @@wsrep_max_ws_size; +---------------------+ | @@wsrep_max_ws_size | +---------------------+ | 1073741824 | +---------------------+ 1 row in set (0.00 sec)批判性閱讀
這是一種“簡單”（但不是“免費”）的方法，可確保即使來自不同的連接，讀寫後也能看到更新的數據。
什麼時候應用需要使用後讀？寫後讀的案例是什麼？但無論如何，這種先讀後寫應該在同一個事務中？請提供更多關於 read-after-write 以及何時使用它的資訊。
可能需要不同的變數 (…) （使用 FusionIO 或其他保證原子性的驅動器，OFF 更好。）
什麼是殘頁？我用我的母語翻譯，現在更加困惑。
Miscellany (…) DROP USER 可能無法複製？
還有更多細節和資訊嗎？我們使用自動化
DROP USER幾年以來從未發現過問題。我們只是沒有看到問題嗎？
（我想我最好回答這個問題。）
“colo” = “co-location” = “datacenter”——意味著節點之間的延遲非常重要。
SELECT ... FOR UPDATE應該在一個事務中。一個你想在一個節點上做一些事情而不打擾其他節點的例子：你需要計算一堆東西來把數據
INSERT放到一個表中。但是您很樂意在單個節點上進行計算，而不必擔心節點崩潰。例如，您可能有一些其他機制可以從崩潰中恢復。想想“冪等性”。“交易規模”——嗯，應該說“交易需要多長時間才能執行”。在某種程度上，大量的行被修改會使它花費更長的時間，但這並不是“大小”的唯一原因。
太大——跨節點死鎖的可能性更大。太小 - 做跨節點更多的努力和延遲
COMMIT。關鍵閱讀：使用者在部落格上寫評論，然後點擊送出。下一頁出現，但未能顯示該評論。為什麼？寫入到一個節點；讀取去了另一個節點，但它還沒有到達那裡。（這可能是 Galera 不聲稱完全同步的唯一現實例子。gcache 中的檢查只檢查“它是否會成功送出”，而不是“它是否已經寫入磁碟”。）
“撕裂的頁面”——一個 innodb 數據單元是一個 16KB 的塊。典型的磁碟以 512 字節塊為單位進行思考。如果 InnoDB 的塊完全寫入或根本不寫入，則可以從電源故障中恢復。但如果只寫入部分（N*512，但小於 16K），則它是“殘頁”。因此，InnoDB 以“雙寫緩衝區”為先，以便能夠從中恢復。這涉及大量的 I/O。但是，由於 Galera 可以完全恢復當機，如果您願意在斷電後重建節點，則可以允許損壞頁面。
DROP USER涉及數據庫中的 MyISAM 表mysql。MyISAM 表被（或曾經）不被複製。我懷疑 Galera 已經確保它DROP USER有效。然而，由於所有的GRANT東西都涉及到 MyISAM，我懷疑在某些情況下它可能會失敗。（MySQL 8.0 將GRANT內容移動到 InnoDB 表中，從而使其具有崩潰安全性。）感謝您指出文章中的缺陷。我將嘗試改進http://mysql.rjweb.org/doc.php/galera和您提供的 MariaDB 連結。（某天）