MySQL中怎么維護主從信息的元數(shù)據(jù)

144次閱讀

共計 1073 個字符，預(yù)計需要花費 3 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章給大家介紹 MySQL 中怎么維護主從信息的元數(shù)據(jù)，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

1.*** 個維度是單點實例，單點實例是那些測試環(huán)境，數(shù)據(jù)流轉(zhuǎn)節(jié)點或者業(yè)務(wù)優(yōu)先級不高的業(yè)務(wù)。這些業(yè)務(wù)允許數(shù)據(jù)丟失，甚至允許環(huán)境重建，有一個基本的備份即可，這類的業(yè)務(wù)我們首先剝離出來，后面處理的時候就可以可以繞過這些節(jié)點，比如對于這些節(jié)點來說，可能不需要備份，可能不需要每天備份，壓根不需要增量備份，binlog 備份，按照這個規(guī)劃，做了這些信息確認之后，后期要完成的備份恢復(fù)就有據(jù)可依，要不費了半天勁，*** 發(fā)現(xiàn)業(yè)務(wù)優(yōu)先級不高，做事情的性價比就大打折扣。

2. 第二個維度是數(shù)據(jù)庫角色，數(shù)據(jù)庫的角色其實不能嚴格意義上歸類為 Master,Slave，其實可以有更多的類型，比如單點業(yè)務(wù)，我們可以歸類為 SingleDB, 如果是中繼節(jié)點（show master status 或者 show slave status 持有雙重角色），我們可以歸類為 RelayDB, 如果是主庫或者是從庫即為 Master,Slave, 如果屬于 MHA 或者 MGR 的集群環(huán)境等，其實這個角色可以更加清晰，對于這部分信息我們需要做減法，即 MHA 或者 MGR 的環(huán)境，這類信息可以歸類為集群信息，我們可以對其他的信息按照 SingleDB,RelayDB,Master,Slave 這四個維度來統(tǒng)計即可。

要實現(xiàn)這個功能，就有一些技巧需要補充了。

我們在這里需要兩個腳本：

1）通過 IP 和端口信息得知實例的角色（Master,Slave,RelayDB,SingleDB 等）

2）通過 Slave 和 RelayDB 的信息來得到 Master 的信息，亮點也就在此，通過這些信息我們可以清晰的達到一個復(fù)制關(guān)系圖，甚至可以看到一些意想不到的問題。

比如下面的 IP 信息，數(shù)據(jù)庫角色是中繼節(jié)點 RelayDB（既是 Master 又是 Slave）

我們根據(jù) IP 的后兩段內(nèi)容搜索得到下面的一個基本列表。

這樣一個關(guān)系，如果自己來刻意維護，其實很容易就會迷茫，或者意識不到這種級聯(lián)關(guān)系的存在，但是我們對這些數(shù)據(jù)進行抽象，就很快能夠得到這樣的餓一個關(guān)系圖，原來是這樣的一個級聯(lián)關(guān)系。這樣一來 124.16 這個中繼節(jié)點的角色和上下游的關(guān)系就很清晰了，那么從這個角度來看，我們是否需要對 124.76 做數(shù)據(jù)的備份就很容易得出結(jié)論了。