mysql主從複制架構,是mysql資料庫主要特色之一，絕大多數公司都有用到。
而GTID模式是基于事務的複制模式的意思，發展到現在也是越來越多人用。
以前很多文章，介紹搭建mysql主從複制架構，是需要停止應用服務來做的,對于生産環境，怎麼可能讓你随便停服務？是以必須做到線上做,不影響業務,那才是最實際的。
先說明,案例分兩種方案,實作的意義是一樣的,一種是mysqldump方式,一種是xtrabackup方式,視乎實際情況,因為有些業務不一定能用xtrabackup，例如阿裡雲RDS，騰訊CDB.
配置和授權(通用前置步驟）
如果沒有開GTID模式,主從庫不用做些什麼特别配置,主從之間注意server-id不要一樣就可以了,這個坑很容易掉進去.
當然了,binlog是必須開的,主從就靠這個來複制的,不開就是白搭.
還有binlog_format推薦用row,原則上mixed也沒啥大問題,但是很多情況下實際上都會自動轉成row模式的，而且row模式是三種模式中，最少可能丢資料的模式，即使丢資料也是極個别的極端情況，例如斷網.
事務隔離界别transaction_isolation推薦REPEATABLE-READ或READ-COMMITTED都可以，視乎你對資料一緻性要求高不高，但不代表那種會資料不準确.
========================================
開啟GTID模式,那就要設定下面兩個參數,而且一做就要全做，各主從伺服器都要做，并需要重新開機mysql服務才能生效
<code>#這個不能線上開啟，要寫到配置檔案my.cnf裡面,還要重新開機才生效。</code>
<code>#不然就是下面的報錯</code>
<code>mysql> </code><code>set</code> <code>gtid_mode = 1;</code>
<code>ERROR 1238 (HY000): Variable </code><code>'gtid_mode'</code> <code>is a </code><code>read</code> <code>only variable</code>
<code>#是以我們要編輯my.cnf來開啟</code>
<code>vim my.cnf</code>
<code>#GTID模式,5.6的新功能,新的複制驗證方式,需要就打開,binlog建議改成row</code>
<code>gtid_mode = on</code>
<code>binlog_format = row</code>
<code>#強制GTID的一緻性,一般和上面參數一起使用,但是開啟後隻允許能夠保障事務安全，并且能夠被日志記錄的SQL語句被執行，</code>
<code>#像create table ... select 和 create temporarytable語句，以及同時更新事務表和非事務表的SQL語句或事務都不允許執行。</code>
<code>enforce_gtid_consistency = 1</code>
<code>#然後重新開機mysql程序</code>
<code>service mysqld restart</code>
擴充一下,在gtid模式下,出現不支援的語句需要自己去修改,不然會報錯或不記錄,例如下面這樣.
<code>CREATE TABLE ... SELECT</code>
<code>可以改為下面這樣分成兩句:</code>
<code>CREATE TABLE</code>
<code>INSERT ... SELECT</code>
因為GTID模式要重新開機才能生效,對于一些大庫要慎重更改使用gtid(重新開機失敗那就悲劇了),一定要用的話,主庫要找個月黑風高,夜深人靜的時候設定完再重新開機,從庫就沒所謂啦.
==========================================
然後我們還要關注一些參數，在從庫可以選擇性開啟，主庫加不加都不影響使用，
<code>#用來配置從伺服器的更新是否寫入二進制日志,如果有層級從庫就必須開,沒有的話建議關閉,能有效提高性能</code>
<code>log_slave_updates</code>
<code>#設定從庫SQL線程并行重放events(事務)的worker線程數量,預設值為0，最大值為1024.在5.6.x版本中設定這個參數大于0時，</code>
<code>#則SQL線程充當worker線程的協調者，在多個worker線程之間分發基于庫級别的events,也就是庫級别并行複制，</code>
<code>#5.7.x版本的并行複制可以設定基于組送出事務的并行複制,更加好用.</code>
<code>slave_parallel_workers = 8</code>
<code>#5.7新參數，指定并行複制方式，為了相容5.6的模式，預設的并行複制方式是基于庫級别的，即預設值是：DATABASE，</code>
<code>#我們要設定成5.7支援的基于組送出事務的并行複制方式，則需要設定成：LOGICAL_CLOCK，速度更快。</code>
<code>#slave_parallel_type = LOGICAL_CLOCK</code>
題外話，這個看需求來開啟,有個别從庫會再搭從庫來挂載,如果不開這個參數,那就做不了,如果沒有這種需求,不開也沒什麼,反而增加性能.
配置修改完了,我還還需要在主庫授權一下主從複制使用者的權限,這裡說的授權是指主庫對從庫授權讀寫binlog權限.
<code>mysql>grant replication slave on *.* to </code><code>'rep'</code><code>@</code><code>'%'</code> <code>identified by </code><code>'password'</code><code>;</code>
因為我貪友善,直接用的root使用者,後面請見諒了.
mysqldump方式
因為mysql自帶,不需要再做些什麼,比較友善易用,不過需要強調一下,資料量太大的話,mysqldump就略顯不足了,因為是邏輯備份和導入，導出導入時間耗費巨大,各位自己衡量.
第一步,資料的導出與導入和初始化從庫（以下操作，先在主庫操作，後在從庫操作）
導出和導入,如果庫太大,就會多花點時間,也正如我們開頭說的,先用的是mysqldump來,具體參數我就不多說了,有興趣就去查一下,直接看指令就好了.
首先，我們先從主庫備份個整庫備份：
<code>mysqldump -uroot -p123123 --opt --default-character-</code><code>set</code><code>=utf8 --triggers -R --hex-blob --single-transaction --no-autocommit --master-data=2 -A >test2.sql</code>
就這樣,我們就得到全庫備份檔案test2.sql,
對于有沒有必要做全庫備份的問題,要看實際情況,如果你是做MHA,PXC之類的叢集,你必然要保持主從資料完全一緻,不隻是業務庫,系統庫也需要.如果你從庫一開始就不打算拿來用,那确實隻操作業務庫就好了,還有其他什麼忽略不需要複制到從庫的參數,這個按你需求實際情況來做,這裡就不再細說了.
需要強調一下的是,為什麼能做到線上建立和重做主從,就是因為這個參數,
--master-data=2
後面會詳細說說這個參數會有些什麼特别的地方.
轉回正題,備份做完了,那就是要拷到從庫恢複了,怎麼傳輸過去,這裡就不細說了,什麼scp,rsync,http,ftp什麼的,你喜歡就好了,而我這裡,用的是scp
<code>scp</code> <code>-o StrictHostKeyChecking=no [email protected]:</code><code>/data/ttt/test2</code><code>.sql </code><code>/data/ttt</code>
指令僅供參考,你們自己喜歡怎麼改都行
再然後,要初始化一下從庫的mysql。
雖然說現在是測試,不過一般來說,建立和重做主從,必然是因為他本來就是空白機,或者是主從失效了,需要重做,原因我不說了,反正類似pt-osc工具也沒用的,就是必須重做的架勢,至于怎麼安裝mysql我就不多說了.
簡單說說怎麼初始化,具體可以看我另一篇文章
<code>#這個隻是5.6的初始化方式</code>
<code>service mysqld stop</code>
<code>rm</code> <code>-rf </code><code>/data/mysql/data/</code><code>*</code>
<code>/usr/local/mysql/scripts/mysql_install_db</code> <code>--defaults-</code><code>file</code><code>=</code><code>/usr/local/mysql/my</code><code>.cnf --basedir=</code><code>/usr/local/mysql/</code> <code>--datadir=</code><code>/data/mysql/data</code> <code>--user=mysql > </code><code>/dev/null</code> <code>2>&1</code>
<code>service mysqld start</code>
<code>/usr/local/mysql/bin/mysqladmin</code> <code>-u root password </code><code>'123123'</code>
<code>#5.7的和這個不一樣,請看我另一篇文章</code>
簡單幾個指令就完成了初始化,然後準備導入,為什麼要說準備呢,當然是因為還有些準備工作,例如是如果要開GTID的話
<code>#使用GTID模式的執行個體的導入,需要目标執行個體的GTID記錄是空的,不然會報錯,就類似這樣:</code>
<code>[root@pingtest1 ttt]</code><code># mysql -uroot -p123123 < test2.sql </code>
<code>Warning: Using a password on the </code><code>command</code> <code>line interface can be insecure.</code>
<code>ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be </code><code>set</code> <code>when @@GLOBAL.GTID_EXECUTED is empty.</code>
<code>#提示GTID_EXECUTED為非空,不能導入.</code>
<code>#是以導入前要先重置下binlog</code>
<code>mysql>reset master;</code>
<code>#重置了binlog那就沒問題了,重新執行</code>
<code>mysql -uroot -p123123 -e </code><code>'reset master'</code>
<code>mysql -uroot -p123123 < test2.sql</code>
<code>#好了,導入完成後,我們檢查一下,gtid模式要看看這個</code>
<code>mysql>show variables like </code><code>"%gtid%"</code><code>;</code>
<code>gtid_purged | 16fdabc7-30f9-11e6-9234-0800273e5680:1-3216</code>
看到上面這個就行了.
第二步,配置主從同步（以下操作，都是在從庫操作）
在說怎麼配置之前,我先說一下為什麼能線上不停應用服務來做主從的原因,還記得我上面說的那個參數嗎?,沒錯,就是--master-data=2,意思是記錄備份目前的binlog資訊.
有不少人以前做主從,都是從主庫show master status檢視binlog位置,然後change master to.....是以必須把應用服務停了,不然binlog位置變了後,在做主從期間中間那些語句就執行不了,最終導緻資料不同步.
而加了--master-data=2之後,test2.sql這個檔案會記錄目前binlog的位置,這樣我們就不用理會做主從期間中間的那些資料,隻需要把binlog位置直接指向sql檔案裡面的binlog位置就可以了,然後資料就會自己同步到最新位置.
來看看我的test2.sql的binlog位置,就檔案的前30行,要是你覺得檔案太大很難打開,more或者head -30都可以,就不要vim了,隻看關鍵字
<code>SET @@GLOBAL.GTID_PURGED=</code><code>'16fdabc7-30f9-11e6-9234-0800273e5680:1-3216'</code><code>;</code>
<code>--</code>
<code>-- Position to start replication or point-</code><code>in</code><code>-</code><code>time</code> <code>recovery from</code>
<code>-- CHANGE MASTER TO MASTER_LOG_FILE=</code><code>'mysql-bin.000019'</code><code>, MASTER_LOG_POS=1856541;</code>
看到了,目前binlog位置是mysql-bin.000019,Position位置是1856541,gtid位置是16fdabc7-30f9-11e6-9234-0800273e5680:1-3216.
知道了這些資訊,那麼我們就可以開幹了
一般模式直接change master to就可以了,主要就是mysql-bin.000019和Position位置是1856541,用來告訴主庫,我這些語句執行過了,不需要理會GTID的東西(其實主庫沒開GTID就不會存在這個資料)
<code>#做之前，别忘記先清空一下主從結構的記錄</code>
<code>mysql>reset slave all;</code>
<code>#然後再執行操作</code>
<code>mysql>change master to</code>
<code>master_host=</code><code>'10.0.2.6'</code><code>,</code>
<code>master_user=</code><code>'repl'</code><code>,</code>
<code>master_password=</code><code>'*****'</code><code>,</code>
<code>master_port=3306,</code>
<code>master_log_file=</code><code>'mysql-bin.000019'</code><code>,</code>
<code>master_log_pos=1856541;</code>
====================================
GTID模式下,則還需要多做一步,就是執行那個語句,設定gtid編号,用來告訴主庫,我這些語句執行過了,
<code>mysql>SET @@GLOBAL.GTID_PURGED=</code><code>'16fdabc7-30f9-11e6-9234-0800273e5680:1-3216'</code><code>;</code>
就是跳過之前已經複制過的事務,因為GTID記錄的事務是從1開始的,隻會增加或變更UUID,不會重置計數器,是以就要手動設定跳過之前執行過(已經在備份裡的結果)的事務.然後change master to一下,
<code>master_user=</code><code>'root'</code><code>,</code>
<code>master_password=</code><code>'123123'</code><code>,</code>
<code>MASTER_AUTO_POSITION = 1;</code>
在這一步GTID簡單很多,這也是為什麼越來越多人用的原因,已經不用理會pos跑到哪裡,他會自己去找.
要注意的是,主庫開了GTID複制模式,從庫就用不了舊的模式來做複制了,會提示報錯,是以從庫必須也使用GTID模式來做從庫才可以.
======================================
<code>然後啟動從庫複制</code>
<code>mysql>start slave;</code>
<code>最後檢查一下</code>
<code>mysql>show slave status\G</code>
<code> </code><code>Master_Log_File: mysql-bin.000019</code>
<code> </code><code>Read_Master_Log_Pos: 4980238</code>
<code> </code><code>Relay_Log_File: pingtest1-relay-bin.000002</code>
<code> </code><code>Relay_Log_Pos: 3124105</code>
<code> </code><code>Relay_Master_Log_File: mysql-bin.000019</code>
<code> </code><code>Slave_IO_Running: Yes</code>
<code> </code><code>Slave_SQL_Running: Yes</code>
<code> </code><code>.</code>
<code> </code><code>Exec_Master_Log_Pos: 4980238</code>
<code> </code><code>Retrieved_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:3217-4885</code>
<code> </code><code>Executed_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:1-4885</code>
如何證明主從複制正常了呢？主要看下面這些值：
Slave_IO_Running和Slave_SQL_Running的雙yes： 證明io線程和sql線程都正常，如果不是雙yes，這個主從複制架構就是失敗的，不能使用。
Master_Log_File=Relay_Master_Log_File： 證明從庫執行的binlog檔案和主庫的是一緻的，不一緻就是不同步了，有一定延時，但還可以用，關鍵看你能不能接受這個延時（跨binlog檔案一般算比較大的延時了）。
Read_Master_Log_Pos=Exec_Master_Log_Pos： 證明從庫執行binlog的pos位置是和主庫一緻的，如果是操作太頻繁的庫，有一些不一緻是正常的，如果太大，就代表資料有延時，但不影響從庫使用。
Seconds_Behind_Master： 表示slave上SQL thread與IO thread之間的延遲，也就是看到還有多少資料還沒寫進去。在MySQL的複制環境中，slave先從master上将binlog拉取到本地（通過IO thread），然後通過SQL thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被執行完的那部分的內插補點。
因為我資料比較少,很容易就追上了,看不到差異,但是可以很肯定和你們說,我主庫沒停過應用服務,然後從庫就做好了。
再看看主庫上面的線程如何
<code>mysql>show processlist;</code>
<code>9172 | root | 10.0.2.5:57506 | NULL | Binlog Dump GTID | 75 | Master has sent all binlog to slave; waiting </code><code>for</code> <code>binlog to be updated</code>
線程也在,可以确定整套複制都正常了.
xtrabackup方式
也正如我開頭說的,某些庫很大,幾十G幾百G什麼的也不用很意外,如果還用mysqldump就不科學了,導出導入耗費時間巨大,這個時候就必須靠xtrabackup這種實體拷貝的備份還原工具,加快速度進行,另一方面來說,從備份原理得出的結果來看,mysqldump備份得到的結果是備份開始時間的資料結果,而xtrabackup備份得到的結果是備份結束時間的資料結果,是屬于比較新的資料,對于操作頻繁的庫用xtrabackup來做也是優勢明顯.
第一步目的和上面一緻,隻是用了軟體,而用xtrabackup恢複不需要初始化mysql（以下操作，先在主庫操作，後在從庫操作）
至于怎麼安裝xtrabackup就不多說了,各位可以看我另一篇文章,介紹怎麼安裝xtrabackup和介紹怎麼使用xtrabackup,指令我就簡單貼出來,然後說一下用途就算了.
先在主庫備份全庫(想隻備份特定庫的還請自己想辦法,這裡就不延伸了)
<code>innobackupex --defaults-</code><code>file</code><code>=</code><code>"/usr/local/mysql/my.cnf"</code> <code>--user=root --password=</code><code>'123123'</code> <code>--stream=</code><code>tar</code> <code>"/data/ttt"</code> <code>2> </code><code>/data/ttt/backup</code><code>.log | </code><code>gzip</code> <code>> </code><code>/data/ttt/test2</code><code>.tgz</code>
意思就是把/usr/local/mysql/my.cnf配置檔案裡标明的全庫拷貝出來,并通過gzip壓縮成一個檔案.
拷貝到從庫機器
<code>scp</code> <code>-o StrictHostKeyChecking=no [email protected]:</code><code>/data/ttt/test2</code><code>.tgz ./</code>
然後在從庫伺服器操作，拷貝到一個檔案夾解壓
<code>mkdir</code> <code>test2back</code>
<code>mv</code> <code>test2.tgz test2back/</code>
<code>cd</code> <code>test2back/</code>
<code>tar</code> <code>xf test2.tgz</code>
在從庫開始恢複備份
<code>#關閉mysql服務</code>
<code>/etc/init</code><code>.d</code><code>/mysqld</code> <code>stop</code>
<code>#先删了舊的資料檔案</code>
<code>#然後先apply-log</code>
<code>innobackupex --defaults-</code><code>file</code><code>=</code><code>'/usr/local/mysql/my.cnf'</code> <code>--apply-log </code><code>/data/ttt/test2back/</code>
<code>#然後開始恢複</code>
<code>innobackupex --defaults-</code><code>file</code><code>=</code><code>'/usr/local/mysql/my.cnf'</code> <code>--copy-back </code><code>/data/ttt/test2back/</code>
<code>#恢複完成後看一下,做完收尾工作</code>
<code>ll </code><code>/data/mysql/data</code>
<code>chown</code> <code>-R mysql.mysql data/</code>
<code>#啟動mysql服務</code>
<code>/etc/init</code><code>.d</code><code>/mysqld</code> <code>start</code>
<code>#嘗試登陸一下,ok就完成了</code>
<code>mysql -uroot -p123123</code>
相對來說,速度快了一些,操作也還是簡單一些,就是多安裝了一個軟體.
實際上和上面用mysqldump的思維是一樣,因為xtrabackup備份完成時會生成一個檔案xtrabackup_binlog_info,裡面就記錄了binlog位置和GTID值,故而也能做到不停應用服務來做主從,而且用xtrabackup資料還比較新.
我們來打開這個檔案看一下
<code>vim xtrabackup_binlog_info</code>
<code>mysql-bin.000020 8454162 16fdabc7-30f9-11e6-9234-0800273e5680:1-22037</code>
非常直覺,就這三個值,如果你還有興趣留意,其實xtrabackup_info也有記錄，不過兩者還是有一些差異.
大多數時候用xtrabackup_binlog_info就可以了，但是特殊情況下用xtrabackup_binlog_pos_innodb會好一些，因為xtrabackup_binlog_info中記錄的位置包含非innodb引擎的資料變化位置，但是對于innodb引擎，redo log裡邊本身是包含了binlog pos的，如果你apply log，那麼事務的前滾，復原可能造成這個位置有變動，如果你是做主備複制，複制搭建之後，同步的資料包含非innodb表，那這個xtrabackup_binlog_pos_innodb中的位置就不可靠，反之如果你的同步不涉及到非innodb表，那麼可以使用它。
也正如我上面第二步說的,備份恢複完之後,這個從庫就可以用了,設定的方法也和上面mysqldump沒差别,如果是非GTID的話,直接change master to 就可以用了,
<code>master_log_file=</code><code>'mysql-bin.000020'</code><code>,</code>
<code>master_log_pos=8454162;</code>
如果是GTID模式的話,那就先set一下,跳過之前已經執行過的事務
<code>mysql>SET @@GLOBAL.GTID_PURGED=</code><code>'16fdabc7-30f9-11e6-9234-0800273e5680:1-22037'</code><code>;</code>
然後看一下狀态
<code>mysql> show variables like </code><code>'%gtid%'</code><code>;</code>
<code>gtid_purged | 16fdabc7-30f9-11e6-9234-0800273e5680:1-22037 |</code>
再執行change master to 來完成
然後啟動從庫複制
<code> </code><code>Master_Log_File: mysql-bin.000020</code>
<code> </code><code>Relay_Log_Pos: 17522575</code>
<code> </code><code>Relay_Master_Log_File: mysql-bin.000020</code>
<code> </code><code>Exec_Master_Log_Pos: 17522575</code>
<code> </code><code>Retrieved_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:22038-26950</code>
<code> </code><code>Executed_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:1-26950</code>
還是太快,看不到差異,不過可以肯定複制是完成了,主從架構完成,主庫依然沒有停過.
<code>32718 | root | 10.0.2.5:54224 | NULL | Binlog Dump GTID | 162 | Master has sent all binlog to slave; waiting </code><code>for</code> <code>binlog to be updated</code>
擴充閱讀：
說起了主從複制延時，就不得不強調，一般的主從複制，是屬于異步複制的，即主庫不需要理會從庫是否執行，或者知否追得上複制的速度，隻管自己跑，如果有漏了什麼也是不管的，這也是我們常說的主從不一緻的根本原因。
為了解決這個問題，就有了半同步複制，和完全同步複制的概念。
半同步的意思是一個事務在主庫執行完還不行，必須在至少一個從庫成功寫入資料，事務才算真正送出成功，而其他還沒寫入的從庫則執行異步操作，後續再寫入。這時主庫不能再把從庫狀态棄之不顧，必須知道至少一個從庫寫入成功才能完成，減少複制失敗的事情，但風險還有一些，因為還有一些異步複制的從庫。
完全同步就更加嚴格，要所有從庫傳回寫入成功，這個事務才能算送出成功，嚴格來說，隻有一台從庫的半同步架構，也和完全同步的概念相等。
實作半同步的方式很簡單，mysql有自帶半同步插件，隻是一般沒有使用，我的另一篇文章有說明，配置起來也不難。
實作完全同步方式則大多數是靠叢集軟體實作，例如很出名的PXC叢集軟體，必須所有主從都要寫入成功，事務才算送出完成。
但是論性能，半同步和完全同步，必然會比異步降低得很明顯，資料一緻性要求和系統性能，永遠都是背道而馳。
問題彙總:
有些朋友做的從庫,可能有一種情況,就是除同步賬戶外,本身并不知道主庫的其他使用者密碼,這就造成一種尴尬的情況,如果需要管理從庫的時候,就顯得很不友善,是以逼着要去破解從庫的密碼.
還有另一種情況,就是主庫和從庫版本不一緻,資料表結構可能會有一些版本造成的差異,如果主庫這些表有更改,就會在從庫報錯,算是一個隐性坑,是以我們最好忽略這些表或庫的同步語句.
1. 先來看怎麼破解密碼:
<code>#先關閉mysql</code>
<code>#進入安全模式</code>
<code>/usr/local/mysql/bin/mysqld_safe</code> <code>--skip-grant-tables --skip-networking&</code>
<code>#此時就免密碼登陸了</code>
<code>/usr/local/mysql/bin/mysql</code> <code>-uroot</code>
<code>#更改密碼，密碼和使用者可選，</code>
<code>#這是5.6及之前的方式</code>
<code>update mysql.user </code><code>set</code> <code>password=PASSWORD(</code><code>'新密碼'</code><code>) where user=</code><code>'root'</code> <code>and host=</code><code>'root'</code> <code>or host=</code><code>'localhost'</code><code>or host=</code><code>'localhost.localdomain'</code><code>or host=</code><code>'127.0.0.1'</code><code>;</code>
<code>#5.7之後要用新的字段</code>
<code>update mysql.user </code><code>set</code> <code>authentication_string=password(</code><code>'新密碼'</code><code>) where user=</code><code>'root'</code>
<code>#重新整理政策</code>
<code>flush privileges;</code>
<code>#重新開機mysql</code>
<code>/etc/init</code><code>.d</code><code>/mysqld</code> <code>restart</code>
<code>#正常登陸</code>
<code>/usr/local/mysql/bin/mysql</code> <code>-uroot -p</code><code>'新密碼'</code>
<code>#如果有需要就更新下版本,例如5.6主庫,5.7主庫這種情況</code>
<code>mysql_upgrade --defaults-</code><code>file</code><code>=</code><code>/usr/local/mysql/my</code><code>.cnf -uroot -p</code><code>'新密碼'</code> <code>-h127.0.0.1</code>
<code>#測試功能是否正常</code>
<code>mysql> show databases;</code>
2. 然後是第二種情況,忽略某些表和庫的同步,忽略同步的方式可以在主庫做,也可以在從庫做,不過從一些解析起來很麻煩的坑來說(這裡就不說太多了),在從庫做是最好的.
<code>#在5.6版本之前需要在配置檔案my.cnf操作,當然是要重新開機才生效</code>
<code>vim </code><code>/usr/local/mysql/my</code><code>.cnf</code>
<code>#隻執行某個庫或某個表的同步語句</code>
<code>replicate_wild_do_table=</code><code>test</code><code>.%,mysql.user</code>
<code>#忽略掉某個庫或某個表的同步語句</code>
<code>replicate_wild_ignore_table=mysql.%,</code><code>test</code><code>.fucking</code>
<code>#在5.7之後的版本,新加入了一個動态修改的指令,不用重新開機了</code>
<code>#這次不用理會配置檔案了,當然後面加一下我覺得還是有必要,避免重新開機後還原的報錯</code>
<code>mysql > change replication filter replicate_wild_do_table=(</code><code>''</code><code>test</code><code>.%</code><code>','</code><code>'mysql.user'</code><code>);</code>
<code>mysql > change replication filter replicate_wild_ignore_table=(</code><code>''</code><code>test</code><code>.%</code><code>','</code><code>'mysql.user'</code><code>);</code>
提醒下,忽略同步的庫和表要走心,考慮多一些情況.
3. 在停止多元複制環境時要注意并行複制的進度，例如出現下面這種情況，就先等一等再停止。
<code>#請關注Executed_Gtid_Set:項</code>
<code>show slave status\G</code>
<code> </code><code>.</code>
<code> </code><code>Master_Server_Id: 2721321239</code>
<code> </code><code>Master_UUID: 4cdc2a74-6299-11e6-95ce-008cfaf595bc</code>
<code> </code><code>Master_Info_File: mysql.slave_master_info</code>
<code> </code><code>SQL_Delay: 0</code>
<code> </code><code>SQL_Remaining_Delay: NULL</code>
<code> </code><code>Slave_SQL_Running_State: Reading event from the relay log</code>
<code> </code><code>Master_Retry_Count: 86400</code>
<code> </code><code>Master_Bind: </code>
<code> </code><code>Last_IO_Error_Timestamp: </code>
<code> </code><code>Last_SQL_Error_Timestamp: </code>
<code> </code><code>Master_SSL_Crl: </code>
<code> </code><code>Master_SSL_Crlpath: </code>
<code> </code><code>Retrieved_Gtid_Set: 4cdc2a74-6299-11e6-95ce-008cfaf595bc:50007036-50049107</code>
<code> </code><code>Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-47551250,</code>
<code>3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,</code>
<code>4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-50010063:50010080-50010093:50010099-50010101:50010108:50010130-50010139:50010145-50010148:50010158:50010179-50010184:50010190-50010200:50010207:50010215-50010221:50010227-50010236:50010243:50010276-50010285:50010291-50010293:50010300:50010308-50010312:50010326-50010328:50010371-50010373:50010391-50010393:50010403-50010405:50010427-50010429:50010464-50010466:50010480-50010482:50010490-50010496:50010518-50010520:50010538-50010540:50010551-50010553:50010574</code>
<code> </code><code>Auto_Position: 1</code>
<code> </code><code>Replicate_Rewrite_DB: </code>
<code> </code><code>Channel_Name: al_rds</code>
<code> </code><code>Master_TLS_Version: </code>
<code>*************************** 2. row ***************************</code>
<code> </code><code>Slave_IO_State: Waiting </code><code>for</code> <code>master to send event</code>
那是因為你這麼一停止，并行複制就中途停止了，就有可能出現有些資料復原不了，或者有些資料複制錯誤，然後後續你還想把他起來就很大可能會報錯了，是以甯願先等一等，再停止。
當然了，如果是線上環境，究竟要等到什麼時候？是以最好就是資料庫不繁忙的時候再做。要麼，你就是準備好重做的心态了，那就來吧。
本文轉自arthur376 51CTO部落格，原文連結：http://blog.51cto.com/arthur376/1792551，如需轉載請自行聯系原作者
![SQL優化SQL語句優化的目的[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)