基於 LVM 快照的 MySQL 複製設置——我忘記了什麼嗎?
我的任務是啟動客戶端 MySQL 5.7.35 數據庫伺服器的全新副本。雖然我過去曾在各種情況下觀察過其他人這樣做,但我以前沒有負責過這項操作,所以我想確認我的計劃是正確的,並且我沒有遺漏任何重要的事情。
數據位於 XFS 格式的 LVM 邏輯卷中,位於具有足夠可用空間以啟用 LVM 快照的捲組內。
該數據庫是 MyISAM 和 InnoDB 表的遺留混合體,目前大小超過 200 GB。副本伺服器設置了相同的 MySQL 版本,並且所有基於行的 binlog 複製的先決條件(副本使用者、伺服器 ID
log_bin
等)都是有序的。我的流程是這樣的:
- 在主伺服器上,執行
FLUSH TABLES WITH READ LOCK
. 保持客戶端會話打開。
- 根據Percona的說法,在執行時嘗試防止長時間執行的
SELECT
查詢處於執行過程中很重要,因此我們將努力確保這一點。
- 在另一個客戶端會話中(不知道為什麼,但文件是這樣說的),執行
SHOW MASTER STATUS
以獲取 binlog 文件名和位置。- 從 MySQL 數據卷創建 LVM 快照。(不包含二進制日誌或中繼日誌。)
- 在原來的 MySQL 客戶端會話中,執行
UNLOCK TABLES
恢復正常執行。- 將快照 (
-t xfs -o nouuid
) 和rsync
其中的數據目錄掛載到(關閉的)副本伺服器上——不包括auto.cnf
自動生成的.pem
文件(我們不使用 SSL 連接到 MySQL,因此它們應該不是特別重要)。- 解除安裝和
lvremove
快照。- 在副本上啟動 MySQL 並按照 MySQL 文件中所述執行正常的 binlog 複製初始化步驟,為步驟 2 中的值提供
MASTER_LOG_FILE
和MASTER_LOG_POS
選項CHANGE MASTER
,然後等待副本趕上。我已經在無流量登台伺服器上測試了這個過程,但我主要關心的是
FLUSH TABLES WITH READ LOCK
實際的生產實例。是否足以防止長時間執行SELECT
,還是我需要注意其他一些危險?當鎖定到位時,任何嘗試寫入的客戶端自然會失敗,但目標是在 30 秒內完成步驟 1-4,這對我們來說是可以接受的部分中斷。此外,由於我們正在執行混合的 MyISAM 和 InnoDB,是
FLUSH TABLES WITH READ LOCK
我們需要做的所有事情,還是其中一個引擎需要更多的東西來確保一致的 LVM 快照?
FLUSH TABLES WITH READ LOCK 就足夠了。這會鎖定表,防止新的寫入,並確保對錶的任何其他寫入都刷新到 MyISAM 表的磁碟捲。對於 InnoDB 表,一些更改可能仍在緩衝池中,但這些更改也由 InnoDB 重做日誌記錄,因此當您啟動副本時,這些更改將自動恢復(這與 InnoDB 崩潰恢復相同) .
在讀鎖期間使用 SHOW MASTER STATUS 是必要的,因為您需要這些座標用於副本上的 CHANGE MASTER 命令。它基本上類似於書籤,因此副本知道從哪裡開始讀取二進制日誌。
聽取有關長時間執行查詢阻塞 FLUSH TABLES WITH READ LOCK 的建議仍然很重要。任何查詢,甚至是只讀 SELECT,都會在表上持有元數據鎖。但是 FTWRL 不需要在任何表上持有元數據鎖,至少是短暫的。因此,長時間執行的 SELECT 將阻止 FTWRL。您可以在 MySQL 的測試實例上做一個實驗來證明這一點:
在一個視窗中,創建一個 MyISAM 表:
mysql> create table test.m (i int) engine=myisam; mysql> insert into test.m values (42);
以持續一段時間的方式查詢它:
mysql> select sleep(120) from m; (hangs)
在第二個視窗中,嘗試 FTWRL:
mysql> flush tables with read lock; (hangs)
FTWRL 正在等待該查詢完成,因此 FTWRL 可以在元數據鎖處自行處理。如果該查詢需要很長時間才能完成,FTWRL 仍將等待,並且任何其他查詢將排隊等待 FTWRL 釋放其對所有表的元數據鎖。
Percona 在他們的 MySQL 版本中添加了一個特性來幫助解決這些情況。它是在備份期間使用的鎖,不會受到這種阻塞行為的影響。如果您有興趣,請閱讀https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/了解詳細資訊,但如果您使用主流 MySQL,則不會有這個功能。
鑑於您有 InnoDB 和 MyISAM 表的混合,LVM 快照方法是一個非常好的解決方案,因為鎖定可以非常簡單地完成,只要足夠長的時間來獲取 LVM 快照並讀取 MASTER STATUS。
我習慣用Percona XtraBackup,不需要加鎖,只要數據庫只儲存InnoDB表即可(mysql系統表除外,它們很小,所以在短暫讀取時備份不成問題鎖)。我傾向於堅持所有表都儲存在 InnoDB 中。MyISAM 性能較差,容易受到數據損壞的影響。