MySQL复制的概述、安装、故障、技巧、工具

标签: Technical MySQL Replication | 发表时间:2011-04-05 10:26 | 作者:老王 jinbiaozhao
出处:http://huoding.com

MongoDBRedis这样的NoSQL数据库的复制相比,MySQL复制显得相当复杂!

概述

首先主服务器把数据变化记录到主日志,然后从服务器通过I/O线程读取主服务器上的主日志,并且把它写入到从服务器的中继日志中,接着SQL线程读取中继日志,并且在从服务器上重放,从而实现MySQL复制。具体如下图所示:

MySQL复制

MySQL复制

整个过程反映到从服务器上,对应三套日志信息,可在从服务器上用如下命令查看:

mysql> SHOW SLAVE STATUS;

 

  • Master_Log_File & Read_Master_Log_Pos:下一个传输的主日志信息。
  • Relay_Master_Log_File & Exec_Master_Log_Pos:下一个执行的主日志信息。
  • Relay_Log_File & Relay_Log_Pos:下一个执行的中继日志信息。

理解这些日志信息的含义对于解决故障至关重要,后文会详细阐述。

安装

先在主服务器上创建复制账号:

mysql> GRANT REPLICATION SLAVE ON *.*
       TO '<SLAVE_USER>'@'<SLAVE_HOST>'
       IDENTIFIED BY '<SLAVE_PASSWORD>';

注:出于安全性和灵活性的考虑,不要把root等具有SUPER权限用户作为复制账号。

然后设置主服务器配置文件(缺省:/etc/my.cnf):

[mysqld]

server_id = 100
log_bin = mysql-bin
log_bin_index = mysql-bin.index
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
innodb_support_xa = 1

注:一定要保证主从服务器各自的server_id唯一,避免冲突。

注:如果没有指定log_bin的话,缺省会使用主机名作为名字,如此一来一旦主机名发生改变,就会出问题,所以推荐指定log_bin(从服务器的relay_log存在一样的问题)。

注:sync_binloginnodb_flush_log_at_trx_commitinnodb_support_xa三个选项都是出于安全目的设置的,不是复制的必须选项,但如果没设置的话,一旦主服务器宕机,数据可能来不及写入磁盘,从而导致从服务器在复制过程中出现类似下面的错误:

  • Client requested master to start replication from impossible position

因为日志数据已经丢失了,所以此类问题基本上不能处理,只能重新安装同步从服务器。

接下来设置从服务器配置文件(缺省:/etc/my.cnf):

[mysqld]

server_id = 200
log_bin = mysql-bin
log_bin_index = mysql-bin.index
relay_log = mysql-relay-bin
relay_log_index = mysql-relay-bin.index
read_only = 1
skip_slave_start = 1
log_slave_updates = 1

注:如果用户有SUPER权限,则read_only无效。

注:有了skip_slave_start,除非使用START SLAVE命令,否则从服务器不会开始复制。

注:设置log_slave_updates,让从服务器记录日志,有助于在必要时把从切换成主。

下面最重要的步骤是如何克隆一份主服务器的数据:

如果数据库使用的是MyISAM表类型的话,可按如下方式操作:

shell> mysqldump --all-databases --master-data=1 > data.sql

注:master-data选项缺省会打开lock-all-tables,并写入CHANGE MASTER TO语句。

如果数据库使用的是InnoDB表类型的话,则应该使用single-transcation

shell> mysqldump --all-databases --single-transaction --master-data=1 > data.sql

有了数据文件,传输到从服务器上并导入:

shell> mysql < data.sql

当然,整个过程也可以利用管道符一次性操作:

shell> mysqldump --host=<MASTER_HOST> ... | mysql --host=<SLAVE_HOST> ...

因为我们开始设置了master-data=1,所以系统会自动设置参数:MASTER_LOG_FILE和MASTER_LOG_POS,我们还需要设置剩下的参数:

mysql> CHANGE MASTER TO
       MASTER_HOST='<MASTER_HOST>',
       MASTER_USER='<SLAVE_USER>',
       MASTER_PASSWORD='<SLAVE_PASSWORD>';

如果数据量很大的话,mysqldump会非常慢,此时直接拷贝数据文件能节省不少时间:

在拷贝之前要先锁定数据,然后再获得相关的日志信息(File & Position):

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

接下来拷贝数据文件时,如果是MyISAM表类型的话,直接拷贝即可;如果是InnoDB表类型的话,一定要先停止MySQL服务再拷贝,否则拷贝文件可能无法使用。把拷贝的数据文件直接复制到从服务器的数据目录。

最后还需要再指定一下日志信息:

mysql> CHANGE MASTER TO
       MASTER_HOST='<MASTER_HOST>',
       MASTER_USER='<SLAVE_USER>',
       MASTER_PASSWORD='<SLAVE_PASSWORD>',
       MASTER_LOG_FILE='<File>',
       MASTER_LOG_POS=<Position>;

注:不要在my.cnf配置文件里设置MASTER_USER和MASTER_PASSWORD,因为最终生效的是CHANGE MASTER TO生成的master.info文件里的信息。

在主服务器上直接拷贝数据文件虽然很快,但需要锁表或者停止服务,这会影响线上服务。如果先前已经有了从服务器,那么可以用旧的从服务器做母本来克隆新的从服务器:

先在旧的从服务器上查询日志信息:

mysql> SHOW SLAVE STATUS;

我们需要的是其中的Relay_Master_Log_File & Exec_Master_Log_Pos。

然后在旧的从服务器上按照前面的方法得到数据,并在新的从服务器上还原。

接着在新的从服务器上设置日志信息:

mysql> CHANGE MASTER TO
       MASTER_HOST='<MASTER_HOST>',
       MASTER_USER='<SLAVE_USER>',
       MASTER_PASSWORD='<SLAVE_PASSWORD>',
       MASTER_LOG_FILE='<Relay_Master_Log_File>',
       MASTER_LOG_POS=<Exec_Master_Log_Pos>;

不管用那个方法,最后记得在从服务器上启动复制,并检查工作是否正常:

mysql> START SLAVE;
mysql> SHOW SLAVE STATUS;

如果IO线程和SQL线程都显示Yes,就可以感谢上帝了:

  • Slave_IO_Running: Yes
  • Slave_SQL_Running: Yes

如果显示No,则说明某些配置步骤有问题,请重新对照一遍前面所说的步骤。

故障

问题:主从复制不止何故停止了,我该怎么办?

答案:复制错误多半是因为日志错误引起的,所以首先要搞清楚是主日志错误还是中继日志错误,从错误信息里一般就能判断,如果不能可以使用类似下面的mysqlbinlog命令:

shell> mysqlbinlog <MASTER_BINLOG_FILE> > /dev/null
shell> mysqlbinlog <RELAY_BINLOG_FILE> > /dev/null

如果没有错误,则不会有任何输出,反之如果有错误,则会显示出来。

如果是主日志错误,需要手动找到正确的日志信息,重新CHANGE MASTER TO即可:

mysql> CHANGE MASTER TO
       MASTER_LOG_FILE='<GOOD_LOG_FILE>',
       MASTER_LOG_POS=<GOOD_LOG_POS>;
mysql> START SLAVE;

如果是中继日志错误,只要在从服务器使用SHOW SLAVE STATUS结果中的日志信息重新CHANGE MASTER TO即可,系统会抛弃当前的中继日志,重新下载:

mysql> CHANGE MASTER TO
       MASTER_LOG_FILE='<Relay_Master_Log_File>',
       MASTER_LOG_POS=<Exec_Master_Log_Pos>;
mysql> START SLAVE;

至于为什么使用的是Relay_Master_Log_File & Exec_Master_Log_Pos,参见概述。

有时候由于BUG或者在从服务器执行了写操作可能会造成键重复错误,错误信息如下:

  • Error ‘Duplicate entry …’ for key … on query

此时最好手动确认并删除从服务器上的无效数据,然后从主服务器复制正确数据,如果错误仍然不能解决,可以在从服务器使用SET GLOBAL sql_slave_skip_counter,如下:

mysql> SET GLOBAL sql_slave_skip_counter = 1;
mysql> START SLAVE;

注:如果有多个错误,可能需要执行多次(提醒:主从服务器数据可能因此不一致,遇到这样的情况可以使用mk-table-checksummk-table-sync检查并修复从服务器数据)。

问题:主服务器宕机了,如何把从服务器提升会主服务器?

答案:在一主多从的环境总,需选择数据最新的从服务器做新的主服务器。如下图所示:

提升从服务器为主服务器

提升从服务器为主服务器

在一主(Server1)两从(Server2,、Server3)环境中,Server1宕机后,等到Server2和Server3把宕机前同步到的日志都执行完,比较Master_Log_File和Read_Master_Log_Pos就可以判断出谁快谁慢,因为Server2从Server1同步的数据(1582)比Server3从Server1同步的数据(1493)新,所以应该提升Server2为新的主服务器,那么Server3在CHANGE MASTER TO到Server2的时候应该使用什么样的参数呢?1582-1493=89,而Server2的最后的二进制日志位置是8167,所以答案是8167-89=8078。

技巧

主从服务器中的表可以使用不同的表类型。比如主服务器可以使用InnoDB表类型,提供事务,行锁等高级特性,从服务器可以使用MyISAM表类型,内存消耗少,易备份等优点。还有一个例子,一台主服务器如果同时带很多个从服务器的话,势必会影响其性能,此时可以拿出一台服务器作为从服务器代理,使用BLACKHOLE表类型,只记录日志,不写数据,由它带多台从服务器,从而提升性能。

主从服务器中的表可以使用不同的键类型。比如主服务器用InnoDB,键用VARCHAR的话节省空间,从服务器使用MyISAM,键用CHAR提高速度,因为MyISAM有静态表一说。

主从服务器中的表可以使用不同的索引。主服务器主要用来应付写操作,所以除了主键和唯一索引等保证数据关系的索引一般都可以不加,从服务器用来应付读操作,所以可以针对查询特征设置索引,甚至不同的从服务器可以针对不同的查询设置不同的索引。

工具

有一些优秀的工具可以让你的得到事半功倍的效果,详细内容请参考各自文档:

此外,Google Project Hosting里还有很多有趣的项目,可用mysql+replication搜索。

补充:Automated, Non-Stop MySQL Operations and Failover

补充:Yoshinori释出了MySQL-MHA项目,有助于提高MySQL主从复制的可靠性。

说明:本文参考了下面列出的书籍中相关的内容:

相关 [mysql 复制 技巧] 推荐:

MySQL复制的概述、安装、故障、技巧、工具

- jinbiaozhao - 火丁笔记
同MongoDB,Redis这样的NoSQL数据库的复制相比,MySQL复制显得相当复杂. 首先主服务器把数据变化记录到主日志,然后从服务器通过I/O线程读取主服务器上的主日志,并且把它写入到从服务器的中继日志中,接着SQL线程读取中继日志,并且在从服务器上重放,从而实现MySQL复制. 整个过程反映到从服务器上,对应三套日志信息,可在从服务器上用如下命令查看:.

mysql主从复制

- - SQL - 编程语言 - ITeye博客
从库的配置,mysql5.5不支持配置文件的配置了,问了数据库的人,用命令行指定. 修改从库的配置 #default-storage-engine = InnoDB #修改 default-storage-engine = blackhole server-id = 11215004 #新增 replicate-do-db = test log-bin = mysql-bin #新增 binlog_format = row.

mysql 索引技巧

- - 小彰
MySQL索引的建立对于MySQL的高效运行是很重要的. 下面介绍几种常见的MySQL索引类型. 在数据库表中,对字段建立索引可以大大提高查询速度. 假如我们创建了一个 mytable表:. CREATE TABLE mytable(   ID INT NOT NULL,    username VARCHAR(16) NOT NULL  );   我们随机向里面插入了10000条记录,其中有一条:5555, admin.

MySQL主从复制配置

- - 天空极速
在实际企业应用环境当中,单台MySQL数据库是不足以满足日后业务需求的. 譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止. 使用MySQL主从复制的好处有:. 1、采用主从服务器这种架构,稳定性得以提升. 如果主服务器发生故障,我们可以使用从服务器来提供服务;. 2、在主从服务器上分开处理用户的请求,可以提升数据处理效率;.

mysql优化小技巧

- - 互联网 - ITeye博客
对mysql优化时一个综合性的技术,主要包括. a: 表的设计合理化(符合3NF). b: 添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引]. c: 分表技术(水平分割、垂直分割). d: 读写[写: update/delete/add]分离. e: 存储过程 [模块化编程,可以提高速度].

MySQL 5.6 测试之 Replication(主从复制)

- - MySQL 中文网 -
MySQL 5.6测试之Replication. MySQL 5.6版本相比以前新增了很多令人激动的特性,简要介绍见: 转:MySQL 5.6新特性. 性能方面已经做过测试了,详细请见: MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试.

MySQL半同步复制(Semisynchronous Replication)

- - IT技术博客大学习
MySQL5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:. 半同步启动需要主从两端都需要加载安装各自对应的semi模块,从库端支持半同步功能的数量至少一台;主库端当一个事务成功提交后,并不及时反馈给前端用户,该线程会被临时block,等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认),这时主库线程才返回给当前session告知操作完成,半同步复制并不关心在从库一端该事务是否都被执行并被提交完成.

[玩转MySQL Replication] 复制拓扑

- - CSDN博客数据库推荐文章
     朴实简单的才是真、那些高端洋气的复制拓扑纯属自虐.      实施复制大概会有 4 个原则:.      ① 一个主库可以有多个备库.      ② 一个备库只能有一个主库.      ③ 每个备库 Server ID全局唯一.      ④ log_slave_updates 有薪火相传之效用.

MySQL主从复制与读写分离

- - 数据库 - ITeye博客
MySQL主从复制与读写分离. MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践. Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过. 但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面.