1.問題現象
バージョン：MySQL 5.6、従来のbinlogファイルおよびposモードで構成されたマスタースレーブレプリケーション構造を使用。
インスタンスが再起動した後、マスタースレーブレプリケーションエラーが上の図に示されています。
2.エラーの意味
エラーは2つの部分に分かれています。
最初の部分
- クライアントはマスターに位置>ファイル
サイズからレプリケーションを開始するように要求しました; - 163800795の最初のイベント「mysql-bin.000398」
、4の「./mysql-binlog.000398」から読み取られた最後のイベント、4の
「./mysql-bin.000398」から読み取られた最後のバイト
最初の部分
この部分は、メインライブラリのDUMPスレッド関数からのものです
mysql_binlog_send
->sender.run()
->Binlog_sender::init
->Binlog_sender::check_start_file
if ((file= open_binlog_file(&cache, m_linfo.log_file_name, &errmsg)) < 0)
{
set_fatal_error(errmsg);
return 1;
}
size= my_b_filelength(&cache);
end_io_cache(&cache);
mysql_file_close(file, MYF(MY_WME));
if (m_start_pos > size)
{
set_fatal_error("Client requested master to start replication from "
"position > file size");
return 1;
}
重要なのは、m_start_posとsizeの2つの値です。ここで、m_start_posは、ライブラリから読み取る必要のある位置から取得されます。また、サイズはbinlogファイルのサイズであるため、ioスレッドに必要なposポイントがbinlogファイルのサイズよりも大きい場合、当然のことながら間違っていることは容易に理解できます。
2番目の部分
この部分もDUMPスレッドから来ています
mysql_binlog_send
->sender.run()
->Binlog_sender::init
->while (!has_error() && !m_thd->killed)
#如果正常这里开始循环读取binlog event，如果前面出错则直接继续后面逻辑
#如果有读取错误则报错
my_snprintf(error_text, sizeof(error_text),
"%s; the first event '%s' at %lld, "
"the last event read from '%s' at %lld, "
"the last byte read from '%s' at %lld.",
m_errmsg,
m_start_file, m_start_pos, m_last_file, m_last_pos,
log_file, my_b_tell(&log_cache));
ここでは主にm_start_posとm_last_posを見ていきます。実際、m_start_posはライブラリから読み取る必要のある位置情報であり、前のエラーと一致しています。m_last_posは、最後に読み取られた位置であるダンプスレッドから取得されます。 、一度も読み取られていないため、先頭の位置は4位です。
3.考えられる原因
分析した結果、最も可能性の高い原因はsync_binlogに関連しているはずだと思います。
1に設定しないと、OSキャッシュがフラッシュされない可能性があります。メインライブラリサーバーがクラッシュして再起動すると、この問題が発生しやすくなります。
小さなグーグルクエリは、これらのエラーのほとんどがサーバーのクラッシュが原因であり、sync_binlogが1に設定されていないことを発見しました。
最後に、問題のあるデータベースのメインデータベースが実際にdouble1に設定されていないことを確認します。
参照リンク：
MySQL 5.6マスタースレーブエラーの例：https：//mp.weixin.qq.com/s/7uQk5cRjfgUxyDcLS7CURg