ホームページ  >  記事  >  データベース  >  MySQL の組み込みレプリケーション機能を使用して可用性を最適化する

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

黄舟
黄舟オリジナル
2016-12-14 09:33:58958ブラウズ

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) に接続し、ホスト マシンのバイナリ更新ログを読み取り、変更を自身のデータベースにマージします。スタンバイ マシンにはホストに接続するためのユーザー アカウントが必要なので、次のようにホスト上でアカウントを作成し、ファイル権限のみを付与します:

GRANT FILE ON *.* TO replicate@10.1.1.2 IDENTIFIED BY password;

スタンバイ マシンはホスト マシンに接続でき、ホスト マシン上で 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 へのマスター/スレーブ関係を作成します。

ステップ3: 相互主従関係を作成する
まず、マシン B の my.cnf ファイルで、[mysqld] セクションに log-bin を追加し、mysqld を再起動して、コピー機能を実行できるユーザー アカウントを作成します。次のコマンドを使用します。

GRANT FILE ON * . * TO replicate@10.1.1.1 IDENTIFIED BY passwd;

レプリケーション ユーザーを追加した後、マシン B で FLUSH PRIVILEGES コマンドを実行して新しい認可テーブルをロードし、マシン A に戻り、その my.cnf に次のコードを追加します。行:

master-host=10.1.1.2
master-user=replicate
master-password=password

マシン A のサービス プログラムを再起動すると、マシン A とマシン B の間で相互通信ができるようになります。関係。どのサーバーでレコードが更新されたり、レコードが挿入されたりしても、レコードは他のサーバーにコピーされます。注: スタンバイ マシンがバイナリ ログの変更をどれくらい早くマージできるかわからないため、この方法を使用して挿入または更新ステートメントの負荷分散を行うのは得策ではない可能性があります。

ステップ 4: データベース接続プログラムを変更する
マシン A とマシン B の間の相互関係を確立したので、このアプローチを活用するにはデータベース接続プログラムを変更する必要があります。次の関数は、最初にマシン A への接続を試みます。接続を確立できない場合は、マシン B に接続します。


/*************************************************** ****
関数 db_​​connect()

成功した場合はリンク識別子を返し、エラーの場合は false を返します
******************** *****************************/
function db_connect(){
$username = "replUser";
$password = "パスワード";
$primary = "10.1.1.1";
$backup = "10.1. 1.2";

# プライマリへの接続を試行します
if(!$link_id = @mysql_connect($primary, $username, $password))
# セカンダリへの接続を試行します
$link_id = @mysql_connect($secondary, $username, $パスワード)
return $link_id;
}

?>

上記のテクノロジーを使用してデータベース接続確立プロセスを 2 つの状況でテストしました。1 つは、メインの MySQL サービス プログラムが閉じられているが、サーバーはまだ実行中であるということです。 、別の状況は、メインサーバーがシャットダウンされている場合です。 mysqld のみがシャットダウンされている場合、接続はすぐにバックアップ マシンに転送されますが、サーバー全体がシャットダウンされている場合は、PHP が原因で無限に待機することになります (2 分後に追跡を諦めましたが、注意が必要な時間は非常に短いです)。存在しないサーバーを探しています。残念ながら、fsockopen 関数とは異なり、mysql_connect 関数にはタイムアウト パラメーターがありませんが、fsockopen を使用してタイムアウトをシミュレートできます。

ステップ 5: 改良されたデータベース接続プログラム

/*************************************************** ****
関数 db_​​connect_plus()

成功した場合はリンク識別子を返し、エラーの場合は false を返します
**************************** *****************************/
function db_connect_plus(){
$username = "ユーザー名";
$password = "パスワード";
$primary = "10.1 .1.1 ";
$backup = "10.1.1.2";
$timeout = 15; // 秒単位のタイムアウト

if($fp = fsockopen($primary, 3306, &$errno, &$errstr, $timeout) ){
fclose($fp);
return $link = mysql_connect($primary, $username, $password);
}
if($fp = fsockopen($secondary, 3306, &$errno, &$errstr, $ timeout) ){
fclose($fp);
return $link = mysql_connect($secondary, $username, $password);
}

return 0;
}

?>

この新しく改良された関数は、調整可能なタイムアウト機能は、mysql_connect 関数に欠けています。接続がすぐに失敗した場合 (マシンは「生きている」が mysqld が「ダウン」している場合など)、関数はすぐに 2 番目のサーバーに移動します。上記の関数は非常に堅牢です。接続を試行する前にテストして、サービス プログラムが指定されたポートでリッスンしているかどうかを確認します。これにより、エラー状態を適切に処理できるようになります。デフォルトのポート 3306 を変更する場合は、必ずポート番号を変更してください。

結論とコメント
まず、完全なデータのスナップショットを取得していることを確認してください。テーブルやデータベースのコピーを忘れると、待機系プログラムが停止してしまいます。スナップショットが生成される時間は重要です。データ ファイルをコピーする前に、バイナリ ログ機能が無効になっていることを確認する必要があります。スナップショットを取得する前にバイナリ ログ機能が有効になっている場合、スタンバイ マシン上のスレッドが停止する可能性があります。これは、スレッドが重要なレコードをインポートしようとすると、主キーの重複によりスレッドが停止する可能性があるためです。最善の方法は、パート 2 で説明した解決策に従うことです。クローズ、コピー、バイナリ ログ機能の再起動を許可します。

元の方法でレプリケーション プロセスを構成し、スタンバイ マシンがマスター マシンと同期していることを確認するために、適切なタイミングでスタンバイ マシンに注意を払うことをお勧めします。

レプリケーション機能を使用するシステムの負荷分散パフォーマンスをテストしたことはありませんが、このようなシステムを柔軟に使用して、挿入と更新のバランスをとります。たとえば、2 つのサーバー上の 2 つのレコードが同じ auto_increment 値を指定した場合、スタンバイ スレッドはどのレコードで停止しますか?このような問題では、ロード バランシングが読み取り専用として処理され、1 つのサーバーがすべての挿入と更新を処理し、一方、一連のスタンバイ (マスターとは別に複数のスタンバイを使用できます) がすべての選択を処理します。

MySQLには既にレプリケーションシステムの機能がいくつか備わっており、構成も非常にシンプルなのでとても嬉しいです。これを使用すると、制御不能なイベントに対する追加のセキュリティの提供を開始できます。ここでは、私がテストして使用したレプリケーション機能についてのみ触れましたが、MySQL オンライン ドキュメントのパート 11 で詳しく説明されています。

上記は、可用性を最適化するための MySQL の組み込みレプリケーション機能の使用についてです。さらに多くのコンテンツを取得したい場合は、PHP 中国語 Web サイト (www.php.cn) に注意してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。