|
管理mysql主從有2年多了，管理過200多組mysql主從，幾乎涉及到各個(gè)版本的主從，本博文屬于總結(jié)性的，有一部分是摘自網(wǎng)絡(luò)，大部分是根據(jù)自己管理的心得和經(jīng)驗(yàn)所寫，整理了一下，分享給各位同行，希望對(duì)大家有幫助，互相交流。 1、Replication 線程 Mysql的 Replication 是一個(gè)異步的復(fù)制過程（mysql5.1.7以上版本分為異步復(fù)制和半同步兩種模式），從一個(gè) Mysql instace(我們稱之為 Master)復(fù)制到另一個(gè) Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實(shí)現(xiàn)整個(gè)復(fù)制過程主要由三個(gè)線程來完成，其中兩個(gè)線程(Sql線程和IO線程)在 Slave 端，另外一個(gè)線程(IO線程)在 Master 端。 要實(shí)現(xiàn) MySQL 的 Replication ，首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否則無法實(shí)現(xiàn)。因?yàn)檎麄€(gè)復(fù)制過程實(shí)際上就是Slave從Master端獲取該日志然后再在自己身上完全 順序的執(zhí)行日志中所記錄的各種操作。打開 MySQL 的 Binary Log 可以通過在啟動(dòng) MySQL Server 的過程中使用 “—log-bin” 參數(shù)選項(xiàng)，或者在 my.cnf 配置文件中的 mysqld 參數(shù)組([mysqld]標(biāo)識(shí)后的參數(shù)部分)增加 “l(fā)og-bin” 參數(shù)項(xiàng)。 2、MySQL 復(fù)制的基本過程如下： 2.1．Slave 上面的IO線程連接上 Master，并請(qǐng)求從指定日志文件的指定位置(或者從最開始的日志)之后的日志內(nèi)容； 2.2. Master 接收到來自 Slave 的 IO 線程的請(qǐng)求后，通過負(fù)責(zé)復(fù)制的 IO 線程根據(jù)請(qǐng)求信息讀取指定日志指定位置之后的日志信息，返回給 Slave 端的 IO 線程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Binary Log 中的位置； 2.3. Slave 的 IO 線程接收到信息后，將接收到的日志內(nèi)容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中，以便在下一次讀取的時(shí)候能夠清楚的高速M(fèi)aster“我需要從某個(gè)bin-log的哪個(gè)位置開始往后的日志內(nèi)容，請(qǐng)發(fā)給我” 2.4. Slave 的 SQL 線程檢測(cè)到 Relay Log 中新增加了內(nèi)容后，會(huì)馬上解析該 Log 文件中的內(nèi)容成為在 Master 端真實(shí)執(zhí)行時(shí)候的那些可執(zhí)行的 Query 語句，并在自身執(zhí)行這些 Query。這樣，實(shí)際上就是在 Master 端和 Slave 端執(zhí)行了同樣的 Query，所以兩端的數(shù)據(jù)是完全一樣的。 3、Mysql復(fù)制的幾種模式 3.1.從 MySQL 5.1.12 開始，可以用以下三種模式來實(shí)現(xiàn)： – 基于SQL語句的復(fù)制(statement-based replication, SBR)， – 基于行的復(fù)制(row-based replication, RBR)， – 混合模式復(fù)制(mixed-based replication, MBR)。 相應(yīng)地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默認(rèn)的。 在運(yùn)行時(shí)可以動(dòng)態(tài)改動(dòng) binlog的格式，除了以下幾種情況： 1.存儲(chǔ)流程或者觸發(fā)器中間 2.啟用了NDB 3.當(dāng)前會(huì)話試用 RBR 模式，并且已打開了臨時(shí)表 如果binlog采用了 MIXED 模式，那么在以下幾種情況下會(huì)自動(dòng)將binlog的模式由 SBR 模式改成 RBR 模式： 1.當(dāng)DML語句更新一個(gè)NDB表時(shí) 2.當(dāng)函數(shù)中包含 UUID() 時(shí) 3.2個(gè)及以上包含 AUTO_INCREMENT 字段的表被更新時(shí) 4.行任何 INSERT DELAYED 語句時(shí) 5.用 UDF 時(shí) 6.視圖中必須要求運(yùn)用 RBR 時(shí)，例如建立視圖是運(yùn)用了 UUID() 函數(shù) 3.2.設(shè)定主從復(fù)制模式： log-bin=mysql-bin #binlog_format="STATEMENT" #binlog_format="ROW" binlog_format="MIXED" 也可以在運(yùn)行時(shí)動(dòng)態(tài)修改binlog的格式。例如 mysql> SET SESSION binlog_format = 'STATEMENT'; mysql> SET SESSION binlog_format = 'ROW'; mysql> SET SESSION binlog_format = 'MIXED'; mysql> SET GLOBAL binlog_format = 'STATEMENT'; mysql> SET GLOBAL binlog_format = 'ROW'; mysql> SET GLOBAL binlog_format = 'MIXED'; 3.3.兩種模式各自的優(yōu)缺點(diǎn)： SBR 的優(yōu)點(diǎn)： 歷史悠久，技能成熟 binlog文件較小 binlog中包含了所有數(shù)據(jù)庫修改信息，可以據(jù)此來審核數(shù)據(jù)庫的安全等情況 binlog可以用于實(shí)時(shí)的還原，而不僅僅用于復(fù)制 主從版本可以不一樣，從服務(wù)器版本可以比主服務(wù)器版本高 SBR 的缺點(diǎn)： 不是所有的UPDATE語句都能被復(fù)制，尤其是包含不確定操作的時(shí)候。 調(diào)用具有不確定因素的 UDF 時(shí)復(fù)制也可能出疑問 運(yùn)用以下函數(shù)的語句也不能被復(fù)制： * LOAD_FILE() * UUID() * USER() * FOUND_ROWS() * SYSDATE() (除非啟動(dòng)時(shí)啟用了 –sysdate-is-now 選項(xiàng)) INSERT … SELECT 會(huì)產(chǎn)生比 RBR 更多的行級(jí)鎖 復(fù)制須要執(zhí)行 全表掃描(WHERE 語句中沒有運(yùn)用到索引)的 UPDATE 時(shí)，須要比 RBR 請(qǐng)求更多的行級(jí)鎖 對(duì)于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會(huì)阻塞其他 INSERT 語句 對(duì)于一些復(fù)雜的語句，在從服務(wù)器上的耗資源情況會(huì)更嚴(yán)重，而 RBR 模式下，只會(huì)對(duì)那個(gè)發(fā)生變化的記錄產(chǎn)生影響 存儲(chǔ)函數(shù)(不是存儲(chǔ)流程 )在被調(diào)用的同時(shí)也會(huì)執(zhí)行一次 NOW() 函數(shù)，這個(gè)可以說是壞事也可能是好事 確定了的 UDF 也須要在從服務(wù)器上執(zhí)行 數(shù)據(jù)表必須幾乎和主服務(wù)器保持一致才行，否則可能會(huì)導(dǎo)致復(fù)制出錯(cuò) 執(zhí)行復(fù)雜語句如果出錯(cuò)的話，會(huì)消耗更多資源 RBR 的優(yōu)點(diǎn)： 任何情況都可以被復(fù)制，這對(duì)復(fù)制來說是最安全可靠的 和其他大多數(shù)數(shù)據(jù)庫系統(tǒng)的復(fù)制技能一樣 多數(shù)情況下，從服務(wù)器上的表如果有主鍵的話，復(fù)制就會(huì)快了很多 復(fù)制以下幾種語句時(shí)的行鎖更少： * INSERT … SELECT * 包含 AUTO_INCREMENT 字段的 INSERT * 沒有附帶條件或者并沒有修改很多記錄的 UPDATE 或 DELETE 語句 執(zhí)行 INSERT，UPDATE，DELETE 語句時(shí)鎖更少 從服務(wù)器上采用多線程來執(zhí)行復(fù)制成為可能 RBR 的缺點(diǎn)： binlog 大了很多 復(fù)雜的回滾時(shí) binlog 中會(huì)包含大量的數(shù)據(jù) 主服務(wù)器上執(zhí)行 UPDATE 語句時(shí)，所有發(fā)生變化的記錄都會(huì)寫到 binlog 中，而 SBR 只會(huì)寫一次，這會(huì)導(dǎo)致頻繁發(fā)生 binlog 的并發(fā)寫疑問 UDF 產(chǎn)生的大 BLOB 值會(huì)導(dǎo)致復(fù)制變慢 不能從 binlog 中看到都復(fù)制了寫什么語句(加密過的) 當(dāng)在非事務(wù)表上執(zhí)行一段堆積的SQL語句時(shí)，最好采用 SBR 模式，否則很容易導(dǎo)致主從服務(wù)器的數(shù)據(jù)不一致情況發(fā)生 另外，針對(duì)系統(tǒng)庫 mysql 里面的表發(fā)生變化時(shí)的處理準(zhǔn)則如下： 如果是采用 INSERT，UPDATE，DELETE 直接操作表的情況，則日志格式根據(jù) binlog_format 的設(shè)定而記錄 如果是采用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那么無論如何 都采用 SBR 模式記錄。 注：采用 RBR 模式后，能處理很多原先出現(xiàn)的主鍵重復(fù)問題。實(shí)例: 對(duì)于insert into db_allot_ids select * from db_allot_ids 這個(gè)語句: 在BINLOG_FORMAT=STATEMENT 模式下: BINLOG日志信息為: —————————————– BEGIN /*!*/; # at 173 #090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0 SET TIMESTAMP=1244793942/*!*/; insert into db_allot_ids select * from db_allot_ids /*!*/; —————————————– 在BINLOG_FORMAT=ROW 模式下: BINLOG日志信息為: —————————————– BINLOG ' hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA= '/*!*/; —————————————– 4、Mysql主從的優(yōu)缺點(diǎn) MySQL的主從同步是一個(gè)很成熟的架構(gòu)，優(yōu)點(diǎn)為：①在從服務(wù)器可以執(zhí)行查詢工作(即我們常說的讀功能)，降低主服 務(wù)器壓力;②在從主服務(wù)器進(jìn)行備份，避免備份期間影響主服務(wù)器服務(wù);③當(dāng)主服務(wù)器出現(xiàn)問題時(shí)，可以切換到從服務(wù)器。所以我在項(xiàng)目部署和實(shí)施中經(jīng)常會(huì)采用這種方案;鑒于生產(chǎn)環(huán)境下的mysql的嚴(yán)謹(jǐn)性。 實(shí)際上，在老版本中，MySQL 的復(fù)制實(shí)現(xiàn)在 Slave 端并不是由 SQL 線程和 IO 線程這兩個(gè)線程共同協(xié)作而完成的，而是由單獨(dú)的一個(gè)線程來完成所有的工作。但是 MySQL 的工程師們很快發(fā)現(xiàn)，這樣做存在很大的風(fēng)險(xiǎn)和性能問題，主要如下： 首先，如果通過一個(gè)單一的線程來獨(dú)立實(shí)現(xiàn)這個(gè)工作的話，就使復(fù)制 Master 端的，Binary Log日志，以及解析這些日志，然后再在自身執(zhí)行的這個(gè)過程成為一個(gè)串行的過程，性能自然會(huì)受到較大的限制，這種架構(gòu)下的 Replication 的延遲自然就比較長了。 其次，Slave 端的這個(gè)復(fù)制線程從 Master 端獲取 Binary Log 過來之后，需要接著解析這些內(nèi)容，還原成 Master 端所執(zhí)行的原始 Query，然后在自身執(zhí)行。在這個(gè)過程中，Master端很可能又已經(jīng)產(chǎn)生了大量的變化并生成了大量的 Binary Log 信息。如果在這個(gè)階段 Master 端的存儲(chǔ)系統(tǒng)出現(xiàn)了無法修復(fù)的故障，那么在這個(gè)階段所產(chǎn)生的所有變更都將永遠(yuǎn)的丟失，無法再找回來。這種潛在風(fēng)險(xiǎn)在Slave 端壓力比較大的時(shí)候尤其突出，因?yàn)槿绻?Slave 壓力比較大，解析日志以及應(yīng)用這些日志所花費(fèi)的時(shí)間自然就會(huì)更長一些，可能丟失的數(shù)據(jù)也就會(huì)更多。 所以，在后期的改造中，新版本的 MySQL 為了盡量減小這個(gè)風(fēng)險(xiǎn)，并提高復(fù)制的性能，將 Slave 端的復(fù)制改為兩個(gè)線程來完成，也就是前面所提到的 SQL 線程和 IO 線程。最早提出這個(gè)改進(jìn)方案的是Yahoo!的一位工程師“Jeremy Zawodny”。通過這樣的改造，這樣既在很大程度上解決了性能問題，縮短了異步的延時(shí)時(shí)間，同時(shí)也減少了潛在的數(shù)據(jù)丟失量。 當(dāng)然，即使是換成了現(xiàn)在這樣兩個(gè)線程來協(xié)作處理之后，同樣也還是存在 Slave 數(shù)據(jù)延時(shí)以及數(shù)據(jù)丟失的可能性的，畢竟這個(gè)復(fù)制是異步的。只要數(shù)據(jù)的更改不是在一個(gè)事務(wù)中，這些問題都是存在的。 如果要完全避免這些問題，就只能用 MySQL 的 Cluster 來解決了。不過 MySQL的 Cluster 知道筆者寫這部分內(nèi)容的時(shí)候，仍然還是一個(gè)內(nèi)存數(shù)據(jù)庫的解決方案，也就是需要將所有數(shù)據(jù)包括索引全部都 Load 到內(nèi)存中，這樣就對(duì)內(nèi)存的要求就非常大的大，對(duì)于一般的大眾化應(yīng)用來說可實(shí)施性并不是太大。MySQL 現(xiàn)在正在不斷改進(jìn)其 Cluster 的實(shí)現(xiàn)，其中非常大的一個(gè)改動(dòng)就是允許數(shù)據(jù)不用全部 Load 到內(nèi)存中，而僅僅只是索引全部 Load 到內(nèi)存中，我想信在完成該項(xiàng)改造之后的 MySQL Cluster 將會(huì)更加受人歡迎，可實(shí)施性也會(huì)更大。 我們知道在5.5之前，MySQL的復(fù)制其實(shí)是異步操作，而不是同步，也就意味著允許主從之間的數(shù)據(jù)存在一定的延遲，mysql當(dāng)初這樣設(shè)計(jì)的目的可能也是基于可用性的考慮，為了保證master不受slave的影響，并且異步復(fù)制使得master處于一種性能最優(yōu)的狀態(tài)：寫完binlog后即可提交而不需要等待slave的操作完成。這樣存在一個(gè)隱患，當(dāng)你使用slave作為備份時(shí)，如果master掛掉，那么會(huì)存在部分已提交的事務(wù)未能成功傳輸?shù)絪lave的可能，這就意味著數(shù)據(jù)丟失！ 在MySQL5.5版本中，引入了半同步復(fù)制模式（Semi-synchronous Replication）能夠成功（只是相對(duì)的）避免上述數(shù)據(jù)丟失的隱患。在這種模式下：master會(huì)等到binlog成功傳送并寫入至少一個(gè)slave的relay log之后才會(huì)提交，否則一直等待，直到timeout（默認(rèn)10s）。當(dāng)出現(xiàn)timeout的時(shí)候，master會(huì)自動(dòng)切換半同步為異步，直到至少有一個(gè)slave成功收到并發(fā)送Acknowledge，master會(huì)再切換回半同步模式。結(jié)合這個(gè)新功能，我們可以做到，在允許損失一定的事務(wù)吞吐量的前提下來保證同步數(shù)據(jù)的絕對(duì)安全，因?yàn)楫?dāng)你設(shè)置timeout為一個(gè)足夠大的值的情況下，任何提交的數(shù)據(jù)都會(huì)安全抵達(dá)slave。 mysql5.5 版本支持半同步復(fù)制功能（Semisynchronous Replication），但還不是原生的支持，是通過plugin來支持的，并且默認(rèn)是沒有安裝這個(gè)插件的。不論是二進(jìn)制發(fā)布的，還是自己源代碼編譯的，都會(huì)默認(rèn)生成這個(gè)插件，一個(gè)是針對(duì)master 的一個(gè)是針對(duì)slave的，在使用之前需要先安裝這倆plugins。 復(fù)制的過濾主要有２種方式： 1、在主服務(wù)器在把事件從進(jìn)二制日志中過濾掉，相關(guān)的參數(shù)是:binlog_do_db和binlog_ignore_db。 2、在從服務(wù)器上把事件從中繼日志中過濾掉，相關(guān)的參數(shù)是replicate_*。 復(fù)制只能擴(kuò)展讀取，不能擴(kuò)展寫入，對(duì)數(shù)據(jù)進(jìn)行分區(qū)可以進(jìn)行擴(kuò)展寫入。 復(fù)制的優(yōu)化： 在mysql復(fù)制環(huán)境中,有8個(gè)參數(shù)可以讓我們控制,需要復(fù)制或需要忽略不進(jìn)行復(fù)制的DB或table分別為: 下面二項(xiàng)需要在Master上設(shè)置： Binlog_Do_DB:設(shè)定哪些數(shù)據(jù)庫需要記錄Binlog Binlog_Ignore_DB:設(shè)定哪里數(shù)據(jù)庫不需要記錄Binlog 優(yōu)點(diǎn)是Master端的Binlog記錄所帶來的Io量減少，網(wǎng)絡(luò)IO減少，還會(huì)讓slave端的IO線程,SQL線程減少，從而大幅提高復(fù)制性能, 缺點(diǎn)是mysql判斷是否需要復(fù)制某個(gè)事件不是根據(jù)產(chǎn)生該事件的查詢所在的DB,而是根據(jù)執(zhí)行查詢時(shí)刻所在的默認(rèn)數(shù)據(jù)庫（也就是登錄時(shí)指定的庫名或運(yùn)行"use database"中指定的DB）,只有當(dāng)前默認(rèn)DB和配置中所設(shè)定的DB完全吻合時(shí)IO線程才會(huì)將該事件讀取給slave的IO線程.所以,如果在默認(rèn)DB和設(shè)定須要復(fù)制的DB不一樣的情況下改變了須要復(fù)制的DB中某個(gè)Table中的數(shù)據(jù),該事件是不會(huì)被復(fù)制到Slave中去的,這樣就會(huì)造成Slave端的數(shù)據(jù)和Master的數(shù)據(jù)不一致.同樣,在默認(rèn)的數(shù)據(jù)庫下更改了不須要復(fù)制的數(shù)據(jù)庫中的數(shù)據(jù),則會(huì)被復(fù)制到slave端,當(dāng)slave端并沒有該數(shù)據(jù)庫時(shí),則會(huì)造成復(fù)制出錯(cuò)而停止。 下面六項(xiàng)需要在slave上設(shè)置： Replicate_Do_DB:設(shè)定需要復(fù)制的數(shù)據(jù)庫,多個(gè)DB用逗號(hào)分隔 Replicate_Ignore_DB:設(shè)定可以忽略的數(shù)據(jù)庫. Replicate_Do_Table:設(shè)定需要復(fù)制的Table Replicate_Ignore_Table:設(shè)定可以忽略的Table Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但可以帶通配符來進(jìn)行設(shè)置。 Replicate_Wild_Ignore_Table:功能同Replicate_Do_Table,功能同Replicate_Ignore_Table,可以帶通配符。 優(yōu)點(diǎn)是在slave端設(shè)置復(fù)制過濾機(jī)制,可以保證不會(huì)出現(xiàn)因?yàn)槟J(rèn)的數(shù)據(jù)庫問題而造成Slave和Master數(shù)據(jù)不一致或復(fù)制出錯(cuò)的問題. 缺點(diǎn)是性能方面比在Master端差一些.原因在于:不管是否須要復(fù)制,事件都會(huì)被IO線程讀取到Slave端,這樣不僅增加了網(wǎng)絡(luò)IO量,也給Slave端的IO線程增加了Relay Log的寫入量。 注：在實(shí)際的生產(chǎn)應(yīng)用中發(fā)現(xiàn)，在mysql5.0以前的版本，mysql的這個(gè)過濾設(shè)置幾乎是形同虛設(shè)，不起作用：不管你在主庫或是從庫上設(shè)置了忽略某個(gè)數(shù)據(jù)庫或是表，他依然會(huì)進(jìn)行同步，所以在做5.0以前版本的主從同步時(shí)，一定保持主從數(shù)據(jù)庫的一致性，主上有的庫或是表從上一定要有，否則在同步的過程會(huì)出錯(cuò)。 主庫IP：192.168.1.2 從庫IP：192.168.1.3 添加一個(gè)用于主從同步的用戶： GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY ‘1q2w3e4r’; 如果監(jiān)控mysql主從的話，請(qǐng)加上一個(gè)super權(quán)限： GRANT SUPER, REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '1q2w3e4r'; 1、主庫的配置 1.1．mysql5.0以下版本的配置 修改主庫mysql配置配置文件，在[mysqld]段添加以下內(nèi)容： server-id = 1 log-bin=/home/mysql/logs/binlog/bin-log max_binlog_size = 500M binlog_cache_size = 128K binlog-do-db = adb binlog-ignore-db = mysql log-slave-updates 1.2. mysql5.0以上版本的配置 修改主庫mysql配置配置文件，在[mysqld]段添加以下內(nèi)容： server-id = 1 log-bin=/home/mysql/logs/binlog/bin-log max_binlog_size = 500M binlog_cache_size = 128K binlog-do-db = adb binlog-ignore-db = mysql log-slave-updates expire_logs_day=2 binlog_format="MIXED" 1.3.各個(gè)參數(shù)的含義和相關(guān)注意項(xiàng)： server-id = 1 #服務(wù)器標(biāo)志號(hào)，注意在配置文件中不能出現(xiàn)多個(gè)這樣的標(biāo)識(shí)，如果出現(xiàn)多個(gè)的話mysql以第一個(gè)為準(zhǔn)，一組主從中此標(biāo)識(shí)號(hào)不能重復(fù)。 log-bin=/home/mysql/logs/binlog/bin-log #開啟bin-log，并指定文件目錄和文件名前綴。 max_binlog_size = 500M #每個(gè)bin-log最大大小，當(dāng)此大小等于500M時(shí)會(huì)自動(dòng)生成一個(gè)新的日志文件。一條記錄不會(huì)寫在2個(gè)日志文件中，所以有時(shí)日志文件會(huì)超過此大小。 binlog_cache_size = 128K #日志緩存大小 binlog-do-db = adb #需要同步的數(shù)據(jù)庫名字，如果是多個(gè)，就以此格式在寫一行即可。 binlog-ignore-db = mysql #不需要同步的數(shù)據(jù)庫名字，如果是多個(gè)，就以此格式在寫一行即可。 log-slave-updates #當(dāng)Slave從Master數(shù)據(jù)庫讀取日志時(shí)更新新寫入日志中，如果只啟動(dòng)log-bin 而沒有啟動(dòng)log-slave-updates則Slave只記錄針對(duì)自己數(shù)據(jù)庫操作的更新。 expire_logs_day=2 #設(shè)置bin-log日志文件保存的天數(shù)，此參數(shù)mysql5.0以下版本不支持。 binlog_format="MIXED" #設(shè)置bin-log日志文件格式為：MIXED，可以防止主鍵重復(fù)。 2、從庫的配置 2.1.mysql5.1.7以前版本 修改從庫mysql配置配置文件，在[mysqld]段添加以下內(nèi)容： server-id=2 master-host=192.168.1.2 master-user=repl master-password=1q2w3e4r master-port=3306 master-connect-retry=30 slave-skip-errors=1062 replicate-do-db = adb replicate-ignore-db = mysql 管理員在2009年8月13日編輯了該文章文章。 -->
|
|
|
