MySQL の組み込みレプリケーション機能を使用して可用性を最適化する (1)

mysql

MySQL の組み込みレプリケーション機能を使用して可用性を最適化する (1)

---

Soundbreak では 24 時間ライブのオーディオとビデオを再生しているため、MySQL の新しいレプリケーション機能を十分に活用することはできません。テストを通じて、この機能を使用してバックアップ データベース サーバーとのデータ同期を維持できることがわかりました。これにより、何らかの理由でメイン サーバーに障害が発生した場合でも、バックアップ マシンを使用してすべてのクエリを処理できるようになります。このような要件に対して、2 つのサーバーを構成することは難しくありません。プロセス全体について詳しく説明し、メインサーバーに障害が発生した場合に PHP を使用してクエリをリダイレクトする方法についても説明します。

MySQLの内部レプリケーション機能は、複数のサーバー間で確立され、サーバー間に主従関係を設定することで実装されます。そのうちの 1 つはマスター サーバーとして機能し、もう 1 つはスレーブ サーバーとして機能します。 2 つのサーバーを構成して、1 台をマスター、もう 1 台をスレーブにする方法について詳しく説明します。そして、それらを切り替えるプロセスについて説明します。 MySQL バージョン 3.23.23 で構成設定処理を実行し、このバージョンでテストも実施しました。 MySQL 開発者は、最新バージョンを使用することが最善であり、マスター サーバーとスレーブ サーバーの両方で同じバージョンを使用することを推奨しています。同時に、MySQL バージョン 3.23 はまだベータ版であり、このバージョンには下位互換性がない可能性があります。このため、実際の Web サイトでは、このバージョンはまだ使用していません。フォールト トレランスの利点の 1 つは、クエリを中断することなくサーバーをアップグレードできることです。

ステップ 1: メインサーバーを構成する
この記事の残りの部分では、2 つのサーバーを指定します。 A (IP は 10.1.1.1) がメイン サーバー (ホストと呼ばれます) として機能します。 B (IP は 10.1.1.2) はバックアップ サーバー (バックアップ サーバーと呼ばれます) として機能します。

MySQL のレプリケーション機能の実装プロセスは次のとおりです: スタンバイ マシン (B) がホスト マシン (A) に接続し、ホスト マシンのバイナリ更新ログを読み取り、変更を自身のデータベースにマージします。スタンバイ マシンにはホストに接続するためのユーザー アカウントが必要なので、ホスト上でアカウントを作成し、次のようにファイル権限のみを付与します。

スタンバイマシンがメインマシンに接続できるようにするには、メインマシンで「FLUSH PRIVILEGES」を実行する必要がありますが、次の手順でサーバーを停止しますので、心配しないでください。

ここで、ホスト データベースのスナップショットが必要になり、バイナリ更新ログの生成を許可するようにホストを構成します。まず、「my.cnf」ファイルを編集してバイナリ更新ログを許可します。そのため、[mysqld] セクションの下のどこかに「log-bin」という行を追加します。次回サーバーが起動すると、ホストはバイナリ更新ログ (名前: -bin.) を生成します。バイナリ更新ログを有効にするには、MySQL サービス プログラムをシャットダウンし、ホスト上のすべてのデータベース ディレクトリを別のディレクトリに移動して、mysqld を再起動します。
すべてのデータベースを取得していることを確認してください。取得していないと、コピー時にテーブルがメイン マシンに存在し、スタンバイ マシンに存在しない場合、エラーで終了します。これで、データのスナップショットと、スナップショットの取得以降にデータベースに加えられた変更のバイナリ ログが作成されました。 MySQL データ ファイル (*.MYD、*.MYI、および *.frm) はファイル システムに依存するため、Solaris から Linux へのようなファイル転送だけを行うことはできないことに注意してください。異種サーバー環境にいる場合は、mysqldump ユーティリティまたはその他のカスタム スクリプトを使用してデータのスナップショットを取得する必要があります。

ステップ 2: バックアップ マシンを構成する
続けてみましょう。スタンバイ マシンの MySQL サービス プログラムを停止し、ホスト マシンからコピーしたデータベース ディレクトリをスタンバイ マシンのデータ ディレクトリに移動します。ディレクトリの所有者とグループを MySQL ユーザーの対応する値に必ず変更し、ファイル モードを 660 (所有者とグループのみ読み取りおよび書き込み可能) に変更し、ディレクトリ自体を 770 に変更してください。 (所有者とグループのみ) 読み取り、書き込み、実行可能)。

続きます。バックアップ マシンで MySQL サービス プログラムを起動し、MySQL が適切に動作していることを確認します。いくつかの選択クエリを実行して (クエリの更新や挿入は行わないでください)、最初の手順で取得したデータ スナップショットが成功したかどうかを確認します。次に、テストが成功したら、MySQL サービス プログラムをシャットダウンします。

ホストからの変更を受信するには、スタンバイ マシン上でアクセスする必要があるホストを構成します。したがって、サーバー マシン上の「my.cnf」ファイルを編集し、[mysqld] セクションに次の行を追加する必要があります:

master-host=10.1.1.1
master-user=replicate
master-password=password

バックアップ開始時 サーバーサービスプログラムの起動後、スタンバイサーバーサービスプログラムは「my.cnf」ファイルで指定されたホストをチェックして変更があるかどうかを確認し、それらの変更を自身のデータベースにマージします。スタンバイ マシンは、ホストの「master.info」ファイルから受信したホストの更新の記録を保持します。スタンバイ スレッドのステータスは、SQL コマンド「SHOW SLAVE-STATUS」を通じて確認できます。
がスタンバイマシンのバイナリログで処理される場合エラーが発生すると、スタンバイ スレッドが終了し、*.err ログ ファイルにメッセージが生成されます。その後、SQL ステートメント「SLAVE START」を使用してエラーを修正し、スタンバイ スレッドを再起動できます。スレッドは、ホスト バイナリ ログ処理が中断されたところから処理を続行します。

この時点で、メイン マシンで発生したデータの変更はスタンバイ マシンにコピーされているはずです。テストするには、メイン マシンでレコードを挿入または更新し、スタンバイ マシンでこのレコードを選択します。

これで、マシン A からマシン B へのマスターとスレーブの関係が確立されました。これにより、マシン A がクラッシュする可能性があるが、マシン A が回復したときに、すべてのクエリをマシン B にリダイレクトできます。マシン A に変更を復元する方法はありません。 。この問題を解決するには、マシン B からマシン A へのマスターとスレーブの関係を作成します。


原著者: Michael
出典: PHPBuilder.com