binlog日志由一个索引文件与很多日志文件组成，每个日志文件由魔数以及事件组成，每个日志文件都会以一个rotate类型的事件结束。
对于每个事件，都可以分为事件头与事件体两部分：
事件头的结构如下所示：
事件体的结构包括固定大小与可变大小两部分。
对于binlog日志的格式，做简单的了解即可，感兴趣的同学可以深入学习。
2. 主从复制2.1 主从复制的流程
mysql主从复制的流程大致如下：
主库同步自己的binlog日志给从库
从库的io线程将binlog日志内容写入relay log
从库的sql线程取relay log并在数据库中进行回放
2.2 gtidgtid是指全局事务标志，用来标记主从同步的情况。
当主节点提交一个事务时，会生成gtid并在binlog日志中进行记录。从库的io线程在读取binlog日志时，会将其储存在自己的relaylog中，并且将这个值设置到gtid_next中，即下一个要读取的gtid，从库读取这个gtid_next时，会对比自己的binlog日志中是否有这个gtid：
如果有这个记录，说明这个gtid的事务已经执行过了，可以忽略掉（幂等）。
如果没有这个记录，slave就会执行该gtid事务，并记录到自己的binlog日志中。
2.3 复制模型异步复制：master 把binlog日志推送给slave，master不需要等到slave是否成功更新数据到relay log，主库直接提交事务即可。这种模式牺牲了数据一致性。
同步复制：每次用户操作时，必须要保证master和slave都执行成功才返回给用户。
半同步复制：不要求slave执行成功，而是成功接收master日志就可以通知master返回。
2.4 mgr模式分布式一致性算法paxos。由至少3个或更多个节点共同组成一个数据库集群，事务的提交必须经过半数以上节点同意方可提交提供，支持多写模式。
mgr 是 share-nothing 的复制方案，基于分布式paxos协议实现，每个实例都有独立的完整数据副本，集群自动检查节点信息，做数据的同步。同时提供单主模式和多主模式，单主模式在主库宕机后能够自动选主，所有写入都在主节点进行，多主模式支持多节点写入。集群提供了容错功能，只要大多数节点正常运行，集群就能正常提供服务。
2.5 并行回放事务回放是从库的sql线程执行relay log的过程，并行回放是为了提高这一过程的效率，将可以并行进行的事务同时进行。
基于逻辑时钟的并行回放
因为mysql本身事务具有acid的特点，所以从主库同步到从库的事务，只要其执行的逻辑时间上有重叠，那么这两个事务就能安全的进行并行回放。
基于writeset的并行回放
将一定时间内关于特定数据块区域的事务集合存储在一个hashmap中。在同一组内的事务或者具有重叠逻辑时钟的事务之间不会发生冲突，而其他情况则无法确定是否存在冲突。
以上就是mysql binlog日志与主从复制是什么的详细内容。