Tag Archives: InnoDB

xtrabackup_binlog_pos_innodb 和 xtrabackup_binlog_info

用过 xtrabackup 工具的 innobackupex 脚本备份数据的人可能会注意到,–apply-log 处理过的备份数据里有两个文件说明该备份数据对应的 binlog 的文件名和位置。但有时这俩文件说明的位置可能会不同。 经过实验和询问 Percona 公司,结论如下: 1 对于纯 InnoDB 操作,备份出来的数据中上述两个文件的内容是一致的 2 对于 InnoDB 和非事务存储引擎混合操作,xtrabackup_binlog_info 中所示的 position 应该会比 xtrabackup_pos_innodb 所示的数值大。此时应以 xtrabackup_binlog_info 为准;而后者和 apply-log 时 InnoDB recovery log 中显示的内容是一致的,只针对 InnoDB 这部分数据 另外,今天发现 InnoBASE/MySQL/Oracle 公司出品的 MySQL Enterprise Backup(原 … Continue reading

Posted in 默认分类 | Tagged , , , , | Leave a comment

MySQL 备份、版本兼容性二三事

最近几天在筹备多做一个 slave 数据库,所以就用 InnoDB Hot Backup 工具把原来的 slave 库备份了一份,拷贝过来,执行了一段 binlog 之后卡住了,然后发现上述工具对 ARCHIVE 存储引擎的表没有考虑,没把数据文件复制过来。于是改用 Percona 出品的 xtrabackup 工具,其 innobackupex 脚本考虑的比较周全。这样总算搞到一份相对完整的备份。 搞到备份数据之后,我又想尝鲜,于是装了 Percona Server (即 MySQL 的一个增强 fork)的 5.5 版本,结果发现无法操作上述 ARCHIVE 存储引擎的表。查了查 MySQL 5.1 的文档,说从 5.0 到 5.1 之间,ARCHIVE存储引擎变了存储格式,不可能兼容,要求 dump/restore 操作。服了…… 考虑到 … Continue reading

Posted in 默认分类 | Tagged , , , , , , | Leave a comment