MySQL数据库InnoDB引擎主从复制同步经验总结

近期将公司的mysql架构升级了，由原先的一主多从换成了drbd+heartbeat双主多从，正好手上有一个电子商务网站新项目也要上线了，用的是drbd+heartbeat双主一从，由于此过程还是有别于以前的myisam引擎的，所以这里也将其心得归纳总结了一下：

1）mysql的replication过程是一个异步同步的过程，并非完全的主从同步，所以同步的过程中是有延迟的，如果做了读写分离的业务的话，建议也要监控此延迟时间；

2）mysql的master与slave机器记得server-id要保持不一致，如果一样的话，replication过程中会出现如下报错:

fatal error: the slave i/o threadstopsbecause master and slavehave equal mysql server ids; these ids mustbedifferent for replication to work(or the --replicate-same-server-id optionmustbe used on slave but this doesnot always make sense; please check themanualbefore using it).

这个问题很好处理，即将slave机的server-id修改成跟master机器不一致即可。

3）我以前的一个误区就是，slave机器是用自己的二进制日志来完成replication过程的，其实不是这样的，根据复制的工作原理：slave服务器是copy主服务器的二进制日志到自己的中继日志，即relay-log日志（即centos3-relay-bin.000002这种名字的）中，然后再把更新应用用到自己的数据库上，所以slave机器是不需要开启二进制日志的，这样过程一样会成功的；除非是准备做主主架构，这才需要slave机器开启二进制日志，这个问题一直在导着我，我以一直以为slave机器搭建replication环境时是一定要开启二进制的

4）在master机器上授权时，尽量只给某一个或某几个固定机器权限，让它们只有replication slav，replication client权限，尽量不要给grant权限；另外，虽然数据库我们一般是通过内网操作，但越是在在内网对mysql数据库进行授权操作，越是要注意安全；

5）replication搭建过程按照正常流程走的话，一般很容易实施成功，如果出错的话，多检查下网络环境、权限问题，一般来说整个搭建过程应该还是会比较顺利的。

在数据库设计初期，我已经将此电子商务的数据库引擎定义为innodb，除了数据库中原有的系统表之外，其它表全部由myisam转成了innodb，原因有二：

1）电子商务业务会涉及到交易付款，在这种基本oltp的应用中，innodb应该作为核心应用表的首选存储引擎；
2）drbd系统重启时的过程会比较缓慢，会频繁的读表，如果表引擎为myisam的话极有可能出现损坏情况，为了造成不必要的问题，我将数据库的表引擎由myisam均转成了innodb引擎的表。

drbd+heartbeat+mysql参考以前的工作文档，搭建的比较顺利，就是在搭建replication环境时遇到了1062报错，详细过程如下：
初期参考mysql手册操作，取master机器的快照备份，用的是--single-transaction选项，然后同步过程频繁1062报错，报错日志如下：

last_sql_error: error 'duplicate entry'd36ad91bff36308de540bbd9ae6f4279' for key 'primary'' on query. defaultdatabase: 'myproject'. query: 'insert into `lee_sessions` (`session_id`,`ip_address`, `user_agent`, `last_activity`, `user_data`) values('d36ad91bff36308de540bbd9ae6f4279', '180.153.201.218', 'mozilla/4.0',1353394206, '')'

后来改变思路，用--master-data选项来取主master快照备份，命令如下所示：

mysqldump -uroot --quick--flush-logs--master-data=1 -p myproject > myproject.sql

附注：--master-data的用法为：通过此参数来备份sql文件时会建议一个slavereplication，当其值为1时，sql文件中会记录change master语句；当其值为2时，change master会被写成sql注释，--master-data在没有使用--single-transaction选项的情况下会自动使用lock-all-tables选项（即这二代选项不要搭配使用）。如何查找sql中的的log_file及log_pos呢？我们可以用如下命令(请注意change单词要写成大写的)，如下所示：

grep "change"myproject.sql

命令显示结果如下：

change master tomaster_log_file='mysql-bin.000008',master_log_pos=106;

接下来的replication过程就不详细说明了，同步完成后我们经过相当长时间的观察，再也没1062报错了，如下所示：

mysql> show slave status \g;
*************************** 1.row***************************
               slave_io_state: waitingformaster to send event
                  master_host: 192.168.11.174
                  master_user: rep1
                  master_port: 3306
                connect_retry: 60
              master_log_file: mysql-bin.000008
        read_master_log_pos: 27880
               relay_log_file:centos3-relay-bin.000002
                relay_log_pos: 28025
      relay_master_log_file: mysql-bin.000008
           slave_io_running: yes
          slave_sql_running: yes
              replicate_do_db:
        replicate_ignore_db:
         replicate_do_table:
     replicate_ignore_table:
    replicate_wild_do_table:
 replicate_wild_ignore_table:
                   last_errno: 0
                   last_error:
                 skip_counter: 0
        exec_master_log_pos: 27880
              relay_log_space: 28182
              until_condition: none
               until_log_file:
                until_log_pos: 0
         master_ssl_allowed: no
         master_ssl_ca_file:
         master_ssl_ca_path:
              master_ssl_cert:
          master_ssl_cipher:
               master_ssl_key:
      seconds_behind_master: 0
master_ssl_verify_server_cert: no
                last_io_errno: 0
                last_io_error:
               last_sql_errno: 0
               last_sql_error:
1 row in set (0.00 sec)

工作中innodb引擎数据库主从复制同步心得以前的项目也比较多的牵涉到innodb数据库的备份及replication，较多的一个做法是停库进行replication，虽然也是解决问题的一种思路，但毕竟属于停机维护，在一些特殊应用场景中是不允许的，我们应该多尝试采用mysqldump这种逻辑备份方式来取master主机快照。