GTID（グローバルトランザクション識別子）を備えたmysql 5.6のリリース後、mysqlでのレプリケーションはシステム管理者の悪夢ではなくなり、非常に有効なツールになりました。 インターネットにはこの主題に関する情報がいくつかありますが、それらはすべて散在しており、理解のために常にアクセスできるとは限りません。 したがって、私は自分自身のために、少し絞った指示を出すことにしましたが、他の誰かが役に立つかもしれません。
セットアップウィザード
私はかなり温室条件があり、ベースが空です、構成後にダンプを注入します
my.cnf
binlog-format = ROW
STATEMENT、MIXED、およびROWの3つのタイプがあります
一言で言えば-ステートメントは本質的にsqlクエリをbinlogに書き込みます。 利点-古い形式、テスト済み、ログが小さく、リクエストを確認できます。 欠点-関数とトリガーの問題、フォーム更新ユーザーの要求がrand（）によるa = 1の順序を設定するなど、さらにいくつかが誤って処理される可能性があります。 ROWは、完全に簡略化されている場合、変更されたバイナリデータをログに書き込みます。 利点-すべてのタイプのリクエストが完全に記録されます。 欠点は巨大なログであり、まあ混合は中間ステートメントであり、可能な場合は行が使用し、そうでない場合は行を使用しようとします。 彼らは、いくつかの非常に複雑なクエリではバグがあると言います。 私が使おうとしたのは彼だった
binlog-checksum = crc32
新しいmysql5.6機能、binlogの作業を高速化するようです
gtid-mode = on
実際には、同じGTIDモードのレプリケーションが含まれています
強制-gtid-consistency = true
トランザクションを中断する可能性のあるものはすべて禁止します。
log-slave-updates = true
ネイティブのドキュメントに記述されています。スレーブサーバーで発生した更新の記録をバイナリログに保持するようスレーブサーバーに指示します。 デフォルトでは、このオプションは無効になっています。 スレーブサーバーをデイジーチェーンで編成する場合に含める必要があります。
サーバーID = 1
サーバーごとに一意の番号
まあ、何を複製するかを正確に示すことを忘れないでください-
replicate-do-db = mybase
replicate-do-table = mybase.mytable1
replicate-do-table = mybase.mytable2
その後、複製権を持つmysqlユーザーを作成します。 たとえば、 GRANT replication slave ON *。* TO "replication" @ '192.168.1.102' IDENTIFIED BY 'password';
これでウィザードのセットアップが完了しました。 ダンプを戦いに注ぐ）
スレーブ設定
最も単純なバージョンでは、ウィザードと同じ構成をスレーブにコピーできます。唯一のことは、server_idを2に変更する必要があることです。
スレーブを再起動し、レプリケーションを開始します。
masterをmaster_host = '192.168.1.1 "、master_auto_position = 1、Master_User =' replication '、master_password =' password 'に変更します。
スレーブを開始します。
そして楽しむ
スレーブの状態を表示\ G
Mysql 5.6でのレプリケーションの構成
All Articles