我們的 MySQL 主伺服器分配了 24GB 的 RAM（innodb_buffer_pool_size = 24GB），但是很好奇是否有一些標準數量可以分配給複製從屬伺服器？

現在從伺服器只是用來進行轉儲而不在主伺服器上鎖定表，理論上如果發生某些事情（在過去的 18 個月內沒有出現），它可以用作緊急主伺服器。如果主伺服器失敗，我總是可以快速分配從伺服器 24GB，但是從伺服器真正需要多少才能坐在那裡進行複制？

記憶體量應該相同，配置應該相同（除了只屬於主/從的配置）。

原因是當您進行故障轉移時，您不想花時間試圖找出應該存在或不存在的值。我什至會創建 2 個 my.cnf 文件：my.cnf和my_failover.cnf（準備my.cnf在 Slave 上，以防 master 失敗。文件可以包含binlog=1（打開 bin 日誌）。

您需要做的就是：

• mv my.cnf mybk.cnf, my my_failover.cnf my.cnf
• 重啟Mysql。

然後你的奴隸將開始登錄。

關於記憶體查詢，在 Master 上執行的所有 Select 語句都不會復製到 Slave。如果你的 Master 是 80% Select / 20% write，那應該不是問題。

如果您想記憶體您的從主伺服器中選擇，請打開慢查詢日誌以進行查詢 > 1 秒，然後將其應用於從伺服器。你可以每天做一次（早上）。

很有可能，很快您將使用您的奴隸進行報告。

你也可以使用Percona Playback。

它應該具有相同數量的 RAM。實際上，它應該具有相同的硬體配置。

原因如下：

MyISAM 鍵記憶體、InnoDB 緩衝池和查詢記憶體不會填充相同數量的數據。自然，Master 將在其記憶體中載入更多數據。

如果您必須故障轉移到 Slave 才能成為新的 Master 怎麼辦？你會得到一些人所說的CACHE STORM。在這種情況下，您使用 Slave 並期望您在 Master 上執行的查詢現在在 Slave 上執行。這是 Storm 部分：如果 Slave 在其記憶體中沒有所需的記憶體數據，它必須花時間從磁碟讀取它。對於奴隸來說，這簡直是殘酷的。

建議

我會在 Slave 上使用mk-slave-prefetch。它的作用如下：它將讀取所有中繼日誌，將 INSERT、UPDATE 和 DELETE 轉換為 SELECT，然後執行 SELECT。這將強制 Slave 上的 mysqld 使用所需的數據頁和索引資訊填充 MyISAM 鍵緩衝區和 InnoDB 緩衝池，使 Slave 上的記憶體盡可能類似於 Master 上的相同記憶體。

這個工具你安裝在 Slave 上，每分鐘執行一次。當您故障轉移到 Slave 時，Master 中 95% 以上的記憶體將在 Slave 上（除非 Slave Lag）。

您可能想知道為什麼我會使用 MAATKIT 而不是更高級的Percona Toolkit。Percona 沒有在 Toolkit 中包含mk-slave-prefetch 。點擊此處下載 mk-slave-prefetch。

我以前討論過這個

• Aug 20, 2011: MySQL 為大量 SELECTs/INSERTs/UPDATEs/DELETEs 提供高性能
• Sep 27, 2011: mysql 複製主控(ServerFault)
• Jan 17, 2012:從從屬伺服器恢復崩潰的 MySQL 主伺服器(ServerFault)

好處

您有實施的好處mk-slave-prefetch

1. 您的從站將準備好進行故障轉移，並且在初始使用時不會遭受記憶體風暴。
2. 您還可以將其用作讀取從屬設備，以通過在主設備和從設備之間使用負載平衡讀取 VIP 來減少主設備上的讀取 I/O。
3. 它可以幫助加快 Slave 上所有其他操作（報告、審計等）的查詢

警告

具有數據冗餘的高可用性設置適用於平衡的硬體。MySQL Cluster、Percona XtraDB Cluster、Schooner 和 Oracle RAC 的使用者通常在每台伺服器上都有相同的硬體配置。任何具有 less 自動功能的伺服器都會使該伺服器成為集群中最薄弱的環節。

對於 MySQL Master/Slave，如果 Slave 只是用於報告和備份，可能沒有問題。一旦您需要 Slave 進行報告和備份之外的任何事情，升級硬體以使 Master 和 Slave 完全相同是絕對必須的。

試一試 ！！！

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