- 一主一从
- 主主复制
- 一主多从---扩展系统读取的性能,因为读是在从库读取的;
- 多主一从---5.7开始支持
- 联级复制---
- 实时灾备,用于故障切换
- 读写分离,提供查询服务
- 备份,避免影响业务
- 主库开启binlog日志(设置log-bin参数)
- 主从server-id不同
- 从库服务器能连通主库
1)在Slave 服务器上执行sart slave命令开启主从复制开关,开始进行主从复制。
2)此时,Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器,并请求从执行binlog日志文件的指定位置(日志文件名和位置就是在配置主从复制服务时执行change master命令指定的)之后开始发送binlog日志内容
3)Master服务器接收到来自Slave服务器的IO线程的请求后,其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息,然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外,还有在Master服务器端记录的IO线程。返回的信息中除了binlog中的下一个指定更新位置。
4)当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后,会将binlog日志内容依次写到Slave端自身的Relay Log(即中继日志)文件(Mysql-relay-bin.xxx)的最末端,并将新的binlog文件名和位置记录到master-info文件中,以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容
5)Slave服务器端的SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容,然后及时把Relay LOG 文件中的内容解析成sql语句,并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这样sql语句,并在relay-log.info中记录当前应用中继日志的文件名和位置点
生产场景下轻松部署MySQL主从复制
快速步骤MySQL主从复制1)安装好配置从库的数据库,配置好log-bin和server-id参数
[mysqld] #主库配置 log_bin = /var/log/mariadb/mysql-bin server-id = 12)无需配置主库my.cnf,主库的log-bin和server-id参数默认就是配置好的。
[mysqld] #从库配置 server-id = 2 relay_log = relay-log relay_log_index = relay-log.index read_only = 13)登录主库,增加从库连接同步的账户,例如:rep,并授权replication同步的权限
mysql>grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123456'; mysql> flush privileges;4)使用mysqldump命令带-x和–master-data=2(锁表)的命令及参数全备数据,把它恢复到从库。备份前查看下二进制的版本号,备份完成后再比对是否一致。
主库>mysqldump -uroot -p123456 -S /data/3306/mysql.sock -B -F -R -x --master-data=1 -A --events|gzip >/server/backup/rep3307_(date +%F).sql.gz 从库>mysql -uroot -p123456 -S /data/3307/mysql.sock <./repo3307_2016-07-03.sql5)从库执行CHANGE MASTER TO….语句,需要binlog文件及对应点(因为–master-data=2已经带了)
mysql>CHANGE MASTER TO MASTER_HOST='www.abcdocker.com', MASTER_PORT=3306, MASTER_USER='rep', MASTER_PASSWORD='123456';6)从库开启同步开关,start slave
7)从库show slave status\G,检查同步状态,并在主库更新测试
mysql> SHOW SLAVE STATUS\G ... Slave_IO_Running: Yes Slave_SQL_Running: Yes ...确认 Slave_IO_Running 和 Slave_SQL_Running 两个参数都为 Yes 状态。
- 主库宕机后,数据可能丢失
- 从库只有一个sql Thread,主库写压力大,复制很可能延时
- 半同步复制---解决数据丢失的问题
- 并行复制----解决从库复制延迟的问题MySQL 5.6中SQL线程支持多个,设置参数slave_parallel_workers=4
半同步复制
介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写relay log中才返回给客户端。如果从库超过10秒没有来获取binlog日志。主库自动转换为异步。相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,半同步复制最好在低延时的网络中使用。
MySQL常用高可用方案
mysql+Heartbeat+DRBD高可用场景
基于主从复制的高可用MHA/MMM方案
基于Galera协议的高可用方案PXC:强一致性、无同步延迟
小结:
主从复制是异步的逻辑的SQL语句级的复制复制时,主库有一个I/O线程,从库有两个线程,I/O和SQL线程
实现主从复制的必要条件是主库要开启记录binlog功能.作为复制的所有Mysql节点的server-id都不能相同
binlog文件只记录对数据库有更改的SQL语句(来自主库内容的变更),不记录任何查询(select,show)语句
一个主库的从库太多,导致复制延迟。建议从库数量3-5 为宜,要复制的从节点数量过多,会导致复制延迟
mysql中有自增长字段,在做数据库的主主同步时需要设置自增长的两个相关配置:auto_increment_offset和auto_increment_increment。
- auto_increment_offset表示自增长字段从那个数开始,他的取值范围是1 .. 65535
- auto_increment_increment表示自增长字段每次递增的量,其默认值是1,取值范围是1 .. 65535
在主主同步配置时,需要将两台服务器的auto_increment_increment增长量都配置为2,而要把auto_increment_offset分别配置为1和2.这样才可以避免两台服务器同时做更新时自增长字段的值之间发生冲突
[root@localhost][(none)]> show variables like 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 1 | | auto_increment_offset | 1 | +--------------------------+-------+ rows in set (0.00 sec)auto_increment_increment:自增值。auto_increment_offset:漂移值,也就是步长
由于auto_increment_increment 属于全局可变的变量,故此可以通过修改自增值来达到测试目的
[root@localhost][(none)]> create table boss.autoinc1(col int not null auto_increment primary key); Query OK, 0 rows affected (1.03 sec) [root@localhost][(none)]> set @@auto_increment_increment=10; Query OK, 0 rows affected (0.00 sec) [root@localhost][(none)]> show variables like 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 1 | +--------------------------+-------+ rows in set (0.00 sec)从上面可以看到,自增从10开始,那么此时插入数据会是什么结果?
[root@localhost][(none)]> insert into boss.autoinc1 values(null),(null),(null),(null); Query OK, 4 rows affected (0.29 sec) Records: 4 Duplicates: 0 Warnings: 0 [root@localhost][(none)]> select col from boss.autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | +-----+ rows in set (0.00 sec)
相关推荐
MYSQL数据库主从复制高可用技术改造环境部署方案。。。
详细介绍Mysql、MariaDB主从复制、多主多从架构、负载平衡和集群的设置。读写分离和数据库垂直、水平切分建议使用Sharding JDBC
MYSQL主从复制高可用实施操作,MYSQL主从复制高可用实施操作
MySQL主从复制+lvs与keepalived实现负载高可用
MySQL高可用系列(一)简单主从复制 MySQL高可用系列(一)——简单主从复制 MySQL主从复制简单背景 一、环境说明 二、数据库安装 1、下载MariaDB10.1.24二进制通用包 2、创建用于运行MySQL服务的用户和用户组、数据...
mysql主从复制+lvs与keepalived实现负载高可用
MY-SQL\MYSQL主从复制高可用实施手册
介绍MySQL主从复制的安装配置, MIXED复制是混合使用ROW(行)和STATEMENT(语句)复制。对于DDl语句会以STATEMENT格式记录;对于TABLE里的行操作记录为ROW格式 如果使用INNODB表,事务级别使用了READ COMMITTED or...
分享一套课程,PostgreSQL数据库工程师培训实战教程(主从复制、高可用HA、集群架构)完整版视频教程,欢迎下载学习,希望对大家有帮助。
MySQL高可用扩展集群应用之Mysql主从复制的实现.pdf 学习资料 复习资料 教学资源
MySQL解决方案工程师总结,MySQL高可用解决方案,全部使用MySQL官方社区版本。
MySQL进阶涉及多个主题,其中高可用性、分布式系统、主从复制原理和备份恢复是核心部分。以下是关于这些主题的详细解释: 高可用性 (High Availability) 定义:确保在任何给定的时间点,服务都是可用的。 策略: ...
本文详细描述了MySQL 5.6 主从复制功能的详细搭建步骤及相关参数说明,保证一次成功。文末附带主从切换方法。
摘要:本文首先介绍了MySQL主从复制架构的优势,包括实现读写分离减轻主库压力、提供容灾冗余、负载均衡提升并发能力、分离报表分析等。...关键词:MySQL 主从复制 高可用性 读写分离 冗余 负载均衡 数据分析
数据库的高级使用技巧 数据库的高级使用技巧 数据库的高级使用技巧
基于keepalived和GTID的半同步主从复制的高可用MySQL集群
除了提供高可用、高性能、便捷易用的产品特性,团队还平均每天帮助用户解决2-3起MySQL实例主从复制延时的问题。从大量实践中我们总结了主从复制延时的各种成因和解决方法,现分享于此。 延时问题的重要性 主从复制...
本套课程主要介绍了MySQL主从复制、双主复制、一主多从、多主一从、多线程复制、无损复制、结合keepalived实现mysql双主高可用、LVS双主mysql负载均衡以及使用MyCat数据库中间件实现读写分离。
MySQL的主从复制是实现应用的高性能,高可用的基础。对于数据库读操作较密集的应用,通过使数据库请求负载均衡分配到不同MySQL服务器,可有效减轻数据库压力。当遇到MySQL单点故障中,也能在短时间内实现故障切换。...
后续的读写分离、多活高可用架构等大多都依赖于主从复制。主从复制也是我们学习MySQL过程中必不可少的一部分,关于主从复制的文章有很多,笔者也来凑凑热闹,写写这方面的内容吧,同时分享下自己的经验和方法。 1....