vlambda博客
学习文章列表

int flush_master_info(Master_info *mi, bool force, bool need_lock, bool do_flush_relay_log) { DBUG_TRACE; DBUG_ASSERT(mi != nullptr && mi->rli != nullptr); DBUG_EXECUTE_IF("fail_to_flush_master_info", { return 1; }); /* 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_t *data_lock = &mi->data_lock;
 if (need_lock) { mysql_mutex_lock(log_lock); mysql_mutex_lock(data_lock); } else { mysql_mutex_assert_owner(log_lock); mysql_mutex_assert_owner(&mi->data_lock); }
 int err = 0; /* We can skip flushing the relay log when this function is called from queue_event(), as after_write_to_relay_log() will already flush it. */ if (do_flush_relay_log) err |= mi->rli->flush_current_log();
 err |= mi->flush_info(force);
 if (need_lock) { mysql_mutex_unlock(data_lock); mysql_mutex_unlock(log_lock); }
 return err;}

set global sync_master_info=10000;set global sync_relay_log=10000;set global sync_relay_log_info=10000;