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

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

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 

–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.  
  3. CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000008'MASTER_LOG_POS=106

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

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

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

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

【编辑推荐】

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

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/301601.html<

(0)
管理的头像管理
上一篇2025-05-24 10:03
下一篇 2025-05-24 10:05

相关推荐

  • 云服务器和云虚拟主机怎么选?云服务器和虚拟主机区别

    云服务器适合业务增长快、需弹性扩展的场景,而云虚拟主机适合预算有限、技术门槛低的小型静态网站或测试环境,二者核心区别在于资源独享性与运维复杂度,核心差异解析:从底层架构到使用体验很多人容易混淆这两者,觉得它们都是“买空间建站”,它们的底层逻辑完全不同,云服务器(ECS)就像是你租了一整栋别墅,水电网络独立,你想……

    2026-06-29
    0
  • 赣州智慧旅游招聘是真的吗?赣州旅游人才招聘信息

    中级岗位(3-5年经验)月薪范围通常在6000-10000元,这类岗位需要独立负责项目模块,如独立运营一个抖音账号,或维护一个景区小程序的功能迭代,具备成功案例的候选人议价能力较强,高级岗位(5年以上经验)月薪范围通常在10000-20000元,部分核心管理岗可达更高,这类人才需要具备战略规划能力,如制定整个景……

    2026-06-29
    0
  • 赣州智能物联网车位锁如何管理?智能车位锁管理系统多少钱

    赣州智能物联网车位锁管理的核心在于通过云端平台实现远程控锁、状态实时监控及自动计费,彻底解决传统车位“被占难管”与“找位难”的痛点,在赣州这样的城市,随着机动车保有量的持续增长,老旧小区、商业综合体以及私人固定车位的资源矛盾日益凸显,传统的机械地锁或简易遥控锁,不仅操作繁琐,更无法实现数据化管理,引入智能物联网……

    2026-06-29
    0
  • 赣州智能消防栓好用吗,智能消防栓多少钱一个

    赣州智能消防栓通过物联网技术实现实时监测与远程报警,能显著降低火灾响应时间并提升城市消防安全管理水平,是目前智慧城市建设中不可或缺的基础设施,赣州智能消防栓的核心价值与应用场景传统消防栓往往存在“看不见、摸不着、用不了”的痛点,在赣州这样地形复杂、老城区与新城区并存的区域,传统设施的管理难度极大,智能消防栓的出……

    2026-06-29
    0
  • 云服务器和物理机到底有啥区别?

    云服务器本质上是虚拟化资源池中的弹性实例,而传统物理服务器是独占的硬件实体,前者胜在弹性与运维便捷,后者强在物理隔离与性能稳定,具体选择取决于业务对成本、扩展性及安全合规的权衡,很多人初次接触服务器时,容易把“云服务器”和“传统物理服务器”混为一谈,觉得它们都是用来跑网站或存数据的盒子,这两者的底层逻辑完全不同……

    2026-06-29
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注