Category Archives: Database

MySQL两种备份模式:Logical Backup 和 Raw Backup

Logical Backup 就是用诸如mysqldump这样的工具把数据导出为可视的sql文件或csv文件

Raw Backup 则是指直接备份数据库的数据文件

Raw Backup执行起来比Logical Backup快的多,因为它不需要消耗CPU/内存把数据变成sql或csv(顺便说一下,变csv比变sql要快很多)。

但Raw Backup有一个缺点:Raw File的跨平台能力比较弱。 一个windows下的文件在linux下可能就用不了,一个从mysql 5.1导出的文件可能无法被mysql 5.5识别。

Raw Backup还有一个严重的缺点: 如果Raw File是一个Corrupted File, 复制后产生的备份仍是一个Corrupted File; 这个备份就没有作用,因为你没法利用它来恢复数据。

对InnoDb执行mysqldump时应该加上 –single-transaction参数

mysqldump默认情况下并不保证数据一致性。 在innodb中,可以这样:

mysqldump  --single-transaction mydb > mydb-backup.sql

如果有 –single-transaction参数,mysqldump会将整个数据的读取过程置于一个满足repeatable read的事务中,最后导出的数据也是相互一致的。

由于innodb的mvcc特性,使用 –single-transaction执行mysqldump, 不会阻塞其他进程的读写。

innodb: 两个事务在binlog文件中不会交叉

在innodb的binlog文件中,如果一个事务从第m行开始,在第n行结束;那么从m到n之间只会记录本事务的操作,不会记录其他事务的行为。

这是因为innodb中binary log entries总是以事务为单位整体写入文件的。

引用

Within an uncommitted transaction, all updates (UPDATE, DELETE, or INSERT) that change transactional tables such as BDB or InnoDB tables are cached until a COMMIT statement is received by the server. At that point, mysqld writes the entire transaction to the binary log before the COMMIT is executed.

推论:

1. 只有事务完成了,相关记录才会进入binlog文件

2. 一个写事务不应该太长,否则当它被整体写入binlog文件时,会长时间占用binlog,导致其他事务在这段时间内无法写入binlog,因而无法提交,最终影响并发性能。

innodb中应该尽量把多条语句放在单个事务中执行

默认情况下,一个写操作就是一次事务

如果一次业务操作包含三次DB写操作,三个写操作就是三个事务,三个事务导致三次log flush(磁盘读写,代价较高):

引用
InnoDB must flush the log to disk at each transaction commit if that transaction made modifications to the database.

所以应该把这三次DB写操作合在一个事务里,这样只需要做一次flush disk。

innodb的binlog跟redo/undo log无关

mysql, 不管用的是不是innodb, 都有binlog. 这个binary log跟transaction没关系,它主要用于replication和backup. log文件会一直递增,不会循环使用(后面的记录不会覆盖前面的)

同时,innodb还有redo log/undo log. 它们用于transaction, 且会循环使用。