Docker ベースの MySQL マスタースレーブレプリケーション環境を構築するための実装手順

1. はじめに

以前のプログラムアーキテクチャは次の形式になります。

プログラムのサイズが大きくなると、複数のバックグラウンドサービスインスタンスに拡張する可能性がありますが、データベースはまだ 1 つしかないため、システムのボトルネックは依然としてデータベースにあります。そのため、今回の主なタスクはデータベースの拡張です。主な形式は、複数のデータベースインスタンスを拡張し、読み取りと書き込みの分離を実現し、一部の書き込みタスクをメインデータベースに割り当て、サブデータベースを読み取りタスクに使用するというものです。これによりシステムのパフォーマンスが向上します。

変更されたアーキテクチャは次のとおりです。

2. 建設前の環境

今回は環境構築にDockerを使用し、MySQLのバージョンは5.7.13を使用しています。

docker pull mysql:5.7.13

全体的な構造は次のとおりです。

書き込みノードとして機能する 1 つのマスターノード。
2 つのスレーブノードが読み取りノードとして機能します。

まず、これらのノードを個別に起動し、異なるポートにマップします。このマシンのデータベース接続ツールを使用して接続し、正常に起動および接続されているかどうかをテストします。

docker run -p 3307:3306 --name mysql-master -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7.13
docker run -p 3308:3306 --name mysql-slave1 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7.13
docker run -p 3309:3306 --name mysql-slave2 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7.13

ここでは、マスターノード (mysql-master) をポート3307にマップし、2 つのスレーブノード (mysql-slave1、2) をそれぞれポート3308と3309にマップします。次に、MySQL のルートパスワードを123456に設定します。

その後、 navicatなどのツールを使用して接続し、MySQL をテストできます。

これらのノードにそれぞれ入り、構成ファイルを編集します。

docker exec -it mysql-master /bin/bash

コンテナに入るには名前を使用しますが、ID に応じて選択することもできます。つまり、 docker exec -it 對應容器的id /bin/bash 。

viおよびvimプログラムはプリインストールされていないため、ダウンロード時にapt updateコマンドを実行し、外部ソースからダウンロードする必要があります。よく知られている理由により、速度は非常に遅いです。ダウンロード元を国内のものに変更しました。

/etc/aptフォルダに入り、まず元のファイルをバックアップします。

mv ソース.リスト ソース.リスト.bak

次に、次のコマンドを使用して新しいファイルを作成し、その内容を入力します。

echo deb http://mirrors.aliyun.com/ubuntu/ xenial メイン 制限付き宇宙 マルチバース > ソースリスト

次にapt updateなどの操作を実行し、最後にvimをインストールします。

3. マスタースレーブ構成を実行する

マスターノードの構成

マスターノードコンテナに入った後、 /etc/mysqlフォルダに入ると、主に変更されるmy.cnfファイルがあります。

このファイルを編集し、 [mysqld]を見つけて、その下に次のコマンドを追加します。

[mysqld]
...
...
## 一意の番号 server-id=101
## これは重要な設定項目です log-bin=mysql-bin

設定が完了したら、設定を有効にするために MySQL サービスを再起動する必要があります。再起動するには、 service mysql restartコマンドを使用します。再起動が完了すると、MySQL コンテナは閉じられます。コンテナdocker restart mysql-masterも再起動する必要があります。

スレーブ構成

マスターノードと同様に、 /etc/mysql/my.cnfファイルを編集します。

[mysqld]
...
...
## 一意の番号 server-id=103
## 選択してください。このノードを他のノードのマスターノードとして使用する必要がある場合は、# log-bin=mysql-bin を追加する必要があります。

マスターノードとスレーブノードのリンク

マスターノード

マスターノードコンテナでMySQL mysql -u root -pと入力します。パスワードはコンテナの起動時に設定した123456です。

MySQLに入ったら、 show master status;を実行します。

ここから、 FileとPositionという 2 つの情報の値を取得します。それぞれmysql-bin.000001と154です。

スレーブノード

MySQLに入り、次のコマンドを実行します。

マスターを、master_host='***'、master_port=3306、master_user='root'、master_password='123456'、master_log_file='****'、master_log_pos= *** に変更します。

これらのパラメータがそれぞれ何を意味するのか説明してください。

master_host: マスターノードの IP アドレス。このマシンで次のコマンドを使用して、コンテナーの IP アドレスを表示できます。

docker examine --format='{{.NetworkSettings.IPAddress}}' コンテナ名 | コンテナ ID

master_port: 外部にマップされたポート番号ではなく、mysql のポート番号

master_user: mysqlのユーザー。権限が必要です。私は直接rootを使用しましたが、新しいユーザーを作成して使用することもできます。

master_password: 同期に使用するMySQLアカウントのパスワード

master_log_file: 同期に使用されるファイル、つまりマスターノードからクエリされたファイル。ここではmysql-bin.000001です。

master_log_pos: バイナリログファイルの同期を開始する位置。マスターノードからクエリされた位置です。私の場合は154です。

先ほどのコマンドを実行した後、MySQL ターミナルでshow slave status \G;を実行して、マスターとスレーブの同期ステータスを表示します。

ここで構成情報を確認すると、2 つの属性slave_io_runningとslave_sql_runningが両方とも no になっていることがわかります。つまり、これらは閉じられていることを意味します。

start slaveを実行して、マスタースレーブレプリケーションを開始できます。実行後、 show slave status \G;コマンドを再度実行して、両方の属性がyesになっていることを確認します。これは、マスタースレーブレプリケーションが有効になっていることを示します。

起動に失敗した場合は、ネットワークが接続されているかどうか、同期に使用した mysql パスワードが正しいかどうか、同期ファイルの名前と場所が正しいかどうかを確認できます。

テスト

マスターデータベースに新しいデータベースを作成できます。スレーブデータベースにこのデータベースが存在する場合、マスターとスレーブの同期が完了したことを意味します。

4. カスケード構成

別のバックアップノードを追加し、このノードをスレーブ 1 ノードからバックアップします。つまり、スレーブ 1 ノードはバックアップノードのマスターノードとして機能します。これにより、マスター -> スレーブ -> バックアップのカスケード関係が形成されます。

私はもともと上記の手順に従い、それをスレーブのmy.cnfに追加しました

log-bin=mysql-slave-bin #区別するためにファイル名を変更しました

次にバックアップノードで実行します

マスターを、master_host='***'、master_user='root'、master_password='123456'、master_port=3306、master_log_file='****'、master_log_pos= *** に変更します。

コマンドは、対応するスレーブノードの IP およびその他の属性に置き換えられます。それは機能しないことが判明しました。プライマリノードが変更されても、バックアップノードは変更されません。

そこで調査してみると、スレーブノードのbinlogファイルには変更された情報の記録がなく、バックアップノードはこのファイルの変更を監視しているのと同等であることがわかりました。このファイルが変更されていなければ、バックアップノードには変更がないことになります。これをもう少し詳しく説明しましょう。MySQL の binlog はすべての変更を記録するので、理論的にはいつでも binlog を使用してデータベースの内容を復元できます。

したがって、マスターノードが変更された後にスレーブノードの binlog ログをどのように記録するかが問題になります。

my.cnfファイルを編集するときに、 log_slave_updates=1別の行を追加できます。これにより、スレーブはマスターから同期を受け取った後、バイナリログを独自の binlog にも書き込むようになります。

可能です。マスターノードが変更されると、スレーブノードとバックアップノードも変更されます。バックアップノードのデータはスレーブノードからバックアップされます。

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

以下もご興味があるかもしれません: