MySQL Casual Talks vol.13
MySQL Casual Talks vol.13
たまには新しい技術じゃなくて、ちょっと前に学んだ技術についても、 復習の意味を兼ねて書いてみます。 今回のテーマはGTIDレプリケーションです。 MySQLのレプリケーションは非常に簡易で便利な高可用性ソリューションですが、 ・間違ってスレーブでクエリを実行してしまった ・マスターのバイナリログが欠損した ・バグを踏んだ などの理由で、レプリケーションが崩れてしまった! ということを経験した方も多いのではないでしょうか。 特に、5.6から導入されたGTIDレプリケーションについては、 まだそれほどノウハウがたまっていない、ということもあるかと思うので、 今回は、GTIDレプリケーションの復旧方法について書いてみました。 復旧方法として、一番シンプルなのは、 スレーブのデータディレクトリを一旦削除し、 マスターのデータディレクトリと置き換えることです。 この方法は、シンプルで間違いがないです
今回は、MySQL/MariaDB GTID レプリケーションの詳細を説明します。これは、Transactdによるレプリケーションセットアップ(修復)ツールを構築する際に調べたものです。 主に従来のバイナリログとポジションを使ったレプリケーションとGTIDによるレプリケーションの違いについて説明します。ある程度従来のレプリケーションのセットアップなどを理解していることを前提にしています。 Index なぜGTIDが必要なのか GTIDが活きるシナリオ GTIDによるポジションの解決 具体的なGTID GTIDを使うための設定 MariaDBでGTIDを使う 2つのGTIDポジションモード 新規セットアップ スレーブで、マスターを新マスターに切り替える ダウンしたマスターをスレーブ群に加える SQLスレッドのエラーを修復する MySQLでGTIDを使う GTIDセット GTIDセットの表現方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く