MySQL丢数据及主从数据不一致的场景-lunique.docxVIP

— PAGE \* Arabic 1 — MySQL丢数据及主从数据不一致的场景-lunique MySQL丢数据及主从数据不一致的场景  1.相关知识点：  innodb_flush_log_at_trx_commit  innodb_flush_log_at_timeout  sync_binlog  relay log、relay log info、master info：  master-info-repository  relay-log-info-repository  sync_relay_log  sync_master_info  sync_relay_log_info  原文地址：http://./doc/cb4fb5f21b37f111f18583d049649b6648d7093e.html viewspace-1318714/  随着对MySQL的学习，发现了MySQL的很多问题，最重要的就是丢数据的问题。对于丢数据问题，我们应该了解丢数据的场景，这样在以后的学习中多考虑如何去避免及解决这些问题。  2.MySQL数据库层丢数据场景  本节我们主要介绍一下在存储引擎层上是如何会丢数据的。  2.1.InnoDB丢数据  InnoDB支持事务，同Oracle类似，事务提交需要写redo、undo。采用日志先行的策略，将数据的变更在内存中完成，并且将事务记录成redo，顺序的写入redo日志中，即表示该事务已经完成，就可以返回给客户已提交的信息。但是实际上被更改的数据还在内存中，并没有刷新到磁盘，即还没有落地，当达到一定的条件，会触发checkpoint，将内存中的数据（page）合并写入到磁盘，这样就减少了离散写、IOPS，提高性能。  在这个过程中，如果服务器宕机了，内存中的数据丢失，当重启后，会通过redo日志进行recovery重做。确保不会丢失数据。因此只要redo能够实时的写入到磁盘，InnoDB 就不会丢数据。  先来看一下innodb_flush_log_at_trx_commit这个参数：  = 0 ：每秒 write cache flush disk  = 1 ：每次commit都 write cache flush disk  = 2 ：每次commit都 write cache，然后根据innodb_flush_log_at_timeout（默认为1s）时间 flush disk  从这三个配置来看，显然innodb_flush_log_at_trx_commit=1最为安全，因为每次commit都保证redo写入了disk。但是这种方式性能对DML性能来说比较低，在我们的测试中发现，如果设置为2，DML性能要比设置为1高10倍左右。  为什么oracle的实时写要比innodb的实时写性能更好？线程与进程？后面还需要研究  大家可以考虑一下0与2的区别？  在某些DML操作频繁的场景下，库的innodb_flush_log_at_trx_commit需要设置为2，这样就存在丢数据的风险：当服务器出现宕机，重启后进行crash recovery则会丢失innodb_flush_log_at_timeout秒内的数据。  PS:当开启了内部XA事务（默认开启），且开启binlog，情况稍有不一样，后面会进行介绍。  2.2.MyISAM丢数据  MyISAM存储引擎在我们的生产中用的并不多，但是系统的数据字典表元数据等都是存储在MyISAM引擎下。  MyISAM不支持事务，且没有data cache，所有DML操作只写到OS cache中，flush disk 操作均由OS来完成，因此如果服务器宕机，则这部分数据肯定会丢失。  2.3.主从复制不一致  主从复制原理：MySQL主库在事务提交时写binlog，并通过sync_binlog参数来控制binlog刷新到磁盘“落地”，而备库通过IO线程从主库读取binlog，并记录到本地的relay log中，由本地的SQL线程再将relay log的数据应用到本地数据库，如下图所示：   从上图我们可以看到，在主从环境中，增加了binlog，这就增加了环境的复杂性，因此也增加了丢数据以及数据不一致可能。  在分析这些丢数据的可能性之前，我们先了解一下binlog的刷新机制以及MySQL的内部XA 事务是如何保证binlog与red