mysql Binlogで最も踏みやすい穴

クズども · 掲載地 2018/09/25 10:31:40

MySQLの高可用性アーキテクチャにおいて、プライマリデータベースレプリケーションは非常に一般的なタイプです。

プライマリデータベースがダウンした際、サービスの可用性を確保するためにスレーブデータベースを新しいプライマリデータベースとしてアップグレードできます。同時に、クラスタ全体のQPSはスレーブライブラリを拡張することで改善できます。

マスタースレーブレプリケーションアーキテクチャの下で、MySQLはbinlogを使ってマスタースレーブデータの一貫性を実現します。

上の図に示されているように、MySQLのマスタースレーブ複製は主に以下のステップで構成されています

1. バイナリログの変更をマスターログ

2. スレーブio_threadメインライブラリのビンログを要求し、その結果得られたビンログをリレーログに書き込みます

3. リレーログのイベントをやり直すsql_threadスレー

BinlogはMySQLのマスタースレーブレプリケーションのリンクであるだけでなく、他の目的も果たしています。たとえば：

1. mysqlbinlogツールを使ってbinlogファイルを解析し、ポイントインタイムのデータベースリカバリーを実行します。

2. binlogイベントに基づくデータベースのフラッシュバック(MariaDBは直接mysqlbinlogをフラッシュバックとして利用できます)

3. GitHubのオープンソースのオンラインテーブル変更ツールgh-ostもbinlogを通じて実装されています

4. ビンログを解析することで、段階的に購読・消費も可能です

Binlogは非常に便利ですが、日常の運用やメンテナンスの過程で問題に直面するのは避けられません。ここにbinlogに関連するいくつかの誤りを挙げます。

よくある質問の一つ

現象

mysqlbinlog5.5が解析すると、mysql5.7のbinlogファイルが表示されます

ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.

原因分析

MySQL 5.6や他のより上位のbinlogファイルでは、GTIDイベントなどの新しいbinlogイベントが追加されました。

MySQL5.5のmysqlbinlogはこのようなbinlogイベントを認識していません。

回避策

mysqlbinlogの上位バージョンを使って、下位バージョンのmysqlで生成されるbinlogを解決してください

よくある質問2

現象

健康なmysqlサーバーにスレーブステータスが表示されます

Last_SQL_Error:リレーログ読み取り失敗:リレーログイベントエントリを解析できませんでした。
考えられる理由は、マスターのバイナリログが破損している(バイナリログに「mysqlbinlog」を実行して確認できます)、
スレーブのリレーログが破損しています(リレーログに「mysqlbinlog」を実行して確認できます)。
ネットワークの問題や、マスターやスレーブのMySQLコードのバグなどです。
マスターのバイナリログやスレーのリレーログを確認したい場合は、
このスレーブに「SHOW SLAVE STATUS」を発行することで、彼らの名前を知ることができます。

原因分析

リレーログのエントリは、マスターライブラリのビンログエラー、スレーブライブラリのリレーログエラー、ネットワークの問題やバグにより読み取れません。通常、ネットワーク障害やスレーブライブラリへの過度な負荷が原因で、誤ったリレーログ形式が発生します。

回避策

現在の同期時刻を特定し、マスター・スレーブ同期をリセットすると、新しいリレーログが生成され、マスター・スレーブ同期が復元されます。

「show slave status\G」の出力から、以下の情報が得られます:

Relay_Master_Log_File: mysql-bin.002540 // スレーブライブラリがbinlogExec_Master_Log_Pos マスターを読み込む: 950583017 // スレーブ上で実行された位置位置ポイント
スレーブを停止し、スレーブが読み込んだbinlogファイルと実行された位置から同期を再度設定します。

Relay_Master_Log_File: mysql-bin.002540 // スレーブライブラリがbinlogExec_Master_Log_Pos マスターを読み込む: 950583017 // スレーブ上で実行された位置位置ポイント

よくある質問3

現象

ダウンタイムエラー後にスレーブステータスを表示する復元:

Last_SQL_Error: リレーログ位置の初期化エラー:バイナリログからヘッダーを読み取るI/Oエラー
Last_SQL_Error:リレーログ位置の初期化エラー:Binlogのマジックナンバーが悪い; このバージョンのMySQLでは使えないバイナリログファイルではありません

原因分析

停電、マザーボードの焼失など、または不正なシャットダウンによるリレービンファイルの破損

回避策

同じ質問2。

relay_log_recovery = 1 も設定可能です。

スレーブがライブラリからダウンすると、リレーログが破損し、ログの一部が処理されない場合、リレーログは自動的に放棄され、ログはマスターから再取得され、リレーログの復元が完了します。

よくある質問4

現象

ライブラリマシンからの再起動後にマスターを切り替えると発生します

エラー(コード1201):マスター情報構造を初期化できませんでした。さらに多くのエラーメッセージはMySQLエラーログで確認できます
又は

エラー1872(HY000):スレーブがリポジトリからリレーログ情報構造を初期化しませんでした

原因分析

停電、マザーボードの焼損などのダウンタイム、または不正なシャットダウンで master.info や realy-log.info ファイルに損傷が生じること

回避策

スレーブ>すべてをスレーブにリセットし、マスターをに変更します

予防措置

プロファイル設定

relay_log_info_repository=テーブル
master_info_repository=テーブル
MySQL 5.6.5 mysql.slave_master_info and mysql.slave_relay_log_infoのストレージエンジンはデフォルトでMyISAMに設定されており、InnoDBのストレージエンジンに変更する必要があります

ALTERテーブルmysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info表はイベントsync_master_info後に更新されます。

テーブルmysql.slave_relay_log_infoトランザクションコミットごとに更新されます。

よくある質問5

現象

マスタースレーブbinlog_format元々は文で、メインデータベースbinlog_format行に変えた後、ライブラリから「スレーブ状態表示」が表示されます。

Last_Error: 行イベントを実行するエラー:「文を実行できません:文は行形式で、BINLOG_FORMAT = STATEMENTなのでバイナリログに書き込むことが不可能です。」

原因分析

メインデータベースbinlog_formatが行で、スレーブライブラリbinlog_formatがステートメントの場合、上記のエラーが発生します。

しかし、メインライブラリbinlog_formatステートメント、スレーブライブラリはbinlog_format行です。

また、メインのデータベースbinlog_formatが行の場合、データベースbinlog_formatが混在している場合はエラーは報告されません。

もしあなたのSQLスレッドが確かに
binlog_format=STATEMENT ROWイベントを受け取ると停止します。その
その理由は、そのROWイベントをSTATEMENT形式(時にROW注入と呼ぶこともあります)でログできないためです。
BINLOG文またはスレーブのSQLスレッドによって実行されるROWイベント)
詳細理由の参考:https://bugs.mysql.com/bug.php?id=69095

回避策

奴隷>奴隷を止めろ;
SLAVE> SET GLOBAL binlog_format=MIXED;
SLAVE> START SLAVE;

よくある質問番号6

現象

mysql5.6をmysql5.5に同期する際のエラー

Last_IO_Error:バイナリログからデータを読み取った際にマスターから致命的なエラー1236が発生しました:「スレーブはマスターがログに設定されているチェックサムではレプリケーションイベントを処理できません; 最初のイベント「mysql-bin.000001」は4で、最後のイベントは「mysql-bin.000001」から120で読み込まれ、最後のバイトは「mysql-bin.000001」から120で読み取られました。

原因分析

プライマリサーバー上で動作するSQL文が、ソフトウェアやハードウェア、またはネットワークの伝送エラーによりサーバー上で実行されるSQL文と矛盾する(イベント破損と呼ばれる)問題を解決するため、MySQL 5.6はレプリケーションイベントチェックサム関数を追加しています。イベントがバイナリログに書き込まれると、チェックサムもバイナリログに書き込まれ、イベントがネットワークを通じてスレーブに送信された後、スレーブ上で検証され、スレーブのリレーログに書き込まれます。各ステップでイベントとチェックサムが記録されるため、問題の原因をすぐに特定できます。

mysql5.6.5以降のバージョンbinlog_checksumでは、デフォルト値はcrc32です。

以前のバージョンbinlog_checksumデフォルト値は「0」でした

解決

Slave> set global binlog_checksum=none

よくある質問7

現象

ディスクがいっぱいになったら、binlogファイルとmysql-bin.indexファイルを手動でクリーンアップしてください

「表示バイナリログは空ですが、表示マスターステータスは通常です。」

mysql>バイナリログ表示; Empty set (0.00 sec)mysql> show master status;
+------------------+-----------+--------------+------------------+
| ファイル | ポジション | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 |             |                |
+------------------+-----------+--------------+------------------+

原因分析

mysql-bin.indexファイルを確認した後、最初の空欄を見つけました。

mysqlのソースコードrpl_master.cc:show_binlogs()には以下のコードがあります:

/* The file ends with EOF or empty line */
  一方((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
空白行は文書の終わりとみなされます

(参考文献)https://yq.aliyun.com/articles/213657記事)

予防措置

binlogを手動で削除したり、mysql-bin.indexファイルを手動で編集したりしないでください。やり方が分かっていなければ、自分で地雷を掘ってしまうかもしれません!

概要

DBAは、MySQLの新しいバージョンごとにbinlogの改善点(例えばバージョン5.6で追加されたgtid機能やバージョン5.7のEnhanced Multi-threaded Slavesなど)に注意を払い、各パラメータの意味を詳細に理解することで、エラーに直面したときにその意味を理解し、問題を容易に解決できるようにする必要があります。

[出典] mysql Binlogで最も踏みやすい穴

関連記事

閲覧したセクション