InnoDB引擎数据库主从复制同步心得

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

创新互联公司公司2013年成立，先为赣榆等服务建站，赣榆等地企业，进行企业商务咨询服务。为赣榆企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

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

Fatal error: The slave I/O thread stops because master and slavehave equal MySQL server ids; these ids must be different for replication to work(or the --replicate-same-server-id option must be used on slave but this doesnot always make sense; please check the manual before 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. Default database: 'mypharma'. 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快照备份，命令如下所示：

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

--master-data的用法为：通过此参数来备份SQL文件时会建议一个slave replication，当其值为1时，SQL文件中会记录change master语句；当其值为2时，change master会被写成SQL注释，--master-data在没有使用--single-transaction选项的情况下会自动使用lock-all-tables选项（即这二代选项不要搭配使用）。

如何查找SQL中的的LOG_FILE及LOG_POS呢？我们可以用如下命令(请注意change单词要写成大写的)，如下所示：

 
 
 
      
  
  
  1. [root@centos1 ~]# grep "CHANGE " myproject.sql 
    2.   
  
  
  2.  
    3.   
  
  
  3. CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000008', MASTER_LOG_POS=106; 
    4.

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

 
 
 
      
  
  
  1. mysql> show slave status \G; 
    2.   
  
  
  2. *************************** 1. row *************************** 
    3.   
  
  
  3.                Slave_IO_State: Waiting for master to send event 
    4.   
  
  
  4.                   Master_Host: 192.168.11.174 
    5.   
  
  
  5.                   Master_User: rep1 
    6.   
  
  
  6.                   Master_Port: 3306 
    7.   
  
  
  7.                 Connect_Retry: 60 
    8.   
  
  
  8.               Master_Log_File: mysql-bin.000008 
    9.   
  
  
  9.           Read_Master_Log_Pos: 27880 
    10.   
  
  
  10.                Relay_Log_File: centos3-relay-bin.000002 
    11.   
  
  
  11.                 Relay_Log_Pos: 28025 
    12.   
  
  
  12.         Relay_Master_Log_File: mysql-bin.000008 
    13.   
  
  
  13.              Slave_IO_Running: Yes 
    14.   
  
  
  14.             Slave_SQL_Running: Yes 
    15.   
  
  
  15.               Replicate_Do_DB:  
    16.   
  
  
  16.           Replicate_Ignore_DB:  
    17.   
  
  
  17.            Replicate_Do_Table:  
    18.   
  
  
  18.        Replicate_Ignore_Table:  
    19.   
  
  
  19.       Replicate_Wild_Do_Table:  
    20.   
  
  
  20.   Replicate_Wild_Ignore_Table:  
    21.   
  
  
  21.                    Last_Errno: 0 
    22.   
  
  
  22.                    Last_Error:  
    23.   
  
  
  23.                  Skip_Counter: 0 
    24.   
  
  
  24.           Exec_Master_Log_Pos: 27880 
    25.   
  
  
  25.               Relay_Log_Space: 28182 
    26.   
  
  
  26.               Until_Condition: None 
    27.   
  
  
  27.                Until_Log_File:  
    28.   
  
  
  28.                 Until_Log_Pos: 0 
    29.   
  
  
  29.            Master_SSL_Allowed: No 
    30.   
  
  
  30.            Master_SSL_CA_File:  
    31.   
  
  
  31.            Master_SSL_CA_Path:  
    32.   
  
  
  32.               Master_SSL_Cert:  
    33.   
  
  
  33.             Master_SSL_Cipher:  
    34.   
  
  
  34.                Master_SSL_Key:  
    35.   
  
  
  35.         Seconds_Behind_Master: 0 
    36.   
  
  
  36. Master_SSL_Verify_Server_Cert: No 
    37.   
  
  
  37.                 Last_IO_Errno: 0 
    38.   
  
  
  38.                 Last_IO_Error:  
    39.   
  
  
  39.                Last_SQL_Errno: 0 
    40.   
  
  
  40.                Last_SQL_Error:  
    41.   
  
  
  41. 1 row in set (0.00 sec) 
    42.

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

目前在测试ext3和ext4文件系统对数据库的影响，感觉MySQL性能优化不大；反而，固态SSD硬盘对于提升磁盘I/O方面确实影响不少，这方面有研究的朋友也欢迎来信交流。

【编辑推荐】

  1. 适合初学者的MySQL学习笔记之库操作示例
  2. 适合初学者的MySQL学习笔记之表操作示例
  3. 适合初学者的MySQL学习笔记之MySQL管理心得
  4. 适合初学者的MySQL学习笔记之MySQL查询示例
  5. 适合初学者的MySQL学习笔记之管理员常用操作总结

文章题目：InnoDB引擎数据库主从复制同步心得
网站地址：http://www.gawzjz.com/qtweb2/news20/14670.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

App设计知识

同城分类信息

SF双层罐　　 　成都枢纽中心　　 　成都纯水机　　 　达州托管服务器　　 　成都网络推广公司　　 　成都广告招牌　　 　内江托管服务器　　 　成都网站推广　　 　成都企业网站建设公司　　 　seo优化　　 　攀枝花网站建设　　 　复盛机电设备安装　　 　新都四新网站建设　　 　广安网站建设　　 　全网营销　　 　网络推广平台　　 　成都ssl证书认证　　 　四川广汉锦华　　 　做网站　　 　网站推广