MySQL のレイテンシ問題とデータフラッシュ戦略プロセスの分析

1. MySQLレプリケーションプロセス

公式文書のプロセスは次のとおりです。

MySQL のレイテンシ問題とデータフラッシュ戦略

1. 絶対遅延、相対同期

2. 純粋な書き込み操作の場合、オンライン標準構成では、スレーブ データベースへの負荷はマスター データベースへの負荷よりも大きくなります。少なくともスレーブ データベースにはリレーログが書き込まれています。

2. MySQLの遅延問題の分析

1. メインデータベースへの頻繁なDMLリクエスト

原因: マスター データベースは同時にデータを書き込みますが、スレーブ データベースは単一のスレッドでログを適用するため、リレーログの蓄積と遅延が簡単に発生する可能性があります。

解決策: 書き込み要求を分割するためにシャーディングが使用されます。 MySQL 5.7 以降にアップグレードし、論理クロックに基づいて並列レプリケーションを有効にすることを検討してください。

2. メインデータベースは大規模なトランザクションを実行する

原因: たとえば、マスター データベースが大きなテーブルを更新するのには長い時間がかかります。マスター データベースとスレーブ データベースの構成が似ている場合、スレーブ データベースも大きなテーブルを更新するためにほぼ同じ時間を費やす必要があります。この時点で、スレーブ データベースの遅延が蓄積され始め、後続のイベントを更新できなくなります。

解決策: 大規模なトランザクションを分割し、時間内に送信します。

3. メインデータベースは大きなテーブルに対してDDL文を実行する

原因: DDL の実行が開始されておらず、ブロックされています。位置は変更されていないことが確認されています。DDL が実行されており、シングル スレッド アプリケーションによって待機時間が増加し、位置は変更されていません。

解決策: DDL または書き込み操作をブロックするクエリを見つけてクエリを強制終了し、スレーブ データベースで DDL が正常に実行されるようにします。業務のオフピーク時に実行し、OnlineDDL をサポートする MySQL の上位バージョンを使用してみます。

4. マスターインスタンスとスレーブインスタンスの構成が一致しない

理由: ハードウェア: マスターインスタンスサーバーは SSD を使用し、スレーブインスタンスサーバーは通常の SAS ディスクを使用し、CPU メイン周波数が一貫していないなど。構成: RAID カードの書き込み戦略が一貫していない、OS カーネルパラメータ設定が一貫していない、MySQL ディスクの書き込み戦略が一貫していない (innodb_flush_log_at_trx_commit および sync_binlog など) など。

解決策: DB マシンの構成 (ハードウェアとオプション パラメータを含む) を統一します。一部の OLAP ビジネスでも、スレーブ データベース インスタンスのハードウェア構成はマスター データベースよりも高くなります。

5. スレーブライブラリ自体が過度の圧力を受けている

原因: スレーブ データベースが大量の選択要求を実行しているか、業務の選択要求のほとんどがスレーブ データベース インスタンスにルーティングされているか、または大量の OLAP 業務があるか、スレーブ データベースがバックアップ中であるなどです。このとき、CPU 負荷が高すぎる、IO 使用率が高すぎるなどの理由により、SQLThread アプリケーションが遅くなりすぎている可能性があります。

解決策: 読み取り要求を分散し、既存のスレーブ インスタンスへの負荷を軽減するために、Xi'an データベース トレーニング スレーブをさらに作成します。

また、ディスク フラッシュ パラメータ innodb_flush_log_at_trx_commit=0 および sync_binlog=0 を調整して、IO 負荷を軽減し、マスター スレーブ間の遅延を減らすこともできます。

3. プロモーション期間中のCPU過負荷問題

現象：

同時実行性が高いと CPU 負荷が過剰になり、リクエストの処理時間が長くなり、徐々にバックログが発生して、最終的にサービスが利用できなくなります。また、低速の SQL ステートメントが多数あると、CPU 負荷が過剰になります。

解決：

基本的に、データベースのマスターとスレーブの切り替えは禁止されているか、慎重に検討されています。これでは根本的な問題を解決できず、SQL の問題を解決するには R&D の協力が必要です。サービスのダウングレードも可能です。コンテナの場合、CPU 容量を動的に拡張できます。ビジネスと交渉して、pt-kill を開始し、読み取り専用の低速 SQL を強制終了します。一般インデックスまたは結合インデックスを追加することで低速 SQL の問題を解決できるかどうかを確認しますが、このとき、DDL がデータベースに与える影響を考慮する必要があります。

4. InnoDB フラッシュ戦略

MySQL の innodb_flush_method パラメータは、innodb データ ファイルと redolog のオープンおよびフラッシュ モードを制御します。このドキュメントでは、このパラメータについて次のように説明しています。

値は3つあります: fdatasync (デフォルト)、O_DSYNC、O_DIRECT

デフォルトはfdatasyncで、fsync()を呼び出してデータファイルとredologバッファをフラッシュします。

O_DSYNC が使用される場合、InnoDB は O_SYNC を使用して redolog を開いてフラッシュし、fsync() を使用してデータ ファイルをフラッシュします。

O_DIRECT が使用される場合、InnoDB は O_DIRECT を使用してデータ ファイルを開き、fsync() を使用してデータ ファイルと redolog をフラッシュします。

まず、ファイル書き込み操作には、開く、書き込み、フラッシュの3つのステップが含まれます。

上記で最も頻繁に言及されている fsync(intfd) 関数は、フラッシュ中に fd ファイル記述子によって指されるファイルに関連するバッファをディスクにフラッシュするために使用され、メタデータ情報 (変更日、作成日など) がフラッシュされた後にのみフラッシュが成功したと見なされます。

O_DSYNC メソッドを使用して REDO ファイルを開くということは、ログを書き込むときにデータがディスクに書き込まれ、成功が返される前にメタデータも更新する必要があることを意味します。

O_DIRECT は、書き込み操作が MySQL InnoDB バッファからディスクに直接書き込まれることを意味します。

これら 3 つのモードの具体的なデータ書き込み方法は次のとおりです。

fdatasync モード: データを書き込む場合、書き込みステップは実際にディスクに書き込まれなくても完了します (オペレーティング システムのバッファーに書き込まれた時点で完了として返される場合があります)。実際の完了はフラッシュ操作であり、バッファーはフラッシュのためにオペレーティング システムに引き渡され、ファイルのメタデータ情報もディスクに更新される必要があります。

O_DSYNCモード: ログの書き込みは書き込みステップで行われ、データファイルの書き込みはfsyncを介してフラッシュステップで行われます。

O_DIRECT モード: データ ファイルは、オペレーティング システム バッファーを経由せずに mysqlinnodbbuffer からディスクに直接書き込まれ、実際の完了はフラッシュ ステップで行われます。ログは引き続き OS バッファーを通過する必要があります。

MySQL のレイテンシ問題とデータフラッシュ戦略

1. Unix 系オペレーティング システムでは、O_DIRECT モードでファイルを開くと、バッファリングが IO に与える影響が最小限に抑えられます。ファイルの IO は、ユーザー空間のバッファに対して直接操作され、IO 操作は同期しています。そのため、read() システム コールでも write() システム コールでも、データがディスクから読み取られることが保証されます。そのため、IO 負荷は最小限に抑えられ、CPU 処理負荷は最小限に抑えられ、物理メモリの使用量は最小限に抑えられます。ただし、オペレーティング システムのバッファリングがないため、ディスクへのデータ書き込み速度は大幅に低下します (書き込み応答時間が長くなるという形で現れます)。ただし、全体的な SQL 要求量が大幅に減少することはありません (これは、innodb_buffer_pool_size が十分に大きいかどうかによって異なります)。

2. O_DSYNC モードは、同期 IO モードでファイルを開くことを意味します。データが物理ディスクに書き込まれるまで、書き込み操作はすべてブロックされます。その結果、CPU 待機時間が長くなり、SQL 要求のスループットが低下し、挿入時間が長くなります。

3. fsync(intfiledes) 関数は、ファイル記述子 filedes で指定された単一のファイルに対してのみ動作し、ディスク書き込み操作が完了するまで待機してから戻ります。 fdatasync(int filedes) 関数は fsync に似ていますが、ファイルのデータ部分にのみ影響します。 fsync はデータに加えて、ファイルのメタデータもディスクに同期的に更新します。

CPU に最も大きな負荷をかけるのは O_DSYNC で、次に datasync が続き、最も負荷をかけないのは O_DIRECT です。全体的な SQL ステートメント処理のパフォーマンスと応答時間に関しては、O_DSYNC は劣っています。O_DIRECT は SQL スループットが優れていますが (datasync モードに次ぐ)、応答時間が最も長くなります。

デフォルトのデータ同期モードは、オペレーティング システム バッファと innodb_buffer_pool の処理性能をフルに活用するため、全体的なパフォーマンスが向上します。ただし、マイナス面としては、空きメモリが急速に減少し、最終的にはページ スワップが頻繁に発生し、ディスク IO 負荷が高くなり、大量の同時データ書き込みの安定性に重大な影響が出ることです。

要約する

上記は、編集者が紹介したMySQLレイテンシ問題とデータフラッシュ戦略プロセスの分析です。皆様のお役に立てれば幸いです。