mysqlMGR
mysqlMGR组复制
在mysql5.7.17之后出现了组复制，这种技术。
为了复制环境只，数据一致性考虑，多写这种场景研发的技术。
架构原理
mgr针对的表都是要有主键的
mgr会有多主，单主，在主库发生事务修改的相关信息，和产生的binlog打包生成一个写集合（write set）
在事务提交commit之前广播到各个节点
1、主库发生新的事务，在事务执行期间，会将事务产生的binlog刷到binlog cache
2、主库生成write_set ，如果主库发生100个事务会有100个write_set 包含binlog日志+库表hash值 写入一个统一的内存区域（rpl_transaction_write_set_ctx）在binlog prepare之后，在binlog commit之后，通过gcs_module传输各个节点
3、通过各个节点的certify验证（paxos）投票机制，判断此次事务是否满足半数以上节点通过（不冲突）
4主库binlog flush 到磁盘
5 此时各个从库开始回放日志（relaylog）
半同步复制和增强半同步原理
mysql工作原理是wcl工作机制会先将日志刷到磁盘
2pc
两阶段
prepare和commit两阶段
1、prepare分为binlog prepare和redo prepare 其中binlog prepare不做操作，redo prepare 会刷新到磁盘redo还是(prepare
状态）
2、commit 提交阶段会将binlog一组一组的刷新到磁盘txid，last_commit ， innodb存储引擎会将redo日志打上commit的标记，事务管理器会将binlog打上commit
数据库挂了，起来时候，查看binlog最后一个有没有last_commit redolog进行前滚，发现没有提交 undo就会进程回滚
5，7之后会在binlog末尾加个xid，即使redo没有commit标记数据也算落地
主从复制原理
异步复制
主库binlogdump会把binlog解析出来以事件的方式传给io线程
半同步复制
在5.5版本中写入到relaylog中就要返回ack给主库，在redo的commit的阶段等待
增强半同步5.7后
在ack等待阶段不同，在binlogsync阶段
prepare 阶段：将 XID（内部 XA 事务的 ID） 写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
commit 阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；
备份
mysqldump 锁不锁表 加参数针对innodb的表是记录快照的
pxb 针对innodb的是热备，针对别的表是加锁的
物理备份，拷贝数据文件，会记录备份中的redo ， 恢复的时候会cr滚动
8.0之后会有clone-plugin插件
限制a和b的版本得是一样的
当前的这个数据库做个备份
远程拉去一个数据库的数据
mvcc多版本并发控制
主要是解决读写之间的控制
更改一行的时候，写是不允许的，读是允许的
通过undo生成多版本快照+readview（可见性）
通过trx_id和回滚指针
rc级别下 事物可以立即读取到其他事物commit过的readview 每次的语句都会创建
rr级别 在事物开始第一次查询开始生成一个一致性readview直到事物结束 事物开始的时候会创建readview
创建readview
1获取一个kernel_mutex 内存锁
2遍历trx_sys的trx_list链表，获取所有活跃事物创建readview
获取到当前活跃的事物链表
m_ids
min_trx_id=当前链表中最小的事物id
max_trx_id=下一个事物要分配的的事物id
creator_trx_id=当前readview
用db_trx_id去判断在没在当前活跃链表中，如果小于最小的min_trx_id，就证明这个事物是提交过的，
如果db_trx_id大于min_trx_id不在当前活跃列表内，max_trx_id=看看下一个要分配的是不是大于db_trx_id如果大于证明事物已经提交了
如果出现ddl操作会打破这种操作
发布评论