MySQL のマスターとスレーブのデータベース同期遅延の問題を解決する

最近、MySQL のマスター/スレーブ データベースの同期テストを行ったところ、いくつかの問題が見つかりました。その中には、マスター/スレーブの同期遅延の問題も含まれます。以下の内容は、インターネットで見つけた説明の一部であり、ご自身の学習のために記録したものです。

MySQL のマスターとスレーブの同期 これは、次の利点を持つ非常に成熟したアーキテクチャです。 ① クエリ作業 (つまり、読み取り機能と呼ばれるもの) をスレーブ サーバーで実行できるため、マスター サーバーの負荷が軽減されます。バックアップ期間中のマスターサーバーサービスへの影響を避けるため、スレーブマスターサーバーで実行されます。 ③ マスターサーバーに問題が発生した場合、スレーブサーバーに切り替えることができます。

これらの利点については皆さんすでによくご存じだと思います。このソリューションはプロジェクトの展開にも使用されています。しかし、MySQL のマスターとスレーブの同期にはスレーブ データベースの遅延という問題が常にありました。なぜこの問題が発生するのでしょうか?この問題を解決するにはどうすればよいでしょうか?

1. MySQL データベースのマスターとスレーブの同期遅延の原理。

2. MySQL データベースのマスターとスレーブの同期遅延はどのように発生しますか?

3. MySQL データベースのマスター/スレーブ同期遅延ソリューション。

1. MySQL データベースのマスターとスレーブの同期遅延の原理。

回答: MySQL データベースのマスター/スレーブ同期遅延の原理について話すときは、MySQL データベースのマスター/スレーブ レプリケーションの原理から始める必要があります。MySQL のマスター/スレーブ レプリケーションは、メイン データベースによって生成されます。すべての DDL と DML の binlog は、シーケンシャルに書き込まれるため、効率が非常に高くなります。スレーブの Slave_IO_Running スレッドはログを取得するために非常に効率的です。次のステップが問題です。スレーブの Slave_SQL_Running スレッドは、スレーブ上のメイン ライブラリの DDL および DML 操作を実装します。 DML と DDL の IO 操作はシーケンシャルではなくランダムであり、スレーブ上の他のクエリもロック競合を引き起こす可能性があるため、DDL カード マスターの実行には 10 分かかります。その後、後続のすべての DDL は、続行する前にこの DDL が実行されるまで待機するため、遅延が発生します。 「メイン ライブラリの同じ DDL も 10 分間実行する必要があります。なぜスレーブが遅れるのですか?」と尋ねる友人もいます。答えは、マスターは同時に実行できますが、Slave_SQL_Running スレッドは実行できないからです。

2. MySQL データベースのマスターとスレーブの同期遅延はどのように発生しますか?

回答: メイン ライブラリの TPS 同時実行性が高い場合、生成される DDL の数がスレーブの 1 つの SQL スレッドが耐えられる数を超え、当然、大規模なクエリによってロック待機が発生する可能性もあります。奴隷の発言。

3. MySQL データベースのマスター/スレーブ同期遅延ソリューション

回答: スレーブ同期遅延を軽減する最も簡単な解決策は、アーキテクチャを最適化し、メイン データベースの DDL を高速に実行するように努めることです。メイン ライブラリには sync_binlog=1、innodb_flush_log_at_trx_commit = 1 などの高いデータ セキュリティが設定されているという事実もありますが、スレーブではそのような高いデータ セキュリティは必要ありません。sync_binlog を 0 または 0 に設定することもできます。 binlog をオフにすることもできます。innodb_flushlog を 0 に設定すると、SQL の実行効率が向上します。もう 1 つは、メイン ライブラリよりも優れたハードウェア デバイスをスレーブとして使用することです。

mysql-5.6.3 はすでにマルチスレッドのマスター/スレーブ レプリケーションをサポートしています。原理は Ding Qi と似ていますが、Oracle はマルチスレッドを実行するための単位としてデータベース (スキーマ) を使用します。異なるライブラリは異なるレプリケーション スレッドを使用します。

sync_binlog=1

これにより、MySQL はトランザクションをコミットするたびにバイナリ ログの内容をディスクと同期します

デフォルトでは、バイナリ ログは書き込まれるたびにハード ディスクと同期されません。したがって、オペレーティング システムまたはマシン (MySQL サーバーだけでなく) がクラッシュすると、バイナリログの最後のステートメントが失われる可能性があります。これを防ぐには、sync_binlog グローバル変数 (1 が最も安全な値ですが、最も遅い値です) を使用して、N 回のバイナリ書き込みごとにバイナリをハード ディスクと同期します。 sync_binlog が 1 に設定されている場合でも、クラッシュが発生すると、テーブルの内容と binlog の内容の間に不一致が生じる可能性があります。 InnoDB テーブルを使用する場合、MySQL サーバーは COMMIT ステートメントを処理し、トランザクション全体をバイナリログに書き込み、トランザクションを InnoDB にコミットします。 2 つの操作間でクラッシュが発生した場合、トランザクションは再起動時に InnoDB によってロールバックされますが、トランザクションはバイナリログにまだ存在します。 --innodb-safe-binlog オプションを使用すると、InnoDB テーブルの内容と binlog の間の一貫性を高めることができます。 (注: --innodb-safe-binlog は MySQL 5.1 では必要ありません。このオプションは の導入により廃止されました)、(デフォルトで true) InnoDB ログがハード ディスクと同期されます。このオプションの効果は次のとおりです。クラッシュ後の再起動時、トランザクションがロールバックされた後、MySQL サーバーはロールバックされた InnoDB トランザクションをバイナリログから削除します。これにより、binlog が InnoDB テーブルなどの正確なデータをフィードバックし、(ロールバック ステートメントを受信せずに) スレーブ サーバーとマスター サーバーの同期を維持することが保証されます。

innodb_flush_log_at_trx_commit (これは非常にうまく機能します)

Innodb が MyISAM より 100 倍遅いと不満を抱いていますか?この値を調整するのを忘れている可能性があります。デフォルト値の 1 は、トランザクションのコミットまたはトランザクション外の命令ごとにログをハードディスクに書き込む (フラッシュ) 必要があり、非常に時間がかかることを意味します。特にバッテリーバックアップキャッシュを使用している場合。多くのアプリケーション、特に MyISAM テーブルから転送されるアプリケーションでは、これを 2 に設定しても問題ありません。これは、ハードディスクに書き込むのではなく、システム キャッシュに書き込むことを意味します。ログは依然として毎秒ディスクにフラッシュされるため、通常は 1 ～ 2 秒以上の更新が失われることはありません。 0 に設定すると高速になりますが、MySQL がハングアップした場合でもトランザクション データが失われる可能性があります。値 2 は、オペレーティング システム全体がハングした場合にのみデータ損失を引き起こします。

以上がMySQL のマスターとスレーブのデータベース同期遅延の問題を解決するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。