我们的配置目的: 两台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是围绕此方案的实现在讲解，很易懂。