MySQL マスタースレーブレプリケーションの実践の詳細説明 - ログポイントに基づくレプリケーション

ログポイントベースのレプリケーション

1. マスターデータベースとスレーブデータベースに専用のレプリケーションアカウントを作成する

MariaDB [従業員]> '123456' によって識別される 'repl'@'172.%' のユーザーを作成します。

運用中のパスワードは、一定のパスワード強度を達成するために関連する仕様を満たす必要があり、マスターデータベースにはスレーブデータベース上の特定のネットワークセグメントからのみアクセスできる必要があることに注意してください。

2. マスターデータベースとスレーブデータベースにレプリケーション権限を付与する

MariaDB [従業員]> *.* のレプリケーション スレーブを 'repl'@'172.%' に付与します。

3. メインデータベースを構成する

バイナリログを有効にするにはサービスを再起動する必要があります。server_id は、コマンドラインや構成ファイルと組み合わせて再起動不要の永続的な構成を実現できる動的パラメーターです。server_id はクラスター内で一意であることに注意してください。

[mysqld]
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
binlog_format = 行
サーバーID = 101

注: ログをデータから分離し、できれば異なるデータパーティションに分けることをお勧めします。

4. スレーブライブラリを構成する

オプション log_slave_update は、リレーログ relay_log をローカル binlog に保存するかどうかを決定します。リンクレプリケーションが構成されている場合は、このオプションが必須です。server_id はクラスター内で一意であることに注意してください。

[mysqld]
# レプリケーション
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
サーバーID = 102
# 奴隷
リレーログ = /var/log/mysql/リレー-bin
リレーログインデックス = /var/log/mysql/リレー-bin.index
リレーログ情報ファイル = /var/log/mysql/リレービン.info
log_slave_updates = オン
読み取り専用

5. ライブラリからデータを初期化する

ここでは、mysqldump を使用してマスターデータベースをバックアップします。本番環境では、ロックフリーのホットバックアップ (innodb エンジンに基づく) には xtrabackup を使用することをお勧めします。

従業員データベースのデータをメインデータベースにバックアップする

次のようにコードをコピーします。

 mysqldump --single-transaction --master-data=1 --triggers --routines --databases employees -u root -p >> backup.sql

バックアップファイルbackup.sqlをscpまたはdockerボリューム経由でスレーブサーバーにマウントし、スレーブライブラリにインポートします。

mysql -u ルート -p < バックアップ.sql

6. レプリケーションリンクを開始する

[email protected]と[email protected]があり、データはmysqldumpを通じてスレーブに同期されています。次に、スレーブサーバーでレプリケーションリンクを構成します。

MariaDB [(なし)]> マスターを MASTER_HOST='master'、MASTER_USER='repl'、MASTER_PASSWORD='123456'、MASTER_LOG_FILE='mariadb-bin.000029'、MASTER_LOG_POS=516 に変更します。
クエリは正常、影響を受けた行は 0 行 (0.02 秒)

スレーブでレプリケーションリンクを開始する

MariaDB [(なし)]> スレーブを起動します。
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

7. スレーブライブラリのスレーブステータスを確認する

Slave_IO_Running と Slave_SQL_Running は YES である必要があります。エラーが発生した場合は、Last_IO_Error または Last_SQL_Error のプロンプト情報を詳しく読んでください。

MariaDB [(なし)]> スレーブステータスを表示\G
************************** 1. 行 ****************************
        Slave_IO_State: マスターがイベントを送信するのを待機中
         マスターホスト: マスター
         マスターユーザー: repl
         マスターポート: 3306
        接続再試行: 60
       マスターログファイル: mariadb-bin.000029
     読み取りマスターログ位置: 516
        リレーログファイル: リレーbin.000002
        リレーログ位置: 539
    リレーマスターログファイル: mariadb-bin.000029
       スレーブIO実行中: はい
      スレーブSQL実行中: はい
       レプリケート_Do_DB:
     レプリケート_無視_DB:
      テーブルの複製:
    無視テーブルを複製:
   Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
          最終エラー番号: 0
          最終エラー:
         スキップカウンタ: 0
     実行マスターログポジション: 516
       リレーログスペース: 831
       Until_Condition: なし
        ログファイルまで:
        ログ位置まで: 0
      マスターSSL許可: いいえ
      マスターSSLCAファイル:
      マスターSSLCAパス:
       マスターSSL証明書:
      マスターSSL暗号:
        マスターSSLキー:
    マスターより遅れている秒数: 0
Master_SSL_Verify_Server_Cert: いいえ
        最終IOエラー番号: 0
        最後のIOエラー:
        最終SQLエラー番号: 0
        最後のSQLエラー:
 Replicate_Ignore_Server_Ids:
       マスターサーバーID: 101
        マスターSSL証明書:
      マスターSSLCrlパス:
          使用Gtid: いいえ
         Gtid_IO_Pos:
   ドメイン ID を複製:
 ドメイン ID を無視する複製:
        Parallel_Mode: 保守的
セット内の 1 行 (0.00 秒)

8. メインライブラリのダンプスレッドを確認する

binlogダンプスレッドが正しく開始されているかどうかを確認します

MariaDB [(なし)]> プロセスリストを表示 \G
************************** 1. 行 ****************************
   識別子: 7
  ユーザー: root
  ホスト: 172.20.0.1:41868
   db: 従業員
 コマンド: スリープ
  時間: 56
  州：
  情報: NULL
進捗: 0.000
************************** 2. 行 ****************************
   識別子: 10
  ユーザー: repl
  ホスト: 172.20.0.3:45974
   デシベル: NULL
 コマンド: Binlog ダンプ
  時間: 246
  状態: マスターはすべてのバイナリログをスレーブに送信しました。バイナリログが更新されるのを待機しています。
  情報: NULL
進捗: 0.000

2 行目でコマンド Binlog Dump が開始されていることがわかります。これは、レプリケーションスレッドが正常に開始されたことを証明しています。

9. まとめ

アドバンテージ