MySQL 5.7 LOGICAL_CLOCK 并行复制原理及实现分析
MySQL 5.7 LOGICAL_CLOCK 并行复制原理及实现分析
在MySQL5.7 引入基于Logical clock的并行复制方案前，MySQL使用基于Schema的并行复制，使不一样db下的DML操做能够在备库并发回放(在优化后，能够作到不一样table下并发)。可是若是业务在Master端高并发写入一个库（或者表），那么slave端就会出现较大的延迟。基于schema的并行复制，Slave做为只读实例提供读取功能时候能够保证同schema下事务的因果序（Causal Consistency，本文讨论Consistency的时候均假设Slave端为只读），而没法保证不一样schema间的。例如当业务关注事务执行前后顺序时候，在Master端db1写入T1，收到T1返回后，才在db2执行T2。但在Slave端可能先读取到T2的数据，才读取到T1的数据。mysql
MySQL 5.7的LOGICAL CLOCK并行复制，解除了schema的限制，使得在主库对一个db或一张表并发执行的事务到slave端也能够并行执行。Logical Clock并行复制的实现，最初是Commit-Parent-Based方式，同一个commit parent的事务能够并发执行。但这种方式会存在保证没有冲突的事务不能够并发，事务必定要等到前一个commit parent group的事务所有回放完才能执行。后面优化为Lock-Based方式，作到只要事务和当前执行事务的Lock Interval都存在重叠，即保证了Master端没有锁冲突，就能够在Slave端并发执行。LOGICAL CLOCK能够保证非并发执行事务，即当一个事务T1执行完后另外一个事务T2再开始执行场景下的Causal Consistency。sql
LOGICAL_CLOCK Commit-Parent-Based 模式
因为在MySQL中写入是基于锁的并发控制，因此全部在Master端同时处于prepare阶段且未提交的事务就不会存在锁冲突，在Slave端执行时均可以并行执行。所以能够在全部的事务进入prepare阶段的时候标记上一个logical timestamp（实现中使用上一个提交事务的sequence_number），在Slave端一样timestamp的事务就能够并发执行。数据库
Master端
在SQL层实现一个全局的logical clock： commit_clock。并发
当事务进入prepare阶段的时候，从commit_clock获取timestamp并存储在事务中。app
在transaction在引擎层提交以前，推高commit_clock。这里若是在引擎层提交以后，即释放锁后操做commit_clock，就可能出现冲突的事务拥有相同的commit-parent，因此必定要在引擎层提交前操做。函数
Slave端
事务拥有相同的commit-parent就能够并行执行，不一样commit-parent的事务，须要等前面的事务执行完毕才能够执行。高并发
LOGICAL_CLOCK Lock-Based模式原理及实现分析
Commit-Parent-Based 模式，用事务commit的点将clock分隔成了多个intervals。在同一个time interval中进入prepare状态的事务能够被并发。例以下面这个例子（引自WL#7165）：性能
Trx1 ------------P----------C-------------------------------->
|
Trx2 ----------------P------+---C---------------------------->
| |
Trx3 -------------------P---+---+-----C---------------------->
| | |
Trx4 -----------------------+-P-+-----+----C----------------->
| | | |
Trx5 -----------------------+---+-P---+----+---C------------->
| | | | |
Trx6 -----------------------+---+---P-+----+---+---C---------->
| | | | | |
Trx7 -----------------------+---+-----+----+---+-P-+--C------->
| | | | | | |
每个水平线表明一个事务。时间从左到右。P表示prepare阶段读取commit-parent的时间点。C表示事务提交前增长全局counter的时间点。垂直线表示每一个提交划分出的time interval。优化
从上图能够看到由于Trx5和Trx6的commit-parent都是Trx2提交点，因此能够并行执行。可是Commit-Parent-Based模式下Trx4和Trx5不能够并行执行，由于Trx4的commit-parent是Trx1的提交点。Trx6和Trx7也不能够并行执行，Trx7的commit-parent是Trx5的提交点。但Trx4和Trx5有一段时间同时持有各自的全部锁，Trx6和Trx7也是，即它们之间并不存在冲突，是能够并发执行的。ui
针对上面的状况，为了进一步增长复制性能，MySQL将LOGICAL_CLOCK优化为Lock-Based模式，使同时hold住各自全部锁的事务能够在slave端并发执行。
Master端
-
添加全局的事务计数clock产生事务timestamp和记录当前最大事务timestamp的clock。
class MYSQL_BIN_LOG: public TC_LOG { ... public: /* Committed transactions timestamp */ Logical_clock max_committed_transaction; /* "Prepared" transactions timestamp */ Logical_clock transaction_counter; ... } - 对每一个事务存储其lock interval，并记录到binlog中。
在每一个transaction中添加下面两个member。
class Transaction_ctx
{
...
int64 last_committed;
int64 sequence_number;
...
}
其中last_committed表示事务lock interval的起始点，是事务全部的锁都得到时候的max-commited-timestamp。因为在一个事务执行过程当中，数据库没法知道当前的锁是否为最后一个，在实际实现的时候，会对每次DML操做都更新一次last_committed。
static int binlog_prepare(handlerton *hton, THD *thd, bool all)
{
...
if (!all)//DML操做
{
Logical_clock& clock= mysql_bin_log.max_committed_transaction;
thd->get_transaction()->
store_commit_parent(clock.get_timestamp());//更新transaction中的last_committed
sql_print_information("stmt prepare");
}
...
}
class Transaction_ctx
{
...
void store_commit_parent(int64 last_arg)
{
last_committed= last_arg;
}
...
}
sequence_number为lock interval的结束点，理论上是commit释放锁的时间点。在实现中选择在最后更新last_committed以后，引擎层commit前的一个时刻便可，知足这一条件的状况下时间点越靠后越能得到更大lock interval，Slave执行也就能得到更大并发度。因为咱们须要把该信息记录到binlog中，因此实现中在flush binlog cache到binlog文件中的时候记录。并且当前的MySQL5.7已经disable掉了设置GTID_MODE为OFF的功能，会强制记录GTID_EVENT。这样事务的last_committed和sequence_number就记录在事务开头的Gtid_log_event中。
int
binlog_cache_data::flush(THD *thd, my_off_t *bytes_written, bool *wrote_xid)
{
...
if (flags.finalized)
{
trn_ctx->sequence_number= mysql_bin_log.transaction_counter.step();//获取sequence_number
if (!error)
if ((error= mysql_bin_log.write_gtid(thd, this, &writer)))//记录Gtid_log_event
...
}
bool MYSQL_BIN_LOG::write_gtid(THD *thd, binlog_cache_data *cache_data,
Binlog_event_writer *writer)
{
...
Transaction_ctx *trn_ctx= thd->get_transaction();
Logical_clock& clock= mysql_bin_log.max_committed_transaction;
DBUG_ASSERT(trn_ctx->sequence_number > clock.get_offset());
int64 relative_sequence_number= trn_ctx->sequence_number - clock.get_offset();
int64 relative_last_committed=
trn_ctx->last_committed <= clock.get_offset() ?
SEQ_UNINIT : trn_ctx->last_committed - clock.get_offset();
...
Gtid_log_event gtid_event(thd, cache_data->is_trx_cache(),
relative_last_committed, relative_sequence_number,//Gtid_log_event中记录relative_last_committed和relative_sequence_number
cache_data->may_have_sbr_stmts());
...
}
同时能够看到记录在Gtid_log_event中的sequence_number和last_committed使用的是相对当前binlog文件clock的值。即每一个binlog file中事务的last_commited起始值为0，sequence_number为1。因为binlog切换后，须要等待上一个文件的事务执行完，因此这里记录相对值并不会致使冲突事务并发执行。因为server在每次启动的时候都会生成新的binlog文件，这样作带来的一个明显好处是max_committed_transaction和transaction_counter不须要持久化。
- 更新max_committed_transaction。
max_committed_transaction的更新必定要在引擎层commit（即锁释放）以前，若是以后更新，释放的锁被其余事务获取到而且获取到last_committed小于该事务的sequence_number，就会致使有锁冲突的事务lock interval却发生重叠。
void
MYSQL_BIN_LOG::process_commit_stage_queue(THD *thd, THD *first)
{
...
if (head->get_transaction()->sequence_number != SEQ_UNINIT)
update_max_committed(head);
...
if (head->get_transaction()->m_flags.commit_low)
{
if (ha_commit_low(head, all, false))
head->commit_error= THD::CE_COMMIT_ERROR;
...
}
Slave端
当事务的lock interval存在重叠，即表明他们的锁没有冲突，能够并发执行。下图中L表明lock interval的开始，C表明lock interval的结束。
- 可并发执行: Trx1 -----L---------C------------> Trx2 ----------L---------C-------> - 不可并发执行: Trx1 -----L----C-----------------> Trx2 ---------------L----C------->
slave端在并行回放时候，worker的分发逻辑在函数Slave_worker Log_event::get_slave_worker(Relay_log_info rli)中，MySQL5.7中添加了schedule_next_event函数来决定是否分配下一个event到worker线程。对于DATABASE并行回放该函数实现为空。
bool schedule_next_event(Log_event* ev, Relay_log_info* rli)
{
...
error= rli->current_mts_submode->schedule_next_event(rli, ev);
...
}
int
Mts_submode_database::schedule_next_event(Relay_log_info *rli, Log_event *ev)
{
/*nothing to do here*/
return 0;
}
Mts_submode_logical_clock的相关实现以下。
在Mts_submode_logical_clock中存储了回放事务中已经提交事务sequence_number的low-water-mark lwm。low-water-mark表示该事务已经提交，同时该事务以前的事务都已经提交。
class Mts_submode_logical_clock: public Mts_submode
{
...
/* "instant" value of committed transactions low-water-mark */
longlong last_lwm_timestamp;
...
longlong last_committed;
longlong sequence_number;
在Mts_submode_logical_clock的schedule_next_event函数实现中会检查当前事务是否和正在执行的事务冲突，若是当前事务的last_committed比last_lwm_timestamp大，同时该事务前面还有其余事务执行，coordinator就会等待，直到确认没有冲突事务才返回。这里last_committed等于last_lwm_timestamp的时候，实际这两个值各自事务的lock interval是没有重叠的，也可能有冲突。在前面lock-interval介绍中，这种状况是前面一个事务执行结束，后面一个事务获取到last_committed为前面一个的sequence_number的状况，他们的lock interval没有重叠。但因为last_lwm_timestamp更新表示事务已经提交，因此等于的时候，该事务也能够执行。
int
Mts_submode_logical_clock::schedule_next_event(Relay_log_info* rli,
Log_event *ev)
{
...
switch (ev->get_type_code())
{
case binary_log::GTID_LOG_EVENT:
case binary_log::ANONYMOUS_GTID_LOG_EVENT:
// TODO: control continuity
ptr_group->sequence_number= sequence_number=
static_cast<Gtid_log_event*>(ev)->sequence_number;
ptr_group->last_committed= last_committed=
static_cast<Gtid_log_event*>(ev)->last_committed;
break;
default:
sequence_number= last_committed= SEQ_UNINIT;
break;
}
...
if (!is_new_group)
{
longlong lwm_estimate= estimate_lwm_timestamp();
if (!clock_leq(last_committed, lwm_estimate) && //若是last_committed > lwm_estimate
rli->gaq->assigned_group_index != rli->gaq->entry) //当前事务前面还有执行的事务
{
...
if (wait_for_last_committed_trx(rli, last_committed, lwm_estimate))
...
}
...
}
}
@return true when a "<=" b,
false otherwise
*/
static bool clock_leq(longlong a, longlong b)
{
if (a == SEQ_UNINIT)
return true;
else if (b == SEQ_UNINIT)
return false;
else
return a <= b;
}
bool Mts_submode_logical_clock::
wait_for_last_committed_trx(Relay_log_info* rli,
longlong last_committed_arg,
longlong lwm_estimate_arg)
{
...
my_atomic_store64(&min_waited_timestamp, last_committed_arg);//设置min_waited_timestamp
...
if ((!rli->info_thd->killed && !is_error) &&
!clock_leq(last_committed_arg, get_lwm_timestamp(rli, true)))//真实获取lwm并检查当前是否有冲突事务
{
//循环等待直到没有冲突事务
do
{
mysql_cond_wait(&rli->logical_clock_cond, &rli->mts_gaq_LOCK);
}
while ((!rli->info_thd->killed && !is_error) &&
!clock_leq(last_committed_arg, estimate_lwm_timestamp()));
...
}
}
上面循环等待的时候，会等待logical_clock_cond条件而后作检查。该条件的唤醒逻辑是：当回放事务结束，若是存在等待的事务，即检查min_waited_timestamp和当前curr_lwm(lwm同时会被更新)，若是min_waited_timestamp小于等于curr_lwm，则唤醒等待的coordinator线程。
void Slave_worker::slave_worker_ends_group(Log_event* ev, int error)
{
...
if (mts_submode->min_waited_timestamp != SEQ_UNINIT)
{
longlong curr_lwm= mts_submode->get_lwm_timestamp(c_rli, true);//获取并更新当前lwm。
if (mts_submode->clock_leq(mts_submode->min_waited_timestamp, curr_lwm))
{
/*
There's a transaction that depends on the current.
*/
mysql_cond_signal(&c_rli->logical_clock_cond);
}
}
...
}
LOGICAL_CLOCK Consistency的分析
不管是Commit-Parent-Based仍是Lock-Based，Master端一个事务T1和其commit后才开始的事务T2在Slave端都不会被并发回放，T2必定会等T1执行结束才开始回放。所以LOGICAL_CLOCK并发方式在Slave端只读时候的上述场景中可以保证Causal Consistency。但若是事务T2只是等待事务T1执行commit成功后再执行commit操做，那么事务T1和T2在Slave端的执行顺序就没法获得保证，用户在Slave端读取可能先读到T2再读到T1的提交。这种场景就没法知足Causal Consistency。
slave_preserve_commit_order的简要介绍
咱们在前面的介绍中了解到，当slave_parallel_type为DATABASE和LOGICAL_CLOCK的时候，在Slave端的读取操做都存在场景没法知足Causal Consistency，均可能存在Slave端并行回放时候事务顺序发生变化。复制进行中时业务方可能会在某一时刻观察到Slave的GTID_EXECUTED有空洞。那若是业务须要完整的保证Causal Consistency呢，除了使用单线程复制，是否能够在并发回放的状况下知足这一需求？
MySQL提供了slave_preserve_commit_order，使LOGICAL_CLOCK的并发执行时候得到Sequential Consistency。这里Sequential Consistency除了知足以前分析的Causal Consistency的各个场景外，还知足即便T1T2均并发执行的时候，第三个客户端在主库观察到T1先于T2发生，在备库也会观察到T1先于T2发生，即在备库得到和主库彻底一致的执行顺序。
slave_preserve_commit_order实现的关键是添加了Commit_order_manager类，开启该参数会在获取worker时候向Commit_order_manager注册事务。
Slave_worker *
Mts_submode_logical_clock::get_least_occupied_worker(Relay_log_info *rli,
Slave_worker_array *ws,
Log_event * ev)
{
...
if (rli->get_commit_order_manager() != NULL && worker != NULL)
rli->get_commit_order_manager()->register_trx(worker);
...
}
void Commit_order_manager::register_trx(Slave_worker *worker)
{
...
queue_push(worker->id);
...
}
在事务进入FLUSH_STAGE前， 会等待前面的事务都进入FLUSH_STAGE。
int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit)
{
...
if (has_commit_order_manager(thd))
{
Slave_worker *worker= dynamic_cast<Slave_worker *>(thd->rli_slave);
Commit_order_manager *mngr= worker->get_commit_order_manager();
if (mngr->wait_for_its_turn(worker, all)) //等待前面的事务都进入FLUSH\_STAGE
{
thd->commit_error= THD::CE_COMMIT_ERROR;
DBUG_RETURN(thd->commit_error);
}
if (change_stage(thd, Stage_manager::FLUSH_STAGE, thd, NULL, &LOCK_log))
DBUG_RETURN(finish_commit(thd));
}
...
}
bool Commit_order_manager::wait_for_its_turn(Slave_worker *worker,
bool all)
{
...
mysql_cond_t *cond= &m_workers[worker->id].cond;
...
while (queue_front() != worker->id)
{
...
mysql_cond_wait(cond, &m_mutex);//等待condition
}
...
}
当该事务进入FLUSH_STAGE后，会通知下一个事务的worker能够进入FLUSH_STAGE。
bool
Stage_manager::enroll_for(StageID stage, THD *thd, mysql_mutex_t *stage_mutex)
{
bool leader= m_queue[stage].append(thd);
if (stage == FLUSH_STAGE && has_commit_order_manager(thd))
{
Slave_worker *worker= dynamic_cast<Slave_worker *>(thd->rli_slave);
Commit_order_manager *mngr= worker->get_commit_order_manager();
mngr->unregister_trx(worker);
}
...
}
void Commit_order_manager::unregister_trx(Slave_worker *worker)
{
...
queue_pop();//退出队列
if (!queue_empty())
mysql_cond_signal(&m_workers[queue_front()].cond);//唤醒下一个
...
}
在保证binlog flush的顺序后，经过binlog_order_commit便可获取一样的提交顺序。
浅谈LOGICAL_CLOCK依然存在的不足
LOGICAL_CLOCK为了准确性和实现的须要，其lock interval实际实现得到的区间比理论值窄，会致使本来一些能够并发执行的事务在Slave中没有并发执行。当使用级联复制的时候，这会后面层级的Slave并发度会愈来愈小。
- 1. MySQL 5.7 并行复制实现原理与调优
- 2. MYSQL 5.7 并行复制实现原理与调优
- 3. 网易视频云：MySQL 5.7 并行复制实现原理与调优
- 4. MySQL 5.7 并行复制参数优化
- 5. MySQL 5.7新特性：并行复制原理（MTS）
- 6. MySQL并行复制
- 7. MySQL的并行复制
- 8. MySQL并行复制探索！
- 9. mysql主从复制和并行复制
- 10. MySQL 5.7基于组提交的并行复制
- 更多相关文章...
- • Git 分支管理 - Git 教程
- • MyBatis的工作原理 - MyBatis教程
- • 漫谈MySQL的锁机制
- • Java Agent入门实战（三）-JVM Attach原理与使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。