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

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

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

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

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

大庫(kù)搭建主從的一種方式

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

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

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

1、直接備份在服務(wù)器上

2、備份在遠(yuǎn)程nfs掛載備份機(jī)里面

    來看這兩種方法，服務(wù)器本身沒有那么多剩余的空間可供使用，強(qiáng)行備份也可以，但是會(huì)導(dǎo)致磁盤報(bào)警，這肯定不是一個(gè)好的方法。況且要是使用xtrabackup的方法去搞，apply log和copy back這兩步花費(fèi)的時(shí)間相當(dāng)長(zhǎng)。

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

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

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

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

第三：時(shí)間比較快

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

1、將從庫(kù)中原來的my.cnf文件替換拷貝過來的主庫(kù)的my.cnf文件，否則server_id將會(huì)重復(fù)，導(dǎo)致搭建主從報(bào)錯(cuò)。

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

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

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

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

以上就是MySQL大庫(kù)搭建主從的一種思路分享的詳細(xì)內(nèi)容，更多關(guān)于MySQL大庫(kù)搭建主從的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論