關於在產品環境中使用 MySQL5.6 GTIDs 的相關問答

這是一篇關於在產品環境中使用 MySQL 5.6 GTIDs 的相關問答的文章，相信會對你有所幫助，一起看看吧！

Q:在master-master結構中GTID有什麼優勢?如果有, 它是如何做的?  Q:GTID可以應用到MySQL的ACTIVE ACTIVE MASTER MASTER結構上嗎?

A:GTID不會改變MySQL數據備份的本質:比如在配置GTID之後,數據備份同樣是異步的;如果向master-master結構上的兩個master寫入數據,GTID同樣沒有寫沖突檢測機制.GTID的主要優勢在於能夠很容易的改變數據備份的拓補結構,當連接一個slave節點到新的master節點時不再需要為了找到正確的binlog的位置而做一些復雜的計算.

在master-master數據備份的結構中可以配置GTID, 相對於基於位置的數據備份,GTID並不沒有很多的優勢,因為你不會改變數據備份的拓補結構.

GTID同樣不推薦在兩個master都可接受數據的結構中向兩個master都寫入數據.

Q:GTIDs在主機：備用主機上運行的好嗎？失效備援有多快？

A：是的，GTIDs能夠很好的處理這種類型的設置(一個主機一個備機)。GTIDs不提供失效備援，必須使用一個額外的工具才行。失效備援的速度取決於使用的工具。

Q:對於已經建立的MASTER-MASTER/MASTER-SLAVE復制，在GTID設置後，我們需要使用 AUTO POS=1重新建立復制，對嗎？

A:是的，使用 MASTER_AUTO_POSITION=1 是需要指出將要使用GTID復制。所以必須運行：STOP SLAVE; CHANGE MASTER TO … MASTER_AUTO_POSITION = 1; START SLAVE;

Q: GTID是怎麼處理那些應用的，這些應用擁有來自不同引擎(比如：InnoDB和MyISAM)的數據表?

A: 事務不能同時用於MyISAM和InnoDB表,請參照文檔.

Q:在master-slave備份的拓補結構(GTID是可用的)中,如果master節點上的二進制日志被刪除,並且使用AUTO_POSITION=1改變了master命令的情況下, slave節點是怎麼從master節點上獲取數據的?

A: 備份將被中斷,並拋出1236錯誤.

Q: 在slave節點上有什麼值表示該節點的數據滯後了?

A: 是用Seconds_Behind_Master表示的.雖然它不是非常可靠.比如你有一個這樣的備份序列 A -> B -> C, 在C節點上的Seconds_Behind_Master表示的滯後是相對於B節點，而不是A節點.

Q: 保存先前的master的GTIDs有何意義呢?這些GTIDs是在show slave status顯示的Executed_Gtid_Set中執行的.

A: 新的復制協議保證,當slave連接到它的master的時候,slave將已經執行的一定范圍的GTIDs發送給master.然後,master發送所有其他的事務給slave.這就是為什麼Executed_Gtid_Set包含了所有已執行的事務的歷史信息.

Q: 我們在服務器上使用DB Master和Slave VIPs, 那麼mysqlfailover工具也能切換VIP到新的master嗎?基於故障恢復的事件,可以腳本化嗎?

A: 是的,你可以使用拓展,通過mysqlfailover工具來增加自定義腳本.請查看–exec-before和–exec-after相關文檔.

Q: mysqlfailover工具如何處理Master和Slaves之間網絡不穩定的情況?

A: mysqlfailover工具,只是在它認定master不再存活的情況下,觸發故障恢復.所以,在master和slaves之間網絡不穩定的情況,不會影響它對master崩潰的檢測.但是,當一個或者多個slave不可到達的情況下,在故障恢復/正常切換時,它會阻止工具重新正確配置復制過程.

Q: Facebook使用MySQL的GTID嗎? 如果是的話, 具體是哪個模塊,還是所有的呢?

A: 我無法代表Facebook發言,但是在今年的MySQL會議的this talk之中,他們暗示在產品中使用GTIDs.他們已經增加了個性化的代碼,以便讓GTIDs更易於使用.

Q: GTID_SUBSET是MySQL工具包的一部分嗎?或者說我們需要寫一個腳本來定期的檢測它嗎?GTID_SUBSET的優勢也能體現在ACTIVE ACTIVE MASTER MASTER架構中嗎?

Q: 你能確認getid方法是如何得到gitd集合的嗎?

A: GTID_SUBSET()是MySQL 5.6的內置功能, 你不需要額外的工具包. 從它能夠很容易的知道指定的server的Executed_Gtid_Set是不是另一台server Executed_Gtid_Set的一個子集,所有在任何備份拓補結構中都可以使用它.

Q: HOLE和BUGS之間的區別是什麼?

A: 在實現了GTID的MySQL 5.6中是沒有漏洞的,如果你遇到了所謂的漏洞,其實它是一個bug.

Q: 使用MySQL工具包, 我們也可以使用一條python命令來安裝備份. 它能自動的獲得master到slave節點的dump 並且啟動備份嗎? 如果能, 可以用shell腳本在後台備份300GB的數據嗎? 還是它只能在當前位置開始備份不能收集dump信息?

A: 我認為你討論是的mysqlreplicate. 這個工具有CHANGE MASTER TO模式, 所以它沒有任何形式的備份.

Q: mysqlfailover腳本有可能在任何節點(比如slave節點)的任何時間知道當前可用的節點是master還是其他的slave節點嗎? 如果不能, 有其他的方法可以做到嗎?

A: 你可以用mysqlrplshow.

Q: 正如前面說所,MySQL工具在故障自動轉移上存在局限性, 但我想把故障自動轉移作為首選項, 我該怎麼做呢?

A:如果運行mysqlfailover的節點故障了,故障自動轉移的功能就會失效.所有這個節點不是非常可靠. 如果故障自動轉移對你很重要,你可以嘗試下面的幾種方法: 小心監控你的監控節點, 或者使用像Percona Replication manager的解決方法使用Pacemaker, 或是像Percona XtraDB Cluster那樣用Galera備份.

Q: 我們可以在slave節點或者其他監控節點上使用mysqlrpladmin failover/switchover命令嗎?

A: 可以的, 只要server上安裝了mysqlrpladmin, 並且mysqlrpladmin能夠連接到數據庫, 就可以在任何地方執行這個命令.

Q: 如果我們設置slave為只讀…是否建議刪除錯誤事務？

A:是的，建議刪除。不過這不阻止用戶使用SUPER權限在slave上意外寫入。

Q:這些錯誤事務問題可以用(active-passive) master-master復制阻止嗎？

A:Master-master復制將確保任何事務寫入一個服務將自動結束在另一個slave上寫入。所以它就像在避免錯誤事務。不過不建議在兩個master上寫入，因為你會遇到寫沖突。

Q:在MHA上使用GTID有什麼實用的優勢嗎？

A:GTID不提供任何方法執行failover，他們只是簡化你怎樣重新配置復制。所以使用MHA利用GTID是有意義的。

Q: GUID 和 GTID的區別是什麼？什麼時候我們必須使用GUID 和 GTID？

A:我不確定我是否正確的理解了這個問題。GTID由源 id 和事務 id 組成。源 id 是master的server_uuid，是當MySQL首次啟動時自動生成的 GUID。

Q:怎樣檢查slave數據庫表和記錄？我們必須從master到salve數據庫同步數據還是自動進行？

A:你可以使用Percona工具包的 pt-table-checksum 和 pt-table-sync。

以上就是精品為大家整理的關於在產品環境中使用 MySQL 5.6 GTIDs 的相關問答，希望對大家有所幫助。