MySQL系统表故障探究
一次偶尔的巡检,竟然发现错误日志中有大量的重复错误,而且竟然延续了几个月,导致错误日志相当庞大,竟然不影响业务,不报警.........
应用端连接MySQL数据库报Communications link failure
Long long ago,there was a story about the Arguments between DBAs and the Developers...这个故事,并没有童话故事里王子和公主幸福的各种浪。那么就随我,揭示故事发生的原因。 事情的起因:某项目的开发同学突然Q我们组的...
MySQL数据库丢失数据场景分析(II)
原创:Perry.Zhang 发表:Jane.Hoo MySQL主从复制原理:MySQL主库在事务提交时写binlog,并通过sync_binlog参数来控制binlog刷新到磁盘“落地”。从库中有两个线程: IO线程负责从主库读取binlog,并记录到本地的relay log中;SQL线程再将relay log中的记录应用到从库。如下图所示:
MySQL数据库丢失数据场景分析(I)
原创:Perry.Zhang 发表:Jane.HooInnoDB作为MySQL支持事务的存储引擎,同Oracle类似,事务提交时需要写redo、undo log。 InnoDB采用预写日志(Write Ahead Log)策略,数据页的变更会首先在内存中完成,同时将事务操作顺序记录到redo log中。完成上述的操作后表示该事务已经完成,可以返回给应用已提交的信息。 但此时实际被更改的数据页还保存在内存中(称为脏页),并没有flush到磁盘上即没有落地。刷盘操作一般会在达到一定条件后,触发checkpoint机制,此时会将内存中的脏页合并写入到磁盘里,完成数据同步。刷盘策略由innodb_flush_log_at_trx_commit参数控制的策略。