這個周忙的就像打仗一樣，感覺有點被別人牽著鼻子走了，每天都是早出晚歸，干不完的活兒，有時候感覺DBA這碗飯真的不好吃，要有強大的抗壓能力和心理承受能力。今天下午吃飯的時候，真的感覺整個人快要垮掉了，吃完飯就依然決然的下班了，走在路上，看著下班的人群，心想這不就是正常的下班時間么，為什么我還有種早走慚愧的感覺？可能整個人都被洗腦了吧。

這個周的公眾號內(nèi)容更新也是耽擱了兩天，周二那天實在是太累了，就直接休息了。 昨晚要走的時候，大概九點多，工作了一天比較累，然后就大腦不聽使喚，弄了一個故障，把線上一臺環(huán)境的賬號權(quán)限表給刪掉了，然后發(fā)現(xiàn)那套環(huán)境還是個新的，沒有進行備份，我了個蒼天，當時感覺天都快塌了，幸好我平時有保留變更的習慣，在自己的txt文件里面找到了之前給業(yè)務方開過的一些賬號權(quán)限，花了兩個小時給修復了，期間包括測試服務是否可用，同步是否及時等等?；貋硪豢磿r間，已經(jīng)是十一點半了，趕緊抓時間寫公眾號，結(jié)果呢，寫完的時候已經(jīng)零點六分了，就索性沒有更新公眾號。

這種感覺真的很不好，不知道在哪兒看到過一句話，“毀掉一個ITer最好的方式，就是讓他忙到?jīng)]有時間成長”，我現(xiàn)在感覺自己就在這種惡性循環(huán)當中，又想起一個哥們兒給我說過的話，“埋頭給公司拉車的時候，要時不時抬頭看看前方的路。”

希望能夠快速調(diào)整過來，我相信在北漂的人一定有一些跟我相同的感觸，對于忙碌可能大家都有自己的定義，在這一點上我想可能和一些公眾號的觀眾能夠?qū)崿F(xiàn)共鳴^_^。

廢話也說了那么多了，光抱怨也解決不了問題，還是把目光放在當下吧，寫點兒有用的東西，希望對大家有所幫助，也算是自己的一個整理吧。

今天早上去公司，遇到了一個問題，就是報警信息中顯示一個分布式的集群中的一些主從關系down掉了，也就是從庫斷開了，然后查看了一下原因，是因為業(yè)務方和另外一個同事在同時對主庫進行數(shù)據(jù)導入，而這兩個人所做的操作是有依賴關系的，而且都包含大量事務，由于產(chǎn)生了沖突，事務進行了回滾，而從庫上發(fā)現(xiàn)要回滾的數(shù)據(jù)已經(jīng)不存在了，所以就導致了從庫的斷開。

看到這個問題，我先嘗試著修復了一下從庫，因為是使用gtid搭建的主從復制，所以就嘗試著使用set next gtid的方法修復了一下，具體方法可以在gtid那篇文章中看一下，文章在公眾號底部有分類。然后begin;commit;設置自動gtid之后發(fā)現(xiàn)修復好了，但是過了大概五分鐘，就又不行了，很顯然，這個方法不是個長久之計，而業(yè)務方那邊的數(shù)據(jù)還有很多沒有流進來。最終考慮了各種方案之后，不得已而為之，重新搭建從庫。

我查看了一下主庫的數(shù)據(jù)量，大概100G左右吧，我想到的兩種直觀的方法如下：

1、直接備份在服務器上

2、備份在遠程nfs掛載備份機里面

來看這兩種方法，服務器本身沒有那么多剩余的空間可供使用，強行備份也可以，但是會導致磁盤報警，這肯定不是一個好的方法。況且要是使用xtrabackup的方法去搞，apply log和copy back這兩步花費的時間相當長。

再來看遠程nfs備份機，備份機容量很大，解決了磁盤問題，但是遠程傳輸需要的帶寬是無法提供的，如果并行進行備份，那么帶寬肯定是不夠的，并發(fā)的備份進程都會比較慢，保守估計5套主從應該需要8個小時左右。

那么怎么辦呢？這里使用了一種比較粗暴的方法，直接跟業(yè)務方溝通，暫時把服務停了，打通了兩個機器的ssh互信，配置了scp工具，直接通過物理文件拷貝的方式給吧文件復制到從庫去，也不進行壓縮了，因為100G的文件壓縮和解壓需要大量的時間。這樣做的好處有下面幾個：

第一：各個備份之間解耦合，不受其他環(huán)境的影響。

第二：可以通過機器之間的帶寬導入主庫上的原生文件到從庫，能夠保證數(shù)據(jù)的完全一致。

第三：時間比較快

于是就這么做了，大概看了一下，100G的文件scp拷貝的話大概就17分鐘左右，這樣就解決了備份時間長的問題。并行5個窗口，互不影響，也就30分鐘左右，5套環(huán)境的數(shù)據(jù)就過去了?，F(xiàn)在主庫和從庫的數(shù)據(jù)已經(jīng)完全一致了，現(xiàn)在開始搭建從庫，需要做的事情有以下幾個：

1、將從庫中原來的my.cnf文件替換拷貝過來的主庫的my.cnf文件，否則server_id將會重復，導致搭建主從報錯。

2、將從庫中原來的slave-relay-log.index文件拷貝到新目錄下面，否則搭建主從的時候，會提示無法找到這個文件。

3、改變一下從庫的UUID，這個玩意兒在搭建GTID復制的時候需要使用，主從環(huán)境不能重復，否則會導致服務不可用，這個UUID的變更，一般是在auto.cnf文件中，這個文件保存的是當前庫的UUID值。

4、在從庫上reset slave all，然后使用auto_position=1的復制方式搭建主從復制，搭建好主從之后，校驗主從數(shù)據(jù)的一致性。

5、在搭建好的從庫上設置read-only選項，禁止從庫上直接執(zhí)行DML操作

以上就是MySQL大庫搭建主從的一種思路分享的詳細內(nèi)容，更多關于MySQL大庫搭建主從的資料請關注好吧啦網(wǎng)其它相關文章！