redo_binlog-xa_35

 

 

 

select @@binlog_format;

set binlog_format='statement';

show master status;

oracle中不管事务有多个，提交的时间都是平均的。

redo与binlog的区别

innodb vs mysql

物理逻辑日志vs 逻辑日志

写入时间点

binlog是在事务提交的时候才写的

mysql commit的时候时间是不同的 因为要写binlog日志

binlog_cache_size默认值是32768 32k 代表日志写入到这样一个内存里

二进制日志缓冲区吗，默认是32k。该参数是基于会话的，不要设置过大。

当事务的记录大于设定的binlog_cache_size时，mysql会把缓冲区中的日志信息写入一个临时文件中，所以该值也不能设置过小。

show status like '%binlog%';

stmt就是statement的意思

Binlog_cache_disk_use　　（事务类）二进志日志缓存的已经存在硬盘的条数 

Binlog_cache_use　　　　（事务类）二进制日志已缓存的条数（内存中）    注意，这个不是容量，而是事务个数。每次有一条事务提交，都会有一次增加

Binlog_stmt_cache_disk_use  （非事务类）二进志日志缓存的已经存在硬盘的条数  

Binlog_stmt_cache_use  （非事务类）二进制日志已缓存的条数（内存中） 非事务型的语句，都存在这儿，比如MYISAM引擎的表，插入记录就存在这儿

 

binlog_cache_use和binlog_cache_disk_use两者结合可以用来调整binlog_cache_size的大小
binglog_stmt_cache_use和binlog_stmt_cache_disk_use两者结合可以有来调整 binlog_stmt_cache_size的大小

这两个值是单独设置的。

将一个大事务拆成多个小事务

1 提交快

2 复制延迟

 怎么保证redo 与 binlog的一致性

内部分布式事务

commit   1 innodb prepare log

                2 write binary log file（写入到文件）

                3 innodb commit log

如果没有1  2执行 3没执行  这个事务会被rollback（回滚之后 binlog也回滚吗？？？？？？）

如果1 2 成功 3 没成功  这个事务不管有没有commit log  这个事务会被提交

prepare写入事务的id号  xid

 都是写入到磁盘

commit /* xid  prepare 和binlog 里都写xid

没开binlog 只写3

5.6 时候 2 3 是组提交

5.7 prepare log也是组提交了

从5.6开始 第3步不一定落盘

5.7 prepare 之后不fsync  在写binlog之前一次性fsync

写数据文件是用o-direct

写日志文件缓存写 先写缓存 再写磁盘

https://www.cnblogs.com/zhoujinyi/p/3179279.html

innodb_flush_method指的是刷新数据文件

所有的日志文件都是缓存写

https://blog.csdn.net/zbszhangbosen/article/details/9132833

分布式事务 XA

XA{start|begin} xid 【join|resume】

xa end xid【suspend【for migrate】】

xa prepare

两阶段提交 一旦prepare都成功了，这个分布式事务一定要提交 

事务重启之后还在 悬挂事务