Docker ベースの MySQL マスタースレーブ レプリケーションを実装する方法

序文

MySQL マスター/スレーブ レプリケーションは、アプリケーションの高パフォーマンスと高可用性を実現するための基盤です。集中的なデータベース読み取り操作を行うアプリケーションの場合、データベース要求を異なる MySQL サーバーに負荷分散することで、データベースの負荷を効果的に軽減できます。 MySQL で単一点障害が発生した場合、短時間でフェイルオーバーを実現できます。この記事では、MySQL の組み込みレプリケーション機能について説明します。

バージョン

• MySQL: 5.7.17
• セントOS: 7.4.1708
• ドッカー: 1.13.1

概要

MySQL レプリケーション データ プロセス:

1. マスター データベースは、データ更新後にトランザクションをコミットする前に、イベントを binlog バイナリ ログ ファイルに非同期的に記録します。ログ記録が完了すると、ストレージ エンジンがトランザクションをコミットします。
2. スレーブは I/O スレッドを開始してマスターとの接続を確立し、マスターでバイナリログを更新するように要求します。このとき、メインライブラリによって作成される binlog dump スレッドはバイナリダンプスレッドです。新しい更新イベントがある場合は、I/O スレッドに通知します。スレッドがバイナリログのダンプを完了し、新しいログがない場合は、スレッドはスリープ状態になります。
3. ライブラリのI/Oスレッドから新しいイベントログを受信した後、それを独自のリレーログに保存します。
4. スレーブ SQL スレッドはリレー ログからイベントを読み取り、更新を実行して保存します。

マスタースレーブライブラリを構成する

メインライブラリのmy.cnf設定

マスター データベースの my.cnf ファイルでバイナリ ログを有効にし、サービス ID を設定します。

ログ bin = mysql bin
サーバーID = 1

server-id は一意の番号である必要があり、マスターとスレーブ間で異なる必要があり、マスター データベースとスレーブ データベースに対して設定する必要があることに注意してください。

ライブラリ my.cnf から設定する

ログ bin = mysql bin
サーバーID = 2
ログスレーブ更新 = 1
読み取り専用 = 1

スレーブ ライブラリは、log-bin も開き、log-slave-updates を設定して、スレーブ ライブラリがリレー ログを再生するときに、リレー ログを独自のバイナリ ログに記録します。これにより、スレーブ ライブラリは他のサーバーのマスター ライブラリとして機能し、バイナリ ログを他のスレーブ ライブラリに転送できます。このソリューションは、1 つのマスターと複数のスレーブのソリューションを実行するときに検討できます。

DockerfileはMySQLイメージを構築します

必要なファイルを構築する

ここでは、マスター ファイルとスレーブ ファイルは別々に保存され、共有されません。まず、/usr/local/mysql フォルダーを作成し、次にそのディレクトリ内にマスターとスレーブの 2 つのディレクトリを作成し、それぞれにデータ フォルダーを作成します。

• データディレクトリはデータファイルを保存するために使用されます
• DockerfileはDockerfileの内容を保存します
• init.sql データベースを初期化するSQL
• my.cnfデータベース設定ファイル、設定方法は上記に記載されています
• MySQL を構築するための start.sh Dockerfile スクリプト

Dockerfileの内容

# mysql イメージ FROM mysql:5.7.17 を使用して新しいイメージを作成します

ENV MYSQL_ROOT_PASSWORD ytao

コピー start.sh /mysql/start.sh
my.cnf をコピー /etc/mysql/my.cnf 
init.sql をコピー /mysql/init.sql

エクスポーズ3306
コマンド ["sh", "/mysql/start.sh"]

ここでのマスターとスレーブは同じイメージに基づいて構築されており、使用されるストレージ エンジンとその他のコンポーネントは同じである必要があります。そうでない場合、レプリケーション プロセス中に例外が発生する可能性があります。

init.sqlはデータを初期化します

-- data_copy データベースを作成します。DROP DATABASE IF EXISTS `data_copy`;
CREATE DATABASE `data_copy` /*!40100 デフォルト文字セット utf8mb4 collat​​e utf8mb4_general_ci */;

-- person テーブルを作成します USE `data_copy`;
`person` が存在する場合はテーブルを削除します。
テーブル「人」を作成します（
 `id` int(32) NULLではない、
 `name` varchar(255) デフォルト NULL,
 主キー (`id`)
)ENGINE=InnoDB デフォルト文字セット=utf8mb4;

data_copy データベースと person テーブルを作成します。

start.sh スクリプト

#!/bin/sh
echo 'mysql を起動'
サービスmysql開始
睡眠5

echo 'データベースを初期化します'
mysql -uroot -pytao < /mysql/init.sql
echo '初期化が完了しました! '
テール -f /dev/null

マスターイメージとスレーブイメージをビルドし、コンテナを実行する

マスターイメージを構築する

マスター/mysql を実行します。

スレーブイメージをビルドする

ビルド -t スレーブ/mysql 。

ビルドが成功するとSuccessfulyが返されます。またはdocker imagesコマンドでイメージを表示することもできます。

先ほど作成したイメージを使用してコンテナを実行します。

# マスターコンテナ docker run --name master -p 3306:3306 -v /usr/local/mysql/master/data/:/var/lib/mysql -d master/mysql

# スレーブコンテナ docker run --name slave -p 3307:3306 -v /usr/local/mysql/slave/data/:/var/lib/mysql -d slave/mysql

マスター ポートを 3306、スレーブ ポートを 3307 に指定し、データ ディレクトリをデータが保存されるディレクトリとしてマウントします。

データベースに接続した後、データベースが正常に初期化されているかどうかを確認します。

log-binが有効になっているか確認する

レプリケーションアカウントを作成する

前述したように、スレーブ I/O スレッドはマスターとの接続を確立する必要があるため、検証にはアカウントが必要です。アカウントには、接続権限 (REPLICATION CLIENT) に加えて、レプリケーション権限 (REPLICATION SLAVE) も必要です。

'ytao' によって識別される muser@'%' に、*.* 上のレプリケーション クライアント、レプリケーション スレーブを許可します。

ここで設定したアクセスアドレスは公開されており、セキュリティ上の理由から、実際の使用時にはアクセスアドレスを指定する必要があります。

リポジトリからコピーを開始する

スレーブ データベースをマスター データベースに接続し、バイナリ ログを取得して再生します。ここでは、まず上記で作成したアカウントを接続して構成し、コマンドを使用して対応する設定を行う必要があります。

マスターを変更 
MASTER_HOST = '47.107.xx.xxx'、
マスターポート = 3306、
MASTER_USER = 'muser'、
MASTER_PASSWORD = 'ytao'、
MASTER_LOG_FILE = 'mysql-bin.000006';

この時点ではまだコピーは開始されていないので、ライブラリから再度開始する必要があります。

スレーブを起動します。

起動後のステータスを表示するにはSHOW SLAVE STATUS\G;コマンドを使用します。

上記の Slave_IO_Running: Yes および Slave_SQL_Running: Yes とマークされた出力情報は、I/O スレッドと SQL スレッドが開始され、実行中であることを示しています。

テスト同期データ

マスター データベースでデータが追加、更新、または削除された場合、スレーブ データベースでもマスター データベースに対応するデータの変更が反映される必要があります。

メインデータベースにデータを追加する

`data_copy`.`person` (`id`, `name`) に VALUES ('1', 'ytao') を挿入します。

スレーブ データベース データを照会すると、データが同期されています。

要約する

上記は最もシンプルで基本的な構成ですが、上記の構成プロセスを理解していれば、自分の状況に応じてさまざまなソリューションをカスタマイズしたり、1 つのマスターと複数のスレーブ、マスター マスター レプリケーション (アクティブ アクティブまたはアクティブ パッシブ モード) などを実装して、自分のニーズを満たすことができます。

MySQL レプリケーションはシンプルで使いやすいですが、異常なサーバーシャ​​ットダウンからの回復が不可能、データ同期の遅延など、使用中に解決する必要がある問題もいくつかあります。幸いなことに、現在遭遇している問題のほとんどは、業界で適切に解決されています。この点に関心のある方は、現在これらの問題を解決しているミドルウェア実装ソリューションについて学ぶことができます。

さて、今回の記事は以上です。この記事の内容が皆さんの勉強や仕事に少しでも参考になれば幸いです。123WORDPRESS.COM をよろしくお願いいたします。