MySQLスレーブのメンテナンスに関する経験の共有

序文：

MySQL マスター/スレーブ アーキテクチャは、最も一般的に使用されるアーキテクチャ セットです。スレーブ データベースは、マスター データベースから送信されたデータをリアルタイムで同期します。通常、スレーブ データベースはバックアップ ノードとして、またはクエリ用に使用できます。実は、マスター データベースだけでなく、スレーブ データベースも定期的なメンテナンスが必要です。この記事では、スレーブ データベースのメンテナンスの経験をいくつか紹介します。一緒に学びましょう。

1. マスタースレーブレプリケーションにはGTIDモードを使用することをお勧めします。

GTID はグローバル トランザクション ID です。GTID は実際には server_uuid:transaction_id で構成されます。このうち、server_uuid は MySQL インスタンスの一意の識別子であり、transaction_id はインスタンス上で送信されたトランザクションの数を表し、トランザクションの送信とともに単調に増加します。そのため、GTID は各 MySQL インスタンスのトランザクションの実行を保証できます (同じトランザクションが繰り返し実行されず、実行されなかったトランザクションが完了します)。

GTID ベースのマスター/スレーブ レプリケーションは、binlog ファイルのオフセットを通じてレプリケーション位置を特定する従来の方法を置き換えることができます。特に、1 つのマスターと複数のスレーブのアーキテクチャの場合、GTID を使用すると、マスターとスレーブの切り替え時に、他の MySQL スレーブは新しいマスター上の正しいレプリケーション場所を自動的に見つけることができます。これにより、複雑なレプリケーション トポロジでのクラスターのメンテナンスが大幅に簡素化され、レプリケーション場所を手動で設定する際のエラーのリスクが軽減されます。さらに、GTID ベースのレプリケーションでは、すでに実行されたトランザクションを無視できるため、データの不整合のリスクが軽減されます。

2. スレーブデータベースのパラメータはマスターデータベースと一貫性を保つことをお勧めします。

マスター ライブラリとスレーブ ライブラリ間のデータの一貫性を確保するには、スレーブ ライブラリのバージョンをマスター ライブラリと一致させ、関連するパラメータを可能な限りマスター ライブラリと一致させることをお勧めします。たとえば、文字セット、デフォルトのストレージ エンジン、sql_mode などのパラメータは同じに設定する必要があります。特に動的に変更できないパラメータについては、事前に設定ファイルに書き込み、メインデータベースと整合をとることをお勧めします。

3. データベースからバックアップを実行できる

MySQL の完全バックアップはサーバーに負担をかけ、場合によっては短時間グローバル ロックを保持します。特に、データ量が多く業務が忙しいデータベースの場合、完全バックアップは業務に影響を及ぼす可能性があります。バックアップ スクリプトをスレーブ サーバーに展開することをお勧めします。スレーブ サーバーで完全バックアップを実行すると、マスター サーバーへのバックアップ プロセスの影響を軽減できます。

4. スレーブライブラリを読み取り専用に設定することをお勧めします。

データベースの読み取りおよび書き込みステータスは、主に read_only グローバル パラメータによって設定されます。デフォルトでは、データベースは読み取りおよび書き込み操作に使用されるため、read_only パラメータは 0 または false です。このとき、ローカル ユーザーであっても、リモートでデータベースにアクセスするユーザーであっても、権限があれば読み取りおよび書き込み操作を実行できます。

スレーブ ライブラリでの手動更新操作を回避するには、スレーブ ライブラリを読み取り専用に設定すること、つまり read_only パラメータを 1 に設定することをお勧めします。 read_only=1 読み取り専用モードは、スレーブ データベースの同期レプリケーション機能には影響しません。スレーブ データベースは引き続きマスターのログを読み取り、スレーブ側にログを適用して、マスター データベースとスレーブ データベースの同期と一貫性を確保します。スレーブ データベースを読み取り専用に設定すると、スーパー権限を持たないユーザーはデータ変更操作を実行できなくなります。通常のアプリケーション ユーザーが挿入、更新、削除などのデータ変更を伴う DML 操作を実行すると、データベースが読み取り専用モードであることが通知されます。これにより、スレーブ ライブラリで更新操作が発生するのを効果的に防ぐことができます。

さらに、条件が許せば、スレーブ データベースがクエリ作業の一部を引き受けることもできます。たとえば、一部のレポート集計分析クエリや外部サービスクエリをスレーブデータベースクエリとして構成して、メインデータベースへの負荷を軽減できます。

5. スレーブデータベースの監視とマスタースレーブの遅延に注意する

スレーブ データベースはマスター データベースほど重要ではありませんが、通常はスレーブ データベースの監視ステータスにもっと注意を払う必要があります。スレーブ データベースを使用する必要があるまで待たずに、スレーブ データベースがマスター データベースとすでに不整合になっていることを確認してください。基本的な監視に加えて、スレーブ データベースではレプリケーション ステータスと遅延ステータスに特別な注意を払う必要があります。

スレーブ側で show slave status; を実行して、スレーブの状態を照会できます。関心のある主な値は、Slave SQL Running、Slave IO Running、Seconds Behind Master の 3 つです。これら 3 つの値は、SQL スレッドの実行ステータス、IO スレッドの実行ステータス、およびスレーブ データベースの遅延秒数を表します。スレーブ SQL 実行中、スレーブ IO 実行中が「はい」、マスターからの秒数遅延が 0 の場合にのみ、スレーブ データベースが正常に実行されているとみなされます。

要約:

この記事は主にスレーブ データベースのメンテナンスに関する個人的な経験を共有しています。誤りがあれば修正してください。他の学生に関連する経験や提案がある場合は、メッセージを残して共有したり議論したりすることもできます。

上記は、MySQLスレーブデータベースのメンテナンス体験の共有の詳細な内容です。MySQLスレーブデータベースのメンテナンス体験の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。