问题描述
MySQL复制不定期出现问题,报错为:Failed to flush master info,但具体原因尚未定位到。
涉及代码
查看MySQL 5.7.34版本的代码:
int flush_master_info(Master_info* mi, bool force)
{
DBUG_ENTER("flush_master_info");
assert(mi != NULL && mi->rli != NULL);
/*
The previous implementation was not acquiring locks.
We do the same here. However, this is quite strange.
*/
/*
With the appropriate recovery process, we will not need to flush
the content of the current log.
For now, we flush the relay log BEFORE the master.info file, because
if we crash, we will get a duplicate event in the relay log at restart.
If we change the order, there might be missing events.
If we don't do this and the slave server dies when the relay log has
some parts (its last kilobytes) in memory only, with, say, from master's
position 100 to 150 in memory only (not on disk), and with position 150
in master.info, there will be missing information. When the slave restarts,
the I/O thread will fetch binlogs from 150, so in the relay log we will
have "[0, 100] U [150, infinity[" and nobody will notice it, so the SQL
thread will jump from 100 to 150, and replication will silently break.
*/
mysql_mutex_t *log_lock= mi->rli->relay_log.get_log_lock();
mysql_mutex_lock(log_lock);
int err= (mi->rli->flush_current_log() ||
mi->flush_info(force));
mysql_mutex_unlock(log_lock);
DBUG_RETURN (err);
}
在执行时抛出异常:
//============================================//
if (flush_master_info(mi, FALSE))
{
mi->report(ERROR_LEVEL, ER_SLAVE_FATAL_ERROR,
ER(ER_SLAVE_FATAL_ERROR),
"Failed to flush master info.");
mysql_mutex_unlock(&mi->data_lock);
goto err;
}
//============================================//
if (flush_master_info(mi, force_flush_mi_info))
{
error= 1;
sql_print_error("Failed to flush master info file.");
}
解决办法
重启复制即可修复。
标签:info,log,--,mi,will,Failed,master,flush From: https://www.cnblogs.com/gaogao67/p/17297166.html