そのため、MySQLのグループレプリケーションはMySQL 5.7で生まれました。
人々がそれについてもっと質問し始めている間今それは少し出ています。
3 件中 1 - 3 件を表示
Jun
17
2019
Aug
08
2016
ログポジションベースのレプリケーションの場合は、レプリケーション障害発生時にスレーブでSKIP処理を容易に行う事ができましたが、GTIDモードの場合は以下のように空のトランザクションを実行して、エラー対応をする必要がありました。
mysqlslavetrxを利用しない場合の例
root@localhost [sakila]> stop slave; Query OK, 0 rows affected (0.03 sec) root@localhost [sakila]> SET GTID_NEXT = "3edaa0b8-3e39-11e4-9df1-080027f5bf08:54"; Query OK, 0 rows affected (0.00 sec) root@localhost [sakila]> begin; commit; Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) root@localhost [sakila]> SET GTID_NEXT = "3edaa0b8-3e39-11e4-9df1-080027f5bf08:55"; Query OK, 0 rows affected (0.00 sec) root@localhost [sakila]> begin; commit; Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) root@localhost [sakila]> SET …[さらに読む]
Dec
25
2014
メリークリスマス!!やあ、良い子のみんな!!サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ!!
というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。
前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID(Global Transaction ID)である。
GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOで
3 件中 1 - 3 件を表示