Mysql主从复制的配置,双机互为主从的优缺点

我们的配置目的: 两台mysql服务器可以相互为主从提供同步服务.

 双机互为主从的优缺点:

Mysql主从优点:

1. mysql的主从复制的主要优点是同步"备份", 在从机上的数据库就相当于一个(基本实时)备份库.

2. 在主从复制基础上, 通过mysqlproxy可以做到读写分离, 由从机分担一些查询压力.

3. 做一个双向的主从复制, 两台机器互相为主机从机, 这样, 在任何一个机器的库中写入, 都会"实时"同步到另一台机器, 双向的优点在于当一台主机发生故障时, 另一台主机可以快速的切换过来继续服务.

 

步骤:

1. 在两台机器上添加一个用于从机访问的帐号, 赋予REPLICATION SLAVE权限.

GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slave';

为slave用户赋予任何数据库中任何表上的REPLICATION SLAVE权限, 此用户可以在网络任意位置访问, 访问时以密码slave标记.

 

当使用的是ubuntu的时候, 需要注意一点, /etc/mysql/my.cnf配置文件下的bind-address = 127.0.0.1这一行需要注释, 不然从机在请求时是连接不到的.(我的是ubuntu, 其他版linux不知道会不会一样)

 

为了保证工作的步骤明细, 可以采用在配置完用户相关信息之后, 在另一台机器上以分配的用户密码连接一次, 能成功则能保证当前步骤是正确的.

 

2. 配置服务器编号, 开启bin-log

编辑mysql配置文件, linux: /etc/mysql/my.cnf,    windows: c:/program files/mysql/mysql 5.0/my.ini

找到[mysqld]这个标签,

在它的下面有两行

#server-id               = 1
#log_bin                 = /var/log/mysql/mysql-bin.log

打开这两行的注释, 注意这里的server-id是服务器编号, 所以, 两台服务器上的值要设置的不一样. 比如1和2

 

3. 使server-id和log-bin的配置修改生效:

sudo /etc/init.d/mysql restart

或者windows下在服务里重启mysql服务

 

4. 将两台数据库服务器的mysql都锁定

在mysql命令模式下:

FLUSH TABLES WITH READ LOCK;

SHOW MASTER STATUS;

 

此时请保证执行这两条命令的mysql控制台不要退出.

 

5. 分别重新打开一个mysql控台台, 配置主机

CHANGE MASTER TO

MASTER_HOST = 'host', #另一台机器的地址

MASTER_PORT = 3306, #另一台机器的端口

MASTER_USER = 'slave',#另一台机器上第一步分配的用户名

MASTER_PASSWORD = 'slave', #另一台机器上第一步分配的密码

MASTER_LOG_FILE = 'mysql-bin.000001',#另一台机器上执行SHOW MASTER STATUS得到的文件名

MASTER_LOG_POS = 192; #另一台机器上执行SHOW MASTER STATUS得到的偏移量

 

6. 开启同步

START SLAVE;

 

7. 验证正确性

SHOW SLAVE STATUS;

如果返回的结果第一列是Waiting for master to send event或者Queueing就说明配置是正确的, 当然, 还可能会有其他的信息也是正确的, 只不过我这里没有收集到...呵呵

Mysql主从缺点:
但主从机制是一样的:
mysql主从的实现是,mysql master被使用后,其中master后台IO线程会写Binlog;slave有一个Relay Log线程同步binlog日志,同时有另一个Extractor线程会读取相应的Binlog,在Slave进行相应的同样的操作。
对于主从正常执行,相应的延迟几乎是不存在的。但是在高QPS下,主从同步却出现了比较明显的延迟情况。在PPT介绍中,当master QPS达到1万左右时,Slave重做的QPS却只有2000左右,因此所谓的瓶颈其实是在Binlog日志在slave重做这块。而此处实现是单线程的,因此改进的方法此处用多线程实现。

PPT中介绍淘宝实现,修改了源码,对应的机制是Transfer机制:此处通过对Binlog日志重做采用多线程实现,从而提高slave的QPPS,PPT给出的实验数据按此机制实现后,QPS能达到1万多。从而解决mysql主从之间高QPS下的数据同步问题。
当然使用此机制对应的mysql相关配制也有一定的要求:
1.Binlog日志格式必须是基于ROW级别的,
2.对应的SQL语句必须对应PK或者uni key。

对于以上两点,作者解析是基于多线程必须是知道PK或者uni key才能完成相应的多线程重做slave,这样才能保证SQL语句的执行顺序。相对来说,对于第二点很多应用需求还是能满足。但是对ROW日志格式,对于一些批量修改等应用,采用此日志格式所带来的DB的IO压力等应该也是需要考虑的。

毕竟一种新的方案的提出有它的优点也有它的缺点,合适才是最合理的。总的来说此PPT是围绕此方案的实现在讲解,很易懂。