Google Cloud SQL 複製延遲
我們有一個在第二代 MySQL 5.6 上寫入數據的項目
master 的寫入行為：平均每秒 70 次寫入操作。事情是每天2次，應用程序每次寫入數據3個小時。他們每個人每秒寫入 2500 次操作。
我相信這種寫操作會導致永無止境的複制延遲。一旦複製延遲開始，就無法恢復。增加副本的源（cpu 和記憶體）不起作用。
我應該怎麼做才能使副本同步？我認為主/從架構不是這種寫操作的解決方案。
我應該使用更大的主來進行讀寫操作而不是主從嗎？
謝謝你。
目前主控：4cpu 15gb ram 和 900gb ssd
目前副本：8cpu 30gb ram 和 900gb ssd
編輯
就像在單個事務中插入 50k 一樣。複製是基於行的。可以批量插入。儘管主數據庫中存在其他數據庫，但所有操作都進入單個數據庫。升級到 5.7 是可能的。
我正在嘗試創建一個外部只讀副本，因為由於超級權限而無法設置全域變數。正如您所描述的，我將為多執行緒複製和 innodb_flush_log_at_trx_commit 增加並行工作人員。
另外我會嘗試最大允許的數據包。延遲的副本被銷毀。所以下面的狀態和變數代表主控。
我已經看到這種情況在 Amazon RDS 中經常發生。當 Master 被大量寫入敲擊並且它們被序列化到一個 I/O 執行緒時，基於行的複制會發生這種情況。
您應該做的是動態更改以下內容：
SET GLOBAL innodb_flush_log_at_trx_commit = 2;問題是您需要超級權限，Amazon RDS 和 Google CloudSQL 都不允許。對於 Amazon RDS，您可以更改數據庫參數組（MySQL 實例的伺服器選項列表）中的值。如果您可以通過 Google CloudSQL 平台中的某個選項組更改動態選項，這就是更改的選項。當複制趕上備份時，更改回 1。
如果您在 CloudSQL 實例中有多個數據庫， Rick James 發布的答案會很棒。他說
所有操作都進入一個數據庫？任何升級到 5.6 以上的機會；多執行緒複製可能會有所幫助。
現在嘗試更改動態選項以擺脫目前的複制滯後，並嘗試他建議使用 MySQL 5.7 並將多執行緒複製設置為長期解決方案。
（評論問題太多了）
讓我們看
SHOW CREATE TABLE一個範例操作。可能會有一些線索。大批量是如何進行的？一次寫入一次事務？還是在單個事務中插入一百萬次？還是介於兩者之間？
基於行的複制？創新數據庫？
可以“批量”插入嗎？或者是
LOAD DATA嗎？所有操作都進入一個數據庫？任何升級到 5.6 以上的機會；多執行緒複製可能會有所幫助。
雖然不太可能有任何值得調整的可調參數，但如果您可以為每台伺服器提供這些可調參數，它可能會提供更多線索（包括回答上述一些問題）。（使用 post.it 或其他網站；它們不適合這裡。）
SHOW GLOBAL STATUS; SHOW GLOBAL VARIABLES;