MySQL マスタースレーブレプリケーションプロセスの詳細な説明

1. マスタースレーブレプリケーションとは何ですか?

マスター データベースの DDL および DML 操作は、バイナリ ログ (BINLOG) を介してスレーブ データベースに転送され、これらのログが再実行 (再実行) されるため、スレーブ データベースのデータはマスター データベースとの一貫性が保たれます。

2. マスタースレーブレプリケーションの役割

1. マスター データベースに問題がある場合は、スレーブ データベースに切り替えることができます。

2. データベースレベルで読み取りと書き込みの分離を実行できます。

3. スレーブデータベースで毎日のバックアップを実行できる

3. コピープロセス

バイナリログ: メインデータベースのバイナリログ

リレーログ: サーバーからのリレーログ

ステップ 1:各トランザクションがデータの更新を完了する前に、マスターは操作レコードを binlog ファイルに連続的に書き込みます。

ステップ 2:スレーブは I/O スレッドを開始し、マスター上で通常の接続を開きます。その主なタスクは、バイナリログ ダンプ プロセスです。読み取りの進行がマスターに追いついた場合は、スリープ モードに入り、マスターが新しいイベントを生成するのを待機します。 I/O スレッドの最終的な目標は、これらのイベントをリレー ログに書き込むことです。

ステップ 3: SQL スレッドはリレー ログを読み取り、ログ内の SQL イベントを順番に実行して、メイン データベースのデータとの一貫性を保ちます。

4. マスタースレーブレプリケーションの具体的な操作

同じウィンドウの異なるパスに msyql のインスタンスを 2 つインストールしました。私の環境では不一致ですが、マスターとスレーブの MySQL のインストール バージョンは一致させることをお勧めします。

1. マスターデータベースとスレーブデータベースの設定ファイルmy.iniをそれぞれ変更します。

マスター

3306 は MySQL のデフォルトのポート番号で、マスター インスタンスで変更する必要はありません。server-id は、異なる MySQL インスタンスで重複してはならない一意の ID を指定するために使用されます。binlog-do-db は、コピーするデータベースを指定します。log-bin は、バイナリ ログ ファイルを開くために使用されます。

軟膏

マスターデータベースとスレーブデータベースは同じコンピュータ上で実行されるため、ポートは異なる設定にする必要があります。ここでは3307です。

replicate-do-db: 同期するデータベースの名前。マスター上の構成と一致している必要があります。

2. マスター上のレプリケーション専用のアカウントを作成します: weidai/123456

この新しく追加されたアカウントは、mysql.user テーブルでクエリできます。

初めて操作したときはここでアカウントの作成を完了しましたが、実際にコピーしてみると、コピーが成功していないことがわかりました。エラーを確認すると、マスターによって生成されたbinlongは正常であることがわかり、次にスレーブのステータスを確認しました。

最後にエラー行があります:

weidai アカウントを使用してマスターに接続できないため、マスターの binlog が取得されず、リレー ログを生成できません。

アカウントとパスワードを何度も確認しましたが、問題は見つかりませんでした。次に関連情報を探したところ、マスターで新しいユーザーを作成するときに手順を忘れたためであることがわかりました。

新しいユーザーを設定したり、パスワードを変更したりした後は、フラッシュ権限を使用して MySQL システム権限関連のテーブルを更新する必要があります。そうしないと、アクセスが拒否されます。これが先ほどのエラーの原因です。別の方法としては、新しい設定を有効にするために MySQL サーバーを再起動することです。

3. マスター データベースの現在のデータ位置を取得します。これは主に、スレーブ データの開始後にデータの開始位置をコピーするために使用されます。ただし、このステータス値を取得する前に、マスター データベースはデータを変更できないため、最初に読み取りロックを有効に設定する必要があります。

4. メインデータベースはデータのバックアップを実行します。データのバックアップ方法はたくさんあります。ここでは紹介しません。前回の記事を参照してください。バックアップが完了すると、読み取りロックが解除され、メインデータベースは書き込み操作を実行できるようになります。

5. スレーブ データベースを起動し、バックアップしたデータを復元します。この時点で、バックアップ時点のマスター データベースとスレーブ データベースのデータは一致しています。

6. スレーブデータベース上のレプリケーション動作の関連構成

7. この時点で構成は完了していますが、スレーブデータベースはまだ同期できず、スレーブスレッドを開始する必要があります。

8. マスターにテーブルを作成し、新しいデータを追加し、スレーブで確認します。

マスターで行った操作がスレーブに反映されることがわかります。このとき、スレーブはマスターのミラーのようなものです。

5. マスタースレーブ同期ステータスの解釈

スレーブ上で表示するには次のコマンドを使用します。

レイアウトがあまりにも醜いので、次のように整理しました。

Slave_IO_STATE: マスターがイベントを送信するのを待機しています

マスターホスト:127.0.0.1

マスターユーザー:weidai

マスターポート:3306

接続再試行:60

マスターログファイル:mysql-bin.000005

読み取りマスターログ位置:1662

リレーログファイル:AE6Z*****-リレーbin.000002

リレーログ位置:1415

スレーブIO実行中: はい

スレーブSQL実行中: はい

---------------------------------------------------------- ゴージャスな分割線------------------------------------------

スレーブIO実行中: はい

スレーブSQL実行中: はい

前述したように、これら 2 つのスレッドは、スレーブ上のレプリケーション プロセスに関係する非常に重要な 2 つのスレッドです。 YESは正常、NOは異常を意味します。

Slave_IO スレッドは、主にマスター上の binlong ログの内容をスレーブのリレー ログ (Relay_log) にコピーします。通常、問題が発生する可能性は高くありません。問題のほとんどは、権限またはネットワークの問題によって発生し、マスターに接続できなくなります。まさに上記のエラーと同じです。

Slave_SQL スレッドはリレー ログ内の SQL を実行する役割を担っており、エラーが発生する可能性が比較的高くなります。たとえば、誰かが手動でスレーブ データベースにレコードを挿入すると、マスターとスレーブの同期中に主キーの競合が発生する可能性があります。

Slave_IO_STATE: マスターがイベントを送信するのを待機しています

このステータスは、リレー ログの同期が完了し、マスターによって新しいイベントが生成されるのを待機していることを示します。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。