這個周忙的就像打仗一樣,感覺有點被別人牽著鼻子走了,每天都是早出晚歸,干不完的活兒,有時候感覺DBA這碗飯真的不好吃,要有強大的抗壓能力和心理承受能力。今天下午吃飯的時候,真的感覺整個人快要垮掉了,吃完飯就依然決然的下班了,走在路上,看著下班的人群,心想這不就是正常的下班時間么,為什么我還有種早走慚愧的感覺?可能整個人都被洗腦了吧。
這個周的公眾號內(nèi)容更新也是耽擱了兩天,周二那天實在是太累了,就直接休息了。 昨晚要走的時候,大概九點多,工作了一天比較累,然后就大腦不聽使喚,弄了一個故障,把線上一臺環(huán)境的賬號權限表給刪掉了,然后發(fā)現(xiàn)那套環(huán)境還是個新的,沒有進行備份,我了個蒼天,當時感覺天都快塌了,幸好我平時有保留變更的習慣,在自己的txt文件里面找到了之前給業(yè)務方開過的一些賬號權限,花了兩個小時給修復了,期間包括測試服務是否可用,同步是否及時等等。回來一看時間,已經(jīng)是十一點半了,趕緊抓時間寫公眾號,結(jié)果呢,寫完的時候已經(jīng)零點六分了,就索性沒有更新公眾號。
這種感覺真的很不好,不知道在哪兒看到過一句話,“毀掉一個ITer最好的方式,就是讓他忙到?jīng)]有時間成長”,我現(xiàn)在感覺自己就在這種惡性循環(huán)當中,又想起一個哥們兒給我說過的話,“埋頭給公司拉車的時候,要時不時抬頭看看前方的路?!?/p>
希望能夠快速調(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大庫搭建主從的資料請關注腳本之家其它相關文章!
您可能感興趣的文章:- 基于Docker的MySQL主從復制環(huán)境搭建的實現(xiàn)步驟
- 在centos7上搭建mysql主從服務器的方法(圖文教程)
- 如何快速使用mysqlreplicate搭建MySQL主從
- CentOS服務器平臺搭建mysql主從復制與讀寫分離的方法
- MySQL主從數(shù)據(jù)庫搭建方法詳解
- MySQL5.7.18主從復制搭建(一主一從)教程詳解
- 詳解MySQL主從復制讀寫分離搭建
- 使用Docker容器搭建MySql主從復制
- mysql 5.7 docker 主從復制架構搭建教程