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

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

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

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

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

我們在這里需要兩個(gè)腳本：

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

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

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

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

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

關(guān)于MySQL中怎么維護(hù)主從信息的元數(shù)據(jù)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。