GTIDモードでMySQLの起動時間が遅くなったことはありますか？最近、MySQLホスティングデプロイメントの1つでこの問題に遭遇し、問題の解決に着手しました。このブログでは、MySQLの再起動時間を遅くする可能性のある問題、デプロイメントのデバッグ方法、および開始時間を短縮してGTIDベースのレプリケーションの理解を深めるためにできることについて説明します。
問題の発見方法
GTIDモードが有効になっているローエンドのディスクベースのMySQL5.7.21デプロイメントでMySQLの起動時間が遅いことを調査していました。システムはマスタースレーブペアの一部であり、適度な書き込み負荷がかかっていました。計画的メンテナンス中に再起動すると、データベースサーバーが起動して接続の受け入れを開始するのに5〜10分かかることがわかりました。そのような遅延は意味がなかったので、調査に着手しました。
遅いMySQL開始時間のデバッグ
人気のあるPerconaツールpt-ioprofileを使用して、データベースの動作を確認しました。 pt-ioprofile は、MySQLの問題をデバッグするために使用されるPerconaの人気のあるツールキットの非常に重要なユーティリティであり、機能の完全なリストはドキュメントで確認できます。 pt-ioprofile ツールはstraceを使用します およびlsof プロセスのI/Oを監視し、ファイルとI/Oアクティビティの表を印刷します。
そこで、MySQLを起動し、 mysqldを待ちました。 スポーンされ、 pt-ioprofileを開始するプロセス 問題が何であるかを確認するには：
# pt-ioprofile --profile-process mysqld --run-time 200 Tue Oct 9 15:42:24 UTC 2018 Tracing process ID 18677 total pread read pwrite write fsync fdatasync open close getdents lseek fcntl filename ... 216.550641 0.000000 216.550565 0.000000 0.000000 0.000000 0.000000 0.000015 0.000040 0.000000 0.000021 0.000000 /mysql_data/binlogs/mysql-bin.000014 ...
MySQLの再起動を遅くしているのは何ですか？
これを複数回実行すると、次のことがわかりました。
- mysqld プロセスは、ほとんどの時間を最新のバイナリログファイルの読み取りに費やしていました。これは、サーバーが正常に停止されていて、クラッシュリカバリなどの必要がなかった場合でも当てはまりました。
- サーバーもInnoDBデータファイルの読み込みにかなりの時間を費やしましたが、その時間は最新のバイナリログファイルの読み取りに費やした時間と比較してはるかに短かったです。
- サーバーをすぐに再起動した場合、この後続の再起動ははるかに高速になります。
- データベースのシャットダウンによりバイナリログがフラッシュされ、起動時に新しいログが作成されるため、追加の実験を行いました。サーバーをシャットダウンする前に、バイナリログをフラッシュしました。その後のサーバーの起動は再び高速でした。
これらの観察結果は、MySQLが最新のバイナリログファイルの読み取りに多くの時間を費やしていたという事実を明確に示しています。シャットダウン前にログファイルがフラッシュされたときのように、ファイルが小さかった場合、起動は高速でした。
GTIDのMySQL開始時間が遅いですか？バイナリログファイルのサイズが問題になる可能性がありますクリックしてツイート
BinlogGTIDリカバリについて
結局のところ、gtid_executedとgtid_purgedの値を入力するには、MySQLサーバーがバイナリログファイルを解析する必要があります。
これは、FALSEまたはTRUEの読み取りに基づくMySQL5.7ドキュメントメソッドの推奨事項の概要です。
binlog_gtid_simple_recoveryの場合 =FALSE：
gtid_executed：を計算するには
- バイナリログファイルを最新のものからイテレートし、 Previous_gtids_log_eventを持つ最初のファイルで停止します エントリ。
- Previous_gtids_log_eventのすべてのGTIDを消費します およびGtid_log_events このバイナリログファイルから、このGTIDセットを内部に保存します。 gtids_in_binlogと呼ばれます。
- gtid_executedの値 gtids_in_binlogの和集合として計算されます およびmysql.gtid_executedテーブルのGTID 。
たとえば、 gtid_mode のときに作成された、GTIDのないバイナリログファイルが多数ある場合、このプロセスには非常に時間がかかる可能性があります。 =オフ。
同様に、計算するには gtid_purged：
- バイナリログファイルを古いものから新しいものへと繰り返し、空でない Previous_gtids_log_eventを含む最初のバイナリログで停止します。 （少なくとも1つのGTIDを持っている）、または少なくとも1つの Gtid_log_eventを持っている 。
- Previous_gtids_log_eventを読む このファイルから。内部変数gtids_in_binlog_not_purgedを計算します このGTIDセットがgtids_in_binlogから差し引かれます。
- gtid_purgedの値 gtid_executedに設定されています 、マイナス gtids_in_binlog_not_purged 。
つまり、これは、古いバージョンで物事がどのように機能していたかについての理解の基礎を形成します。ただし、 binlog_gtid_simple_recovery の場合、特定の最適化を行うことができます。 TRUEです。これは私たちが興味を持っているケースです：
いつ binlog_gtid_simple_recovery =TRUE：
（注：これはMySQL 5.7.7以降のデフォルトです）
- 最も古いバイナリログファイルと最新のバイナリログファイルだけを読み取ります。
- 計算 gtid_purged Previous_gtids_log_eventから またはGtid_log_event 最も古いバイナリログファイルで見つかりました。
- gtid_executedを計算します Previous_gtids_log_eventから またはGtid_log_event 最新のバイナリログファイルで見つかりました。
- したがって、2つのバイナリログファイルのみ サーバーの再起動中またはバイナリログの削除時に読み取られます。
したがって、MySQLバージョン5.7.7以降では、システムの起動時に常に最新および古いバイナリログファイルが読み取られ、GTIDシステム変数が正しく初期化されます。 MySQLが探しているイベントPrevious_gtids_log_eventは常にバイナリログファイルの最初のイベントであるため、最も古いバイナリログファイルの読み取りはそれほど費用がかかりません。
ただし、 gtid_executedを正しく計算するために 、サーバーは最新のバイナリログファイル全体を読み取り、そのファイル内のすべてのイベントを収集する必要があります。 したがって、システムの起動時間は、最新のバイナリログファイルのサイズに正比例します 。
binlog_gtid_simple_recovery の場合、状況はさらに悪化することに注意してください FALSEです 。最近のリリースではデフォルトのオプションではなくなったため、それほど心配する必要はありません。
遅い開始時間を解決する方法
発生した問題の原因を理解したので、私たちが決定した解決策はかなり明白でした。バイナリログファイルのサイズを小さくしてください。バイナリログファイルのデフォルトサイズは1GBです。起動時にこのサイズのファイルを解析するには時間がかかるため、 max_binlog_sizeの値を減らすのが理にかなっています。 より低い値に。
バイナリログファイルのサイズを小さくすることができない場合は、mysqldプロセスのメンテナンスシャットダウンの直前にバイナリログファイルをフラッシュすると便利です。 binlogGTIDリカバリ時間を短縮します。
