MySQL完成批量拔出以優化機能的教程。本站提示廣大學習愛好者：（MySQL完成批量拔出以優化機能的教程）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL完成批量拔出以優化機能的教程正文
MySQL5.6有許多新的特征，個中許多人都感興致的一條就是全局事務序號功效（GTIDs）。而年夜家都對這一特征很感興致的緣由也很好懂得，即：原來從新銜接從辦事器和一個新的主辦事器一向是件很費事的事，但是在啟用GTIDs功效以後就變得簡略易行。可是，GTIDs的應用不單單是用零丁的標識符調換舊的二進制日記文件/地位，它也采取了新的復制協定。假設你還不太明確這些，那你可以在這篇文章裡學點甚麼。
復制協定：新的 VS 舊的
舊的協定常常簡略直接即：起首從辦事器上在一個特定的偏移量那邊銜接到一個給定的二進制日記文件，然後主辦事器在從那邊發送一切的事務。
新協定稍有分歧：slave起首會發送它曾經履行過的GTID的規模，然後master發送每個喪失的事務. 它也確保了一個給定的GTID只可以在一個特定的slave中履行一次.
理論中，這會轉變任何器械嗎? 使得，它會轉變許多器械. 想象一下上面的場景: 你想要從trx 4開端復制，然則trx2在slave上由於某種原因喪失了.
應用老協定的話，trx 2不再會被履行一次，而應用新協定，它就會被主動的再履行一次.
上面是兩個你可以在理論中看到新協定的通用處景.
跳過事務
盡人皆知老的 SET GLOBAL sql_slave_skip_counter = N 在你想要跳過一個事務時不再供給支撐，而GTID便可以被啟用了. 換用 GTID XXX:N 來跳過事務, 你須得 注入一個空的事務:
mysql> SET gtid_next = 'XXX:N'; mysql> BEGIN; COMMIT; mysql> SET gtid_next = 'AUTOMATIC';
為何我們不克不及應用 sql_slave_skip_counter? 就是由於新的復制協定!
想象一下我們具有以下圖所示的三台辦事器:
讓我們假定 sql_slave_skip_counter 可以用而且曾經被用在S2上用於跳過trx2. 假如你吧S2設置成S1的一個slave將會產生甚麼呢?
兩個辦事器會相互交流被履行了GTID的規模，而且S1將會心識到其必需將trx2發送給S2. 然後會產生的工作有兩種能夠:
很顯著這不平安，這就是為何 sql_slave_skip_counter 在應用GTID時是不克不及用的. 要想跳過一個事務，獨一平安的選擇就是去履行一個虛擬的事務，而不是一個真實的事務.
毛病的事務
假如你在一個slave上當地履行了一個事務 (在MySQL文檔中被稱為毛病事務), 假如你被這個事務推送到新的master上時會產生甚麼呢?
應用老協定，根本上沒啥事（精確點說，新的master和其slave之間的數據將會湧現紛歧致，但那在稍後便可能會被修復）.
應用新協定，毛病的事務將會被辨認成為在每一個處所都喪失了，而且將會主動在容錯備份上被履行，如許就將會招致打斷復制的隱患.
比喻說，你具有一個master（M)和兩個slave (S1 和 S2). 這裡有兩種將slave重連到新的master將會產生（帶有分歧復制毛病的）掉敗的場景:
# 場景 1
# S1
mysql> CREATE DATABASE mydb;
# M
mysql> CREATE DATABASE IF NOT EXISTS mydb;
# Thanks to 'IF NOT EXITS', replication doesn't break on S1. Now move S2 to S1:
# S2
mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;
# This creates a conflict with existing data!
mysql> SHOW SLAVE STATUS\G
[...]
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 'mydb'; database exists' on query. Default database: 'mydb'. Query: 'CREATE DATABASE mydb'
[...]
# 場景 2
# S1
mysql> CREATE DATABASE mydb;
# Now, we'll remove this transaction from the binary logs
# S1
mysql> FLUSH LOGS;
mysql> PURGE BINARY LOGS TO 'mysql-bin.000008';
# M
mysql> CREATE DATABASE IF NOT EXISTS mydb;
# S2
mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;
# The missing transaction is no longer available in the master's binary logs!
mysql> SHOW SLAVE STATUS\G
[...]
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
[...]
你可以如許懂得，毛病的事務應當借助基於GTID的辦事得以免. 假如你須要運轉一個當地事務，最好的選擇是針對那條特定的語句禁用二進制日記:
mysql> SET SQL_LOG_BIN = 0; mysql> # Run local transaction
結論
GTIDs在讓我們便利從新和其他辦事器銜接正本方面是個不小的提高。但是異樣的在運維方面我們也是以面對新的艱苦和挑釁。假設你盤算開端應用GTIDs,那末你就得確切懂得新的復制協定，不然你就會以一種想不到的方法停止復制進程。
