| 今日、私はデータベースの遅延とビーティングに関するもう1つの問題を分析しましたが、これも典型的であり、このプロセスの問題を分析するためのいくつかの方法と手法もあります。 |
まず、高可用性の検出では、断続的に一連の環境検出が行われます。調査の結果、データベースに遅延があることがわかりました。スレーブライブラリにログインした後、スレーブのステータスを表示すると、Seconds_behind_masterの値が絶えず変動している、つまり0から39〜0〜39の頻度は鼓動し続け、人々を非常に暑くします。
データベースの関連ログを参照したところ、参照できるログレコードがないことがわかりました。この問題の分析方法は、最初に再現してみましょう。問題のログを、リズムに応じて3回、つまりshow slave statusで継続的に監視しました。 show slave statusの出力結果を取得して保存します。これにより、問題の発生中にオフセットの変更を取得できます。この変更は、再生中にSQLThreadによって生成される問題です。
たとえば、次の出力では、分析のためにスレーブ側のリレーログをインターセプトし、対応するフィールドはRelay_Log_Posです。
Slave_IO_State：イベント送信するためのマスターを待っている
MASTER_HOSTを：XXXX
Master_User：dba_repl
MASTER_PORT：4306
Connect_Retry：60
MASTER_LOG_FILE：mysqlbin.000044
Read_Master_Log_Pos：386125369
RELAY_LOG_FILE：スレーブリレー-bin.000066
RELAY_LOG_POS：386125580
のRelay_Master_Log_File：mysqlbin.000044
すぐにオフセットの変更を取得しました：385983806、386062813、386125580
次に、mysqlbinlogを使用してこれらのログの詳細を分析したところ、次のコマンドによると、ダンプされたログから3つの関連テーブルをすばやく取得できます。
＃grep INSERT relaylog_xxxx.dump | awk '{print $ 3 "" $ 4}' | sed 's / INTO // g' | sort | uniq
act_action_exec_info
act_join_desc
dic_subsidy_marketing_querylog_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 | head -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フレームワークに基づいて複数回呼び出されます。 xxx操作からcount（1）を選択します。
企業とのコミュニケーションの結果、上記の問題は基本的に明らかになりました。
上記はMySQLのデータ遅延打撃の問題を解決する詳細な内容です。
この記事のアドレス：https : //www.linuxprobe.com/mysql-linux-two.html