您好,登錄后才能下訂單哦!
這篇文章給大家介紹MySQL中怎么維護主從信息的元數據,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
1.***個維度是單點實例,單點實例是那些測試環境,數據流轉節點或者業務優先級不高的業務。這些業務允許數據丟失,甚至允許環境重建,有一個基本的備份即可,這類的業務我們首先剝離出來,后面處理的時候就可以可以繞過這些節點,比如對于這些節點來說,可能不需要備份,可能不需要每天備份,壓根不需要增量備份,binlog備份,按照這個規劃,做了這些信息確認之后,后期要完成的備份恢復就有據可依,要不費了半天勁,***發現業務優先級不高,做事情的性價比就大打折扣。
2.第二個維度是數據庫角色,數據庫的角色其實不能嚴格意義上歸類為Master,Slave,其實可以有更多的類型,比如單點業務,我們可以歸類為SingleDB,如果是中繼節點(show master status或者show slave status持有雙重角色),我們可以歸類為RelayDB,如果是主庫或者是從庫即為Master,Slave,如果屬于MHA或者MGR的集群環境等,其實這個角色可以更加清晰,對于這部分信息我們需要做減法,即MHA或者MGR的環境,這類信息可以歸類為集群信息,我們可以對其他的信息按照SingleDB,RelayDB,Master,Slave這四個維度來統計即可。
要實現這個功能,就有一些技巧需要補充了。
我們在這里需要兩個腳本:
1)通過IP和端口信息得知實例的角色(Master,Slave,RelayDB,SingleDB等)
2)通過Slave和RelayDB的信息來得到Master的信息,亮點也就在此,通過這些信息我們可以清晰的達到一個復制關系圖,甚至可以看到一些意想不到的問題。
比如下面的IP信息,數據庫角色是中繼節點RelayDB(既是Master又是Slave)
我們根據IP的后兩段內容搜索得到下面的一個基本列表。
這樣一個關系,如果自己來刻意維護,其實很容易就會迷茫,或者意識不到這種級聯關系的存在,但是我們對這些數據進行抽象,就很快能夠得到這樣的餓一個關系圖,原來是這樣的一個級聯關系。這樣一來124.16這個中繼節點的角色和上下游的關系就很清晰了,那么從這個角度來看,我們是否需要對124.76做數據的備份就很容易得出結論了。
關于MySQL中怎么維護主從信息的元數據就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。