MySQL5.6 基于db的并行复制

slave的几个类结构:

Master_info:用于IO线程的参数,包括连接master实例的信息。

Relay_log_info:用于sql线程,表示relay log相关的信息。

Slave_worker:继承Relay_log_info,包括一个job队列,用于并行的worker线程。

binlog event的类结构:

slave启动的函数栈:

dispatch_command

start_slave

start_slave_threads

start_slave_thread

start_slave:初始化master_info和relay_log_info两个对象

start_slave_threads:启动两个线程,分别是handle_slave_io
io线程,handle_slave_sql sql线程。

handle_slave_io: 启动io线程,根据master_info对象的连接信息,连接master主库。

while(!io_slave_killed(thd,mi))

request_dump:循环发送dump协议指令到master,接受event写入relay_log.

handle_slave_sql:启动sql线程,

1. 当没有使用并行复制的时候。

while (!sql_slave_killed(thd,rli))

exec_relay_log_event(thd,rli): 循环从relay_log中读取event,并执行apply。

exec_relay_log_event的调用栈:

apply_event_and_update_pos

Log_event::apply_event

Query_log_event::do_apply_event

Query_log_event::do_apply_event

2. 当设置了opt_slave_parallel_workers时,启用了并行复制

slave_start_workers:初始化relay_log_info中关于mts的变量。

slave_start_single_worker:启动多个并发线程。

handle_slave_worker:

while (!error)
         
                   
 error= slave_worker_exec_job(w,
rli):根据jobs_queue中的值,pop出event进行apply。

在Log_event::apply_event的过程中:

1,如果开启了并行:那么会把event分配给worker线程,然后结束

2,如果没有开启并行:则直接执行do_apply_event

3,如果不能并行的,需要wait_for_workers_to_finish所有worker结束后,本线程自己独立执行。

MySQL5.6 基于db的并行复制

时间: 2024-10-11 23:21:14

MySQL5.6 基于db的并行复制的相关文章

MySQL主从复制--MySQL5.6基于GTID及多线程复制

大纲 一.系统环境 二.MySQL初始化安装过程 三.基于GTID的主从模式配置过程 一.系统环境 系统环境 CentOS5.8 x86_64 master.network.com    master    172.16.1.101 slave.network.com     slave     172.16.1.105 软件包 mysql-5.6.26-linux-glibc2.5-x86_64.tar.gz(二进制通用安装包) 拓扑图 二.MySQL初始化安装过程 1.时间同步 [[emai

mysql主从复制--mysql-5.6基于GTID及多线程复制

GTID,Global Transaction Identifiers,全局事务标识符     由服务器的UUID和事务ID号组成一个唯一的标识.mysql 5.6后,事务首部会记录server UUID,追踪十分简单. UUID,Universally Unique Identifier,全局唯一标识符. A为master,B.C为slave,当A宕机时,B将成为New Master.C需将自己有的事务而B没有的事务复制给B,然后B才能成为Master. B和C双方事务的协商过程,由于GTID

mysql5.6 基于GTID及多线程复制详解

一 GTID 详解 官方文档:http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html在这篇文档里,我们可以知道全局事务 ID 的官方定义是:GTID = source_id:transaction_id MySQL 5.6 中,每一个 GTID 代表一个数据库事务.在上面的定义中,source_id 表示执行事务的主库 uuid(server_uuid),transaction_id 是一个从 1 开始的自增计数,表示在这个主库

MySQL 5.7 并行复制实现原理与调优

MySQL 5.7并行复制时代 众所周知,MySQL的复制延迟是一直被诟病的问题之一,然而在Inside君之前的两篇博客中(1,2)中都已经提到了MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进,甚至在Inside君所在的网易电商应用中已经完全消除了之前延迟长达几小时的问题.然而,Inside君发现还是有很部分小伙伴不了解这个足以载入史册的“伟大”的特性,故作分享.总之,

mysql复制原理/基于库的多线程复制原理/基于BLGC的多线程复制原理

单线程主从复制: 从库向主库请求binlog,并将binlog转存到自己的relaylog中,从库重做binlog里面的sql, 主要由以下三个线程完成. dump thread: 在主库上,发送binlog io thread: 在slave上,接收,转存,请求binlog sql thread :在slave 上,重做binlog 基于库的多线程复制原理: 从库向主库请求binlog,并将binlog转存到自己的relaylog中,从库重做binlog里面的sql, 主要由以下三个线程完成.

mysql 并行复制

并行复制,主要是解决sql_thread在高并发环境下,存在性能瓶颈.mysql5.7并行复制的思想简单易懂,一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交). 为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有: (1)DATABASE:默认值,基于库的并行复制方式 (2)LOGICAL_CLOCK:基于组提交的并行复制方式 操作步骤: 数据库版

MySQL 5.7 并行复制

一.缘由: 某天看到主从复制延时的告警有点频繁,就想着是不是彻底可以解决一下. 一般主从复制,有三个线程参与,都是单线程:Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从).复制出现延迟一般出在两个地方 1)SQL线程忙不过来(可能需要应用数据量较大,可能和从库本身的一些操作有锁和资源的冲突:主库可以并发写,SQL线程不可以:主要原因) 2)网络抖动导致IO线程复制延迟(次要原因). 二.解决办法: MySQL从5.6开始有了SQL

MySQL5.7的组提交与并行复制

从MySQL5.5版本以后,开始引入并行复制的机制,是MySQL的一个非常重要的特性. MySQL5.6开始支持以schema为维度的并行复制,即如果binlog row event操作的是不同的schema的对象,在确定没有DDL和foreign key依赖的情况下,就可以实现并行复制. 社区也有引入以表为维度或者以记录为维度的并行复制的版本,不管是schema,table或者record,都是建立在备库slave实时解析row格式的event进行判断,保证没有冲突的情况下,进行分发来实现并行

MySQL5.6基于GTID同步复制,与如何实现MySQL负载均衡、读写分离。

MySQL想必大家都不陌生,之前文章也有介绍同步复制与半同步复制,今天先来了解下什么是GTID. GTID(global transaction ID)全局事务ID,是由服务器的UUID+一段随机数事务ID. 特性:从服务器从主服务器复制过来的事务,GTID不变,也就是说一个事务在全局复制架构中的ID不变. 有什么用: 在MySQL集群中,当Master故障时,需要从Slave中挑选一个提升为Master可以基于GTID对比其他Slave来保证数据的一致性. MySQL主从同步如何配置数据过滤