今天的作业：整理一下传统复制的搭建方式
整理一下GTID的复制搭建方式
mysql replication = 异步的复制
半同步的复制
有没有完全同步的复制？
PXC 是同步的复制
slave数据的镜象
特别在GTID环境更不能在Slave上做写入操作
如果非要在slave上写操作可以set sql_binary_log =0;忽略session
slave拿到master上的日志，在slave重放
是并发还是串行呢？串行
5.6多了新特性基于库的并行同步
IO是线程是一个， SQL线程和ＤＢ一样多
binarylog里面放的什么东西？
用户写入的数据的语句包括变更记录到binarylog里
那么拿到日志重放之后可以还原这部分数据等于说还原了这部分操作
mysql cluster : 基本都是指复制结构
升级是说把从库升级到高版本然后把从库升级为主库
percona-xtradb-cluster
statement base replication
基于SQL 语句的复制
binary log 只会记录用户写入的log
select就不会记入了
service-id不能相同，主库要有log-bin
日志的格式在配置文件里设置
[mysqld]
binlog_format=statement|row|mixed
记录binlog 的最小单位是什么
Event
header event
table_map_event
query_event
begin
write_rows
update_rows
等写数据的_event
commit
mysql-bin.xxxxxx
binary log index
mysql-bin.index
是已经落伍掉的
如果开了gtad 就不用管这个（statement）了
基于语句数据安全没有保证
load file
在语句下是不能复制的
从库上找不到文件
在主库上产生的uuid()和从库上产生的不一样
行级复制
主库delete 删除了1W行 通过范围条件
就会在binerlog里记录1W行
delete from tb where @1=xx , @2=xxx ,,,isdel = 1;
binerlog过大 导致从库卡住了 造成延迟
打开binerlog一看就知道怎么回事了
从库上如果只有20条 发现数据少了好多 那么从库会报错
row : 1032 错误，找不到记录了
如果用statement最多智能看到 1062 错误 ，主建冲突
主库：where sed_index=xxx;
binnerlog：
update tb set
@1=xxx,
@2=xxx,
…
where
@1=xxx,
@2=xxx,
…
如何记录用户的sql
general log
set long_query_time=0; 慢日志设置时间，让说有sql都记录到慢日志里
行级别复制ddl操作是以语句进行记录的
查询binerlog
show binerlog events in 'mybinlog.00008' from 686;
【补充】ndb cluster ,gtid模型下所有的mixed格式都是转成row格式的
DDL 数据操作语言 （Data Definition Language statements.）
Some examples:数据定义语言，用于定义和管理 SQL 数据库中的所有对象的语言
1.CREATE – to create objects in the database 创建
2.ALTER – alters the structure of the database 修改
3.DROP – delete objects from the database 删除
4.TRUNCATE – remove all records from a table, including all spaces allocated for
DML 数据操作语言
1.insert into
2.update
3.delete
等等
row格式现在是主流
gtid，ndb cluster，pxc
help change master to ;
delete操作再从库上没有找到记录
全局的事务标志
crash recover还没支持的太好
master_auto_position=1;
mysql-5.6.9 以后的mysqldump
set @@GLOBAL.GTID_PUREGE
xtrabackup
set global gtid_purged需要gtid_purged是空的
如果不是空的不能执行命令 要reset master;
但这样binerlog就会都被清空
slave1 到了100 但slave2只到90
mha 补数据
用户写的操作用不用保证传到slave上？
不能保证 所以有半同步
半同步模型图：
官方的半同步：在写入Storage之后是否响应用户的写入成功，是要等待日志传到slave上
收到slave ok之后才会响应客户端,我的日志已经传输完成了。
可能客户还没有收到Commit ok 其他客户访问就已经能看到客户commit的数据了（我觉得还好吧）
5.7之前都是这样
增强版半同步：
write往slave上传输移到往storage上提交之前，只有传输到slave上之后才往storage上提交
5.7之后官方提供storage之前提交还是storage之后提交可参数配置
半同步要求日志提交之后slave必须给一个响应，
如果压力过大半同步基本上出现丢数据的问题
所以在业界使用并不是很多
性能上不去 大家没有太多使用
官方的5.7之前一个从库一个只能从一个主库同步
mariadb 10 引入了多通道复制
一个slave可以从多个主库上复制
mysql复制结构
任何节点都有一份数据造成了数据损坏切数据非常占用时间