MySQL数据库运维之主从复制搭建

上篇文章详细介绍了MySQL数据库的单机多实例搭建,本篇文章将在上篇文章的基础上介绍MySQL主从复制过程,其中常见的复制架构有:异步复制,半同步复制及同步复制。常用的复制架构有异步复制及半同步复制!

一、常见的复制架构

1、主主复制
(1)结构图:

(2)说明:主主复制即复制的两个实例互为主从,两个库中都可以同时读和写;
(3)优点:


2、一主一从
(1)结构图:

(2)说明:指的是在两个数据库实例中,一个实例扮演着主库的角色,另一个实例扮演着从库的角色。这种方案中,从库通常用来作为备份使用,提供服务的多为主库;
(3)优点:


3、一主多从
(1)结构图:

(2)说明:指的是在多个数据库实例中,只包含了一个主库,其他实例都作为该主库的从库,这种架构是业务规模较大场景中的一种复制架构;
(3)优点:


二、主从复制的原理和过程

1、主从异步复制的原理

主库上的二进制bin-log中记录主库的所有DML操作,同时在主库上运行有一个IO线程,用于响应从库上的bin-log日志读取请求;在从库上运行有一个IO线程和一个SQL线程,IO线程会实时通过网络请求去从库上读取bin-log日志,然后写入到自身的relay-log日志文件中,同时运行在从库上的SQL线程会去解析并读取relay-log,然后在自身库上执行读取到的SQL,完成主从数据的同步,示意图如下:

2、主从同步的工作过程
(1)详细过程


(2)以上详细过程可总结为三步


三、MySQL异步复制搭建过程(单机多实例介绍,沿用上篇文章中搭建的多实例环境)
1、环境准备


2、编辑3306实例的配置文件,打开该实例的二进制日志,并修改server-id,如下


参数解释:


3、重启主库


4、备份主库的数据


参数说明:


5、登陆主库,然后创建复制账户


6、查看主库的二进制日志文件及位置点


7、将主库导出的数据导入从库中


8、修改从库的配置文件,开启relay-log日志,并设置server-id,如下


9、修改从库上的master指向,使其指向主库,并且从主库上最新的二进制日志和位置点开始同步,然后启动主从同步


注意:上述结果中Slave_IO_Running和Slave_SQL_Running都为Yes表示主从同步成功,如果为Connecting...,可以等待一会再次查看,如果为No,表示同步失败;
参数说明:


开启主从的另外一种方法是分别开启SQL线程和IO线程,如下:


10、验证,登陆主库,然后创建数据库,查看从库是否可以正常同步


11、至此,MySQL的主从复制搭建完毕。

12、主从同步中常见的问题
(1)从库的IO线程无法连接,通过"show slave status G"可以查看到具体的错误信息
原因1:在主库上创建的用户授权错误,导致从库无法远程连接主库
解决办法1:在主库上通过"show grants for ‘user‘@‘ip‘;"查看授权是否正确,如果错误,重新授权即可

原因2:如果是独立主机上的两个主从数据库实例,授权正确的情况下,可能是由于主库的防火墙拦截导致从库无法连接主库
解决办法2:关闭主库的防火墙,或者在主库所在服务器添加防火墙规则,允许从库的tcp连接

(2)从库启动的时候提示server-id冲突,导致无法同步主库上的数据
原因:主从库配置文件中的server-id相同了
解决办法:将主库可从库配置文件中的server-id改为不同,重新开启从库上的同步即可

(3)在从库上执行了创建库或者表的操作,然后在主库上又执行了一遍,导致同步错误,如下:


原因:从库上创建了库,主库上再次创建,从库会将主库上的创建过程再次应用到从库,导致从库上创建同名的库,发生错误
解决办法:停止从库,然后设置sql_slave_skip_count,使其跳过同步主库创建库的操作,从下一个操作开始同步,如下:


针对直接写从库的操作,可以再从库上创建一个普通用户,授予其部分操作权限,然后设置从库的只读,通过在从库的配置文件中增加"read-only"参数来设置。但是注意,这个参数对而且只对非super用户生效,对root用户没有任何效果。

13、再生产场景下如何保证主库上的用户可以有写权限,从库上的用户只有读权限
方法1:在设置从库同步的时候,排除对mysql系统库的同步,通过在配置文件中指定binlog_ignore_db=mysql来排除不需要同步的库,或者在配置文件中指定binlog_do_db=db_name只来同步需要同步的库,然后分别在主库上创建可以写的用户,在从库上创建只能读的用户;


方法2:在未排除任何库的情况下,先在主库上创建可以读写的用户,然后在从库中从新回收用户的写权限;
方法3:在主库和从库上创建不同的用户,然后分别授予不同的权限,使得主库只能写,从库只能读;

四、MySQL半同步搭建过程(介绍过程仍然使用单机多实例的环境)

1、定义
是介于异步复制和全同步复制之间的一种复制方式,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。

2、优缺点
(1)优点:有效的提高了数据的安全性,需要等到数据写到从库之后才返回给客户端;
(2)缺点:因为需要等待至少一个从库接收到并写入relaylog中,索引会造成一定的网络延迟,需要在网络延迟较低的环境中使用

3、搭建过程
(1)前提条件:


(2)查看主库和从库上的have_dynamic_loading变量


(3)登陆主库,在主库上安装半同步插件


注:如果想卸载半同步插件,可以使用如下命令:


(4)登陆从库,安装从库上的半同步插件


注:从库上的半同步插件,也可以使用如下命令完成卸载:


(5)查看插件是否加载成功
主库:


从库:


(6)配置并开启主库的半同步复制,然后重启主库


(7)配置并开启从库的半同步复制,然后重启从库


(8)重启从库上的IO线程


(9)查看主库和从库上的半同步复制是否在运行
登录主库查看:


登录从库查看:


上述结果表示主库和从库上的半同步复制运行正常。

(10)验证半同步复制是否正常
验证方法:正常在主库上创建一张表,会立刻返回,耗时0.1s。关闭从库的io线程,然后在主库上执行建表操作,会发现,主库上回阻塞10秒之后才会返回,而这个时间正好和主库上的rpl_semi_sync_master_timeout相同,表示半同步起作用了,主库的DDL操作需要等到从库应用完relaylog之后才返回;


至此,MySQL的半同步复制搭建完成。

4、半同步搭建中常见问题
(1)主从不能正常同步:和主从同步无法正常复制的排查方法相同
(2)不能正常安装半同步插件
原因1:可能是版本问题
解决办法1:查看MySQL实例的版本,如果版本问题,更换新版本重新安装即可


原因2:MySQL的安装目录中未包含用于半同步复制的共享库
解决办法2:找到该版本对应的半同步共享库,然后重新安装

五、全同步复制
同步复制在所有复制方案中最安全,但是性能最差,而且需要使用DRBD(分布式复制块设备)来完成数据的同步,DRBD是一种类似于"rsync+inotify"的架构,通常使用较少,几乎不用,此处不做详细介绍。

到此,MySQL的主从复制介绍完毕,主从复制是一块很大的内容,包括延迟排查,数据一致问题、快速主从搭建及主从复制的高可用,后面会继续写文章介绍,欢迎转发评论!

后续文章将更新在个人小站上,欢迎查看。

原文地址:https://www.cnblogs.com/mysql-sql/p/11017513.html

时间: 2024-11-06 03:52:18

MySQL数据库运维之主从复制搭建的相关文章

MySQL数据库运维之主从复制延迟问题排查

上篇文章介绍了单机环境下的MySQL主从异步复制和主从半同步复制的搭建过程.搭建过程很简单,但是在实际使用过程中,更多的是解决问题,本篇文章将介绍一下MySQL主从复制中常见的问题以及如何定位问题和如何解决问题. 一.从库复制延迟问题 1.可能的原因如下(1)主从服务器处于不同的网络之中,由于网络延迟导致:(2)主从服务器的硬件配置不同,从服务器的硬件配置(包括内存,CPU,网卡等)远低于主服务器:(3)主库上有大量的写入操作,导致从库无法实时重放主库上的binlog:(4)主库上存在着大事务操

MySQL数据库运维课程

MySQL数据库运维课程 http://www.dataguru.cn/article-4834-1.html?union_site=comm100 课程大纲 第一课:机器选型.系统规划 第二课:安装部署 第三课:压力测试 第四课:性能优化 第五课:字符集和权限安全 第六课:日志系统 第七课:备份与恢复1 第八课:备份与恢复2 第九课:常用工具 第十课:MySQL集群 第十一课:分布式集群 第十二课:集群高可用(HA)和容灾演练 第十三课:自动化运维 第十四课:监控和审计系统 第十五课:成长规划

PL1900-炼数成金MySQL数据库运维

随笔背景:在很多时候,很多入门不久的朋友都会问我:我是从其他语言转到程序开发的,有没有一些基础性的资料给我们学习学习呢,你的框架感觉一下太大了,希望有个循序渐进的教程或者视频来学习就好了.对于学习有困难不知道如何提升自己可以加扣:1225462853进行交流得到帮助,获取学习资料. 下载地址:http://pan.baidu.com/s/1jI05TPW MySQL数据库作为世界上最流行的开源数据库,以简单.易用.开源等特点,收到互联网行业的推崇.随着去IOE运动的如火如荼,MySQL数据库已经

XXMySQL数据库运维变更流程

MySQL数据库运维变更流程 草拟时间:2015.11.13制订时间:修订时间: 0x00 目的 规范MySQL数据库的运维人员变更流程,降低操作流程引发的安全隐患,减少人为的错误风险. 0x01.场景 1.业务人员根据业务需要进行数据订正,库表字段结构变更的相关需求.2.运维人员根据数据库日常运维,故障处理与性能优化的变更需求. 0x02.类型 1.数据订正(insert,update,delete相关操作) 重大变更  数据订正表的总数据条数100W以上,且表属于核心业务.        数

与“十“俱进 阿里数据库运维10年演进之路

导语阿里巴巴集团拥有超大的数据库实例规模,在快速发展的过程中我们在运维管理方面也在不断的面临变化,从物理器到容器.从独占到混布.从本地盘到存储计算分离.从集团内到大促云资源,从开源的MySQL到自研分布式数据库,运维管控进行了自我革新与进化. 作者--谭宇(花名:茂七),阿里巴巴高级技术专家.2009年加入阿里,对分布式系统和数据库领域有很大的兴趣.目前负责阿里巴巴集团数据库中台建设,支撑了集团数据库在容器化.存储计算分离.在离线混部.大规模迁移建站以及智能运维等技术探索与落地. 本文梳理了阿里

Linux运维学习之 —— 搭建本地yum源

yum是RPM的前端工具,通过yum命令可以帮我们自动解决安装rpm包之间的依赖关系.下面是搭建本地yum仓库的步骤: 1.挂载光盘(光盘为CentOS-6.5-x86_64-bin-DVD2.iso)     mount /dev/cdrom1 /media ls一下/media这个目录,可以看到以下内容 2.创建本地文件夹,将Packages下的rpm包全部拷贝到本地文件夹     mount /dev/cdrom1 /media/     cp -r /media/Packages/* /

一个兼职DBA的数据库运维经验 小米科技 [email protected] 2011

一个兼职DBA的数据库运维经验 小米科技  [email protected] 2011 报警监控系统粒度太大,不好用(我们公司现状)数据库状况:十个服务器,惠普HP380G7 戴尔R710 ,都做了主从全部sas盘 15K RAID10服务器内存24G数据库跟业务混用,不是专门给数据库用 导致出问题(我们公司现状)备份用的xtrabackup 数据库不大:160G 70G 30G程序支持分库分表 --------------------------问题 io util% 100%(学)正常io

数据库运维保障

数据库运维保障 国庆假期本来是可以开开心心去玩的,但是由于某些突发情况,例如天灾导致的数据库故障的情况还是有可能出现 如果出现这种情况不但破坏了国庆假期玩乐的美好心情,节后上班也可能由于没有做好预防措施要遭遇领导挨批. 为了避免发生这种情况,对于公司业务系统的相关运维人员来说不能掉以轻心,一定要做好预防措施. 以下是总结的一些突发情况预防措施 1.做好公司业务系统的监控报警,关键时刻启动应急预案 2.服务器选择双电源服务器,避免单电源故障造成的服务器宕机 3.选择优质的机房,机房一定要有发电机,

从一个简单的约束看规范性的SQL脚本对数据库运维的影响

原文:从一个简单的约束看规范性的SQL脚本对数据库运维的影响 之前提到了约束的一些特点,看起来也没什么大不了的问题,http://www.cnblogs.com/wy123/p/7350265.html以下以实际生产运维中遇到的一个问题来说明规范的重要性. 如下是一个简单的建表脚本,表面上看起来并没有什么问题.其中创建了3个约束,一个主键约束,一个唯一约束,一个默认值约束,该脚本执行起来没有任何问题. USE Test GO if exists(select 1 from sys.tables