MySQL复制原理及应用场景

作者: 古飞_数据 | 来源:发表于2022-10-06 16:01 被阅读0次

MySQL复制原理及应用场景
问题册
msyql 主从复制原理
Mysql-Master-Slave主从配置（1）
mysql 主从基础知识笔记
思科设备静态路由配置
主从复制 & MHA
MySQL主从复制原理、半同步操作步骤及原理（摘选）
TimesTen
Redis缓存总结

1.复制原理
2.复制使用场景
3.MySQL复制在５.７，８.０中的增强点

master:
dump_thread
Slave
IO_Threrad
写relay-log
SQL_Thread
读取relay-log

io_thread和主库时一个tcp的连接
5.7增强: 独立了dump_thread

https://dev.mysql.com/worklog/

5.5,5.6 不能用半同步

复制分类

       异步复制
       半同步复制(MySQL 5.5)
       增强半同步复制(MySQL 5.7)
       Binlog group commit(MySQL 5.7)
       MySQL Group Replication (MGR)复制(MySQL 5.7,MySQL 8.0)
       MySQL 8.0 writeset (io_thread)

Binlog format:
statement
row
mixed

GTID特点:
给每个事务做一个唯一的编号

小于5.1版本 用的是statement
delete from tb limit 1;
insert into(c1) values(uuid());
delete from tb order by c2 asc limit 1;

show global variables like 'binlog_format';
set global binlog_format='row';

问题,每5分钟产生一个binlog文件
排查方式
set global general_log=1;
flush logs

主从环境下,先改从库的format

在data目录下有一个auto.cnf文件记录了server-uuid

MGR在mutil-primary模式下是 区间段的uuid,不连续


stop slave; start slave;
pt-table-checksum

基于语句级的复制
binlog_format=statement

[mysqld]
binlog_format= 'statement'

·优点:
 Bin log文件较小
   日志是包含用户执行的原始SQL，方便统计和审计
   出现最早可binlog兼容较好
   Binlog方便阅读,方便故障修复

·缺点:
    存安全隐患，可能导致主从不一致
    对一些系统函数不能准复制或是不能复制
- Load_file()
- uuid()
- User()
- Found_rows ()
- sysdate ()

create table wubx(id int not null, c1 varchar(128),primary key(id));
insert into wubx(id,c1) values(1,'abc');
insert into wubx(id,c1) values(2,'uuid');
show master status;

[mysqld]
binlog_format= 'row'


·解决办法:使用Row格式的binlog
·优点:
    相比STATEMENT更加安全的复制格式
    在某些情况下复制速度更快(SQL复杂，表有主建)·
    系统的特殊函数也可以复制
    更少的锁

·缺点:
Binary log 比较大(支持binlog_row_image)
单语句更新[删除]表的行数过多，会形成大量binlog
无法从bin log看见用户执行的SQL (Event:
binlog_row_query_log_events,记录用户的query)

binlog是一个二进制文件单位event,gtid event

1.GTID
2.query--> begin
3.rows_query -->原生SQL     可省略
4.table_map --> table_id(table name)
5.write_rows  --> event
6.Xid             --> commit

其中第三个步骤可以省略

sql_thread在row格式下对索引的利用

image.png

slave_rows_search_algorithms 8.0.18 此参数没有了

资料

https://blog.csdn.net/n88Lpo/article/details/100144083

2.复制使用场景

●主库压力较大抗不住
●把读压力分担一部分到从库上
●业务高峰数据库连接数太多
●例如高峰的认证，只需要把这个业务分拆到从库上
●有一些大的SQL出现不多，不好优化->专用从库
●后面的统计分析类的SQL
●利用从库做高可用切换

利用主从复制:实现多IDC架构
误区
      所有的SQL都要读写分离
      主从结构数据是不一致的
      过分担心主从数据延迟

3.MySQL复制在５.７，８.０中的增强点

MGR,GTID

５.７版本增强

●在线支持传统复制到GTID复制切换
●在线复制过滤规则变更
●可以利用SQL从PS库获取复制信息
●多线程复制
●半同步复制线程改进
●多源复制

8.0版本改进

●行级(write-set)并行复制
●binlog_transaction_dependency_tracking
      COMMIT_ORDER
      WRITESET
      WRITESET SESSION
●COMMIT_ ORDER
●基于锁的并发策略
●WRITESET
基于主键的并发策略，可以并发的执行同一个Session内的事务，具有最好的性能。
●WRITESET_ SESSION
●基于主键的并发策略，不可以并发执行同一-个Session内的事务。

binlog_transaction_dependency_tracking = writeset
transaction_write_set_extraction=xxhash64
binlog_transaction_dependency_history_size=25000

复制延时

select * from performance_schema.replication_applier_status_by_worker\G

original_commit_timestamp             原始主库提交的时间
immediate_commit_timestamp        当前节点执行时间

针对多源复制
       定制每个channel的过滤规则
配置Filter
       --replication-do-db=channel:database_name
       CHANGE REPLICATION FILTER REPLICATE_DO_DB=(db1) FOR CHANNEL channel_1;
监控Filter的配置和使用情况
       Performance_schem.replication_applier_filters