MySQLデータ遅延ジャンプの問題の解決策

今日は、データベース遅延ジャンプに関する別の典型的な問題を分析しました。このプロセスでは、参考のために問題を分析するためのいくつかの方法とテクニックも提供しました。

まず、高可用性テストでは、一連の環境検出が断続的でした。調査の結果、データベースに遅延があることがわかりました。スレーブライブラリにログインしてshow slave statusを確認すると、Seconds_behind_masterの値が絶えずジャンプしていることがわかりました。つまり、0〜39〜0〜39の頻度でジャンプし続けており、非常に腹立たしいことです。

データベースの関連ログを確認したところ、参照できるログ記録がないことがわかりました。この問題をどのように分析すればよいでしょうか。まずは再現してみましょう。そこで、リズムに合わせて問題のログを3回キャプチャしました。つまり、show slave statusを介して継続的に監視し、show slave statusの出力結果をキャプチャして保存しました。このようにして、問題発生時のオフセットの変化を取得できます。この変化は、再生プロセス中にSQLThreadによって引き起こされた問題です。

例えば、次の出力では、スレーブ側のリレーログを傍受して分析しました。対応するフィールドはRelay_Log_Posです。

Slave_IO_State: マスターがイベントを送信するのを待機中
         マスターホスト: xxxx
         マスターユーザー: dba_repl
         マスターポート: 4306
        接続再試行: 60
       マスターログファイル:mysqlbin.000044
     読み取りマスターログ位置: 386125369
        リレーログファイル: スレーブリレーbin.000066
        リレーログ位置: 386125580
    リレーマスターログファイル: mysqlbin.000044

オフセットの変化はすぐに分かります: 385983806、386062813、386125580

次に、mysqlbinlog を使用して、これらのログ プロセスの詳細を分析し始めました。次のコマンドを実行すると、ダンプされたログ内の関連する 3 つのテーブルをすぐに取得できます。

# grep INSERT relaylog_xxxx.dump |awk '{print $3 " " $4}'|sed 's/INTO//g'|sort|uniq
 アクション実行情報
 行為参加説明
 dic_補助金_マーケティング_クエリログ_202008

各テーブルのデータ操作を少しずつ分析してみましたが、得られる情報はまだ限られていました。さらに分析を続け、例えば、ログ全体のトランザクション量を分析してみましょう。

# mysqlbinlog slave-relay-bin.000066 | grep "GTID$(printf '\t')last_committed" -B 1 \
> | grep -E '^# at' | awk '{print $3}' \
> | awk 'NR==1 {tmp=$1} NR>1 {print ($1-tmp);tmp=$1}' \
> | ソート -n -r | ヘッド -n 100
mysqlbinlog: [警告] 不明な変数 'loose-default-character-set=utf8'
5278
5268
5268
5268
5253
5253
5253
5253
5253

約 5K と比較的大きいことがわかります。この追加情報はどこから来るのでしょうか? メイン データベースで general_log を有効にして、より詳細な操作ログを取得できるようにしました。

さらに分析を進めると、業務全体で明示的なトランザクション方式（SET autocommit=0）が使用されていたことが判明しました。トランザクション全体には複数の大きなSQL文が含まれており、大量の操作ログの詳細が保存されていました。また、トランザクション操作中に、Mybatisフレームワークに基づいて、複数のselect count(1) from xxx操作が呼び出されていました。

事業者とのコミュニケーションの結果、上記の問題点は基本的に解決されました。

上記は、MySQL データの遅延とジャンプの問題に対する詳細な解決策です。MySQL データの遅延とジャンプの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。