背景
6.5号,小编在 Aliyun 的论坛中发现一位开发者提的一个问题,说 RDS 发现了一个超级大BUG,吓的小编一身冷汗 = =!! 赶紧来看看,背景是一个RDS用户创建了一张表,在一个都是NULL值的非索引字段上进行了排序并分页,用户发现第二页和第一页的数据有重复,然后以为是NULL值的问题,把这个字段都更新成相同的值,发现问题照旧。详细的信息可以登录阿里云的官方论坛查看。
小编进行了尝试,确实如此,并且5.5的版本和5.6的版本行为不一致,所以,必须要查明原因。
keep running, just do it!
在RDS生产环境中,一个MySQL实例莫名地被shutdown了, 日志中有如下信息:
1 | 150525 15:30:52 [Note] User 'userxx' issued shutdown command |
虽然PG 9.4发布不过半年时间,下一个大版本9.5却已经进入人们的视野。按目前的情况,2015年上半年可能发布beta版本,下半年正式发布PG 9.5。9.5里面最令人瞩目的一个新功能恐怕是BRIN索引了。下面这个commit加入了对BRIN索引的支持:
RDS的备份工具用的是 Percona-XtraBackup(后面简称PXB),这个工具包里有2个重要的工具,innobackupex和xtrabackup,后者是C编译出的二进制文件,负责备份 InnoDB 数据,前者是一个Perl 脚本,对后者进行封装,同时负责备份非 InnoDB 数据。xtrabackup 二进制里内嵌了InnoDB引擎,所以能很好的处理InnoDB数据。
在2.2版本之前,PXB 分别针对不同版本的 MySQL 源码(5.1/5.5/5.6)编译了不同版本的xtrabackup,以便备份不同版本的MySQL数据,然而在2.2之后,PXB官方觉得5.6已经可以很好的兼容5.1和5.5,所以就只针对 5.6.22 版本的代码编译了一个 xtrabackup 二进制文件,关于这个改动可以看官方的BP #single binary。故事就由此发生。。。
MySQL 非 GTID 协议主备同步原理: 主库在执行 SQL 语句时产生binlog,在事务 commit 时将产生的binlog event写入binlog文件,备库IO线程通过 com_binlog_dump
用文件位置协议从主库拉取 binlog,将拉取的binlog存储到relaylog, SQL线程读取 relaylog 然后进行 apply,实现主备同步,在这个过程中有以下几个问题: