マスタースレーブレプリケーション問題によるアーキテクチャ最適化に関する考察

問題があります

マスター/スレーブレプリケーションアーキテクチャには、1032エラーや1062エラーなど、多くのレプリケーション停滞の問題があります。その中で、1032エラーは、マスターライブラリが正常に実行された後に発見され、スレーブライブラリが見つかりません。スレーブ ライブラリのレコードを更新または削除するときに、メイン ライブラリの挿入が完了した後にスレーブ ライブラリを実行すると主キーの競合が発生し、挿入が成功しないという 1062 エラーが発生します。これらの問題は、エラーをスキップすることで解決できます。以前のコピー データの検証を修復していますが、これらの問題の直接の原因は、マスターとスレーブのデータベース データの不整合です。この不一致は、論理レプリケーション自体でデータの不整合が発生する可能性があることに加えて、ビジネス側または開発者が規制に違反してスタンバイ データベースに対して追加、削除、および変更操作を直接実行することによっても発生します。

マスター/スレーブ レプリケーション アーキテクチャでは、マスター/スレーブ ライブラリは VIP バインディングを実装してライブラリをマスター ライブラリとして指定し、読み取りと書き込みを提供し、マスター ライブラリで問題が発生した場合はスレーブ ライブラリがバックアップの役割を果たします。 、VIP はスレーブ ライブラリに切り替わり、スレーブ ライブラリは読み取りと書き込みを提供します。それ以外の場合、スレーブ ライブラリは単なるバックアップです。通常、開発者が固定 IP を介してスレーブ データベースに直接ログインすることは許可されていませんが、実際の作業ではこれを回避するのが難しい場合が多いです。では、技術的な観点から開発者がスレーブ データベースで操作できないようにするにはどうすればよいでしょうか。高可用性アーキテクチャの通常の動作とフェイルオーバーに影響を与えずにこれを回避するにはどうすればよいでしょうか?

2. アーキテクチャ構成の最適化

(1) 直接的な解決策

上記の問題を解決する直接的な方法は、アーキテクチャ構成の最適化、つまりスレーブ ライブラリの読み書き状態を最適化することを検討することです。読み取り専用状態。

MySQL公式サイトには読み取り専用について以下の記載があります:

1.Whenthe read_only system variable is enabled, the server permits no client updatesexcept from users who have the SUPER privilege. 
只读情况下，super权限可读写。
2.Updates performed by slave threads, if theserver is a replication slave. In replication setups, 
it can be useful toenable read_only on slave servers to ensure that slaves accept updates only from themaster server and not from clients.
不影响主从复制线程的读写。

読み取り専用をオンにすると、スーパー特権アカウントやレプリケーションスレッド等を除き、ビジネス側の開発者等はスタンバイデータベースを操作できなくなります。スタンバイ・データベースにログインしている場合でも同様です。

MySQL [db1]> show global variables like'read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON   |
+---------------+-------+
1 row in set (0.00 sec)
 
MySQL [test]> insert child values('1','12');
ERROR 1290 (HY000): The MySQL server is running withthe --read-only option so it cannot execute thisstatement

(2) 読み取り専用として構成した後に完全なフェイルオーバーを実行するにはどうすればよいですか?

スレーブライブラリから読み取り専用にすることで不正な操作を回避できますが、問題はメインライブラリで問題が発生した場合、VIP はスレーブライブラリに切り替える必要があることですが、このとき、スレーブライブラリからは読み取り専用になります。スレーブライブラリを使用するとデータベースが外部サービスで利用できなくなるため、切り替える前にスレーブライブラリの読み取り専用機能を解除し、メインライブラリの読み取り専用機能を設定する機能を実装する必要があります。

Keepalived+MySQL デュアル マスター (マスター/スレーブ) アーキテクチャを例にとると、通常の動作中、VIP はマスター 1 上にあり、マスター 1 は読み取り/書き込み状態になり、問題が発生するとマスター 2 は読み取り専用状態になります。 Master1 を使用すると、VIP は自動的に Master2 に切り替わります。切り替える前に、次の 2 つの手順を実行します。 1. Master1 を読み取り専用に設定します。 2. Master2 の読み取り専用を解除します。

3. 自動化実装のアイデア

マスター/スレーブ アーキテクチャの場合、フェイルオーバーは手動で行う必要があるため、Keepalived + MySQL デュアルマスター (マスター/スレーブ) では、上記の 2 つの手順を手動で実行することもできます。 ) アーキテクチャでは、障害の自動監視と VIP の自動切り替えが実装されており、自動化を実現するには、上記の 2 つの手順もスクリプトに埋め込む必要があります。

主に、自動監視および切り替えスクリプトにデータベースの読み取り専用を有効にし、読み取り専用をオフにする関数を埋め込む必要があります。主に、「set global read_only=ON」と「set globalread_only=OFF」というステートメントを同時に記述します。既存のステータスを確認するために、シェルは「show variables like 'read_only';」ステートメントを呼び出し、読み取りおよび書き込みステータスを確認した後、readonly パラメータを に設定します。これらのステータス設定のトリガーのカスタマイズは、障害が検出された後、切り替えを実行する前にトリガーされることに注意してください。

上記のアイデアは自動的に変換され、個人テストは成功し、アイデアが正しいことが示されました。

上記は、マスター/スレーブ レプリケーション問題によって引き起こされるアーキテクチャ最適化の考え方の内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。