精华内容
下载资源
问答
  • 主要给大家介绍了关于MySQL主从复制的几种复制方式,文中通过示例代码介绍的非常详细,对大家学习或者使用MySQL具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
  • 详解mongoDB主从复制搭建详细过程 实验目的搭建mongoDB主从复制 主 192.168.0.4 从 192.168.0.7 mongodb的安装 1: 下载mongodb www.mongodb.org 下载最新的stable版 查看自己服务器 适合哪个种方式下载(wget 不...
  • Zookeeper是广泛使用的主从复制状态机服务 受Chubby(Google的全局锁定服务)启发 最初在Yahoo得到应用,后来在Mesos, HBase广泛使用 Apache 开源项目 项目链接 主从复制的案例研究 API支持广泛的用例 性能...
  • 主要介绍了使用Docker搭建Redis主从复制的集群,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
  • MySQL8.0 主从复制配置过程介绍,手把手教你如何配置主从服务器
  • 本文档详细介绍了MySQL主从复制和主主复制的步骤。文档共分为3部分:1.主从复制 2.主主复制 3.常用明命令。希望对大家有所帮助。
  • 在异步或半同步的复制结构中,从库出现延迟是一件十分正常的事。 虽出现延迟正常,但是否需要关注,则一般是由业务来评估。 如:从库上有需要较高一致性的读业务,并且要求延迟小于某个值,那么则需要关注。 简单...
  • 什么是MySQL主从复制  简单来说,是保证主SQL(Master)和从SQL(Slave)的数据是一致性的,向Master插入数据后,Slave会自动从Master把修改的数据同步过来(有一定的延迟),通过这种方式来保证数据的一致性,是...
  • (what)什么是mysql 的主从复制?   指一台服务器充当主数据库服务器,另一台或多台服务器充当从数据库服务器,主服务器中的数据自动复制到从服务器之中。对于多级复制,数据库服务器即可充当主机,也可充当从机...
  • MySQL 主从复制配置 主库、从库配置相同 服务器 Ubuntu18.04 数据库 mysql8.0 主库 1、修改主机配置 配置文件地址 /etc/mysql/mysql.conf.d [mysqld] server-id=1 sync_binlog = 1 binlog_format = ROW 2、重启...
  • 在CentOS7下,源码方式安装mysql版本5.7.19,完成主从复制的设置。
  • 花了小一天的时间,终于实现了centos7 mariadb主从复制配置搭建,下面记录一下过程 环境: 虚拟机:vm8; centos7 版本:7.2.1511; mariadb 版本:centos7.2内置的 主库服务器: 10.69.5.200,CentOS 7,MariaDB 10已...
  • 自己电脑实现ok
  • 主要为大家详细介绍了mysql 5.7 docker 主从复制架构搭建教程,感兴趣的小伙伴们可以参考一下
  • MySQL的主从复制的基本原理是从库连接到主库,主库生成一个主库DUMP线程,该DUMP线程的主要任务是 一直挖掘binlog日志,然后发送到从库的IO线程,IO线程接收到日志流后,写入relay log,另一个线 程SQL线程,会读取该...
  • 主从复制的原理本站的其他文章已经介绍得很详细了,这里不再赘述。简单概况一下就是:从端服务器获取主端服务器的操作日志,并对其进行解析,再在从端复现同样的操作,从而达到同步的目的。 生产环境中为了保证系统...
  • 一、什么是主从复制 主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库,主数据库一般是准实时的业务数据库。在最常用的mysql数据库中,支持单项、异步赋值。在赋值过程中,一个服务器充当主...
  • 从mysql索引分析开始,介绍如何建立索引,什么情况需要建立索引,以及查询截取分析,mysql 的锁机制,主从复制,分表分库等mysql高级部分知识结构
  • 主要介绍了CentOS服务器平台搭建mysql主从复制与读写分离的方法,结合实例形式较为详细的分析了CentOS平台搭建mysql主从复制与读写分离的步骤、设置方法、相关操作技巧与注意事项,需要的朋友可以参考下
  • MyCat 是目前流行的基于 java 语言...配合数据库的主从模式还可实现读写分离。MyCat 是基于阿里开源的 Cobar 产品而研发,Cobar 的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得 MyCat 变得非常的强大!
  • 今天搭建mysql主从复制,一直报这个错。我是在一台虚拟机上使用多实例创建的2个不同端口的数据库,查了很久,才解决。 1.检查主从复制的用户名密码; 2.检查MASTER_LOG_FILE和MASTER_LOG_POS。  记住配置从库的命令...
  • MySQL主从复制,读写分离的设置非常简单: 修改配置my.cnf文件 master 和 slave设置的差不多: [mysqld] log-bin=mysql-bin server-id=222 log-bin=mysql-bin的意思是:启用二进制日志。 server-id=222的意思是...
  • 目录 TOC \o "1-3" \h \z \u 原理 1 主从同步配置 2 主服务器同步用户授权 2 配置MySQL主服务器的f文件 3 备机配置 4 常用命令 5 双主配置f 6 binlog_ignore_db引起的同步复制故障 7 常见错误 11 Mysql Binlog三种...
  • 目录 原理 1 主从同步配置 2 主服务器同步用户授权 2 配置 MySQL 主服务器的 f 文件 3 备机配置 4 常用命令 5 双主配置 f 6 binlog_ignore_db 引起的同步复制故障 9 常见错误 13 Mysql Binlog 三种格式介绍及分析 13...
  • keepalived实现对mysql主从复制的主备自动切换 使用MySQL+keepalived是一种非常好的解决方案在MySQL-HA环境中MySQL互为主从关系这样就保证了两台 MySQL数据的一致性然后用keepalived实现虚拟IP通过keepalived自带的...
  • MySQL主从复制的常见拓扑、原理分析以及如何提高主从复制的效率总结
  • 详细介绍了mysql5.7在win10下的主从配置,及添加slave节点 也附上了mybatis下的配置,主数据写,从数据库读,从数据库根据请求数平均分配的查询,达到简单的负载均衡
  • 文章目录什么是主从复制为什么需要主从复制mysql的主从复制mysql主从复制数据一致性问题方法 1:异步复制方法 2:半同步复制方法 3:组复制三种复制总结redis的主从复制 什么是主从复制 是一种数据备份的方案。 简单...

    什么是主从复制

    是一种数据备份的方案。

    简单来说,是使用两个或两个以上相同的数据库,将一个数据库当做主数据库,而另一个数据库当做从数据库。主数据库中进行相应操作时,从数据库记录下所有主数据库的操作,使其二者一模一样。

    image-20200623170950718

    为什么需要主从复制

    • 读写分离:通过主从复制的方式来同步数据,然后通过读写分离提高数据库并发处理能力,提高数据库的吞吐量。
    • 数据备份:我们通过主从复制将主库上的数据复制到了从库上,相当于是一种热备份机制,也就是在主库正常运行的情况下进行的备份,不会影响到服务。
    • 高可用性:数据备份实际上是一种冗余的机制,通过这种冗余的方式可以换取数据库的高可用性,也就是当服务器出现故障或宕机的情况下,可以切换到从服务器上,保证服务的正常运行。

    mysql的主从复制

    实际上主从同步的原理就是基于 Binlog 进行数据同步的。在主从复制过程中,会基于 3 个线程来操作,一个主库线程,两个从库线程。

    • 二进制日志转储线程(Binlog dump thread)是一个主库线程。当从库线程连接的时候,主库可以将二进制日志发送给从库,当主库读取事件的时候,会在 Binlog 上加锁,读取完成之后,再将锁释放掉。(当从库线程连接的时候可以将二进制日志发送给从库

    • 从库 I/O 线程会连接到主库,向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分,并且拷贝到本地形成中继日志(Relay log)。(接到主库,向主库发送请求更新binlog

    • 从库 SQL 线程会读取从库中的中继日志,并且执行日志中的事件,从而将从库中的数据与主库保持同步。(读取从库中的中继日志,并且执行日志中的事件

    总结:从库I/O线程向主库发起更新请求,主库转储线程向从库发送binlog二进制日志,作为中继日志,从库SQL线程从中继日志读取进行同步 (记忆为:请求–响应–执行)

    image-20200623165942887

    MySQL复制的两种方法

    (1)传统方式
    基于主库的bin-log将日志事件和事件位置复制到从库,从库再加以应用来达到主从同步的目的。

    (2)GTID方式(global transaction identitifiers)

    • 是基于事物来复制数据,因此也就不依赖日志文件,同时又能更好的保证主从库数据一致性。
    • 基于GTID的复制是从Mysql5.6开始支持的一种新的复制方式,此方式与传统基于日志的方式存在很大的差异,在原来的基于日志的复制中,从服务器连接到主服务器并告诉主服务器要从哪个二进制日志的偏移量开始执行增量同步,这时我们如果指定的日志偏移量不对,这与可能造成主从数据的不一致,而基于GTID的复制会避免。
    • 在基于GTID的复制中,首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值,然后主库会有把所有没有在从库上执行的事务,发送到从库上进行执行,并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次,这样可以避免由于偏移量的问题造成数据不一致。
    • 什么是GTID,也就是全局事务ID,其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。

    mysql支持的复制类型

    基于语句的复制
    主服务器上面执行的语句在从服务器上面再执行一遍,在MySQL-3.23版本以后支持。
    基于行复制
    把主服务器上面改编后的内容直接复制过去,而不关心到底改变该内容是由哪条语句引发的,在MySQL-5.0版本以后引入。
    混合复制类型
    MySQL默认使用基于语句的复制,当基于语句的复制会引发问题的时候就会使用基于行的复制,MySQL会自动进行选择。

    在MySQL主从复制架构中,读操作可以在所有的服务器上面进行,而写操作只能在主服务器上面进行。主从复制架构虽然给读操作提供了扩展,可如果写操作也比较多的话(多台从服务器还要从主服务器上面同步数据),单主模型的复制中主服务器势必会成为性能瓶颈。

    mysql主从复制数据一致性问题

    进行主从同步的内容是二进制日志,它是一个文件,在进行网络传输的过程中就一定会存在延迟(比如 500ms),这样就可能造成用户在从库上读取的数据不是最新的数据,也就是主从同步中的数据不一致性问题。 比如我们对一条记录进行更新,这个操作是在主库上完成的,而在很短的时间内(比如 100ms)又对同一个记录进行了读取,这时候从库还没有完成数据的更新,那么我们通过从库读到的数据就是一条旧的记录。

    所以在进行读写分离的同时,要解决主从同步中数据不一致的问题,也就是解决主从之间数据复制方式的问题,如果按照数据一致性从弱到强来进行划分,有以下 3 种复制方式。

    方法 1:异步复制

    异步模式就是客户端提交 COMMIT 之后不需要等从库返回任何结果,而是直接将结果返回给客户端,这样做的好处是不会影响主库写的效率,但可能会存在主库宕机,而 Binlog 还没有同步到从库的情况,也就是此时的主库和从库数据不一致。这时候从从库中选择一个作为新主,那么新主则可能缺少原来主服务器中已提交的事务。所以,这种复制模式下的数据一致性是最弱的。

    image-20200623172429046

    方法 2:半同步复制

    MySQL5.5 版本之后开始支持半同步复制的方式。原理是在客户端提交 COMMIT 之后不直接将结果返回给客户端,而是等待至少有一个从库接收到了 Binlog,并且写入到中继日志中,再返回给客户端。 这样做的好处就是提高了数据的一致性,当然相比于异步复制来说,至少多增加了一个网络连接的延迟,降低了主库写的效率。

    在 MySQL5.7 版本中还增加了一个rpl_semi_sync_master_wait_for_slave_count参数,我们可以对应答的从库数量进行设置,默认为 1,也就是说只要有 1 个从库进行了响应,就可以返回给客户端。如果将这个参数调大,可以提升数据一致性的强度,但也会增加主库等待从库响应的时间。

    image-20200623172414465

    方法 3:组复制

    组复制技术,简称 MGR(MySQL Group Replication)。是 MySQL 在 5.7.17 版本中推出的一种新的数据复制技术,这种复制技术是基于 Paxos 协议的状态机复制。

    刚才介绍的异步复制和半同步复制都无法最终保证数据的一致性问题,半同步复制是通过判断从库响应的个数来决定是否返回给客户端,虽然数据一致性相比于异步复制有提升,但仍然无法满足对数据一致性要求高的场景,比如金融领域。MGR 很好地弥补了这两种复制模式的不足。

    下面我们来看下 MGR 是如何工作的(如下图所示)。

    首先我们将多个节点共同组成一个复制组,在执行读写(RW)事务的时候,需要通过一致性协议层(Consensus 层)的同意,也就是读写事务想要进行提交,必须要经过组里“大多数人”(对应 Node 节点)的同意,大多数指的是同意的节点数量需要大于(N/2+1),这样才可以进行提交,而不是原发起方一个说了算。而针对只读(RO)事务则不需要经过组内同意,直接 COMMIT 即可。

    在一个复制组内有多个节点组成,它们各自维护了自己的数据副本,并且在一致性协议层实现了原子消息和全局有序消息,从而保证组内数据的一致性。

    MGR 将 MySQL 带入了数据强一致性的时代,是一个划时代的创新,其中一个重要的原因就是 MGR 是基于 Paxos 协议的。Paxos 算法是由 2013 年的图灵奖获得者 Leslie Lamport 于 1990 年提出的,有关这个算法的决策机制你可以去网上搜一下。

    事实上,Paxos 算法提出来之后就作为分布式一致性算法被广泛应用,比如 Apache 的 ZooKeeper 也是基于 Paxos 实现的。

    image-20200623172354688

    三种复制总结

    异步复制: 客户端提交COMMIT之后不需要等到从库返回任何结果,而是直接将结果返回给客户端
    优点:不会影响主库写的效率
    缺点:可能会存在主库宕机,而binlog还没有同步到从库的情况,也就是此时的主库和从库数据出现不一致的情况。

    半异步复制: MySQL5.5版本之后开始支持半同步复制的方式,在客户端提交COMMIT之后不直接将结果返回给客户端,而是等待至少有一个从库接受到了binlog .并且写入到中继日志中.再进行返回给客户端。
    优点:提升了数据一致性

    不足:仍然存在数据不一致性的情况,增加了网络连接的延迟

    MGR复制: 简称MGR ,是MySQL在5.7.17版本中推出的一种新的数据复制技术,这种复制技术是基于Paxos协议的状态机复制。Paxos协议可以解决分布式系统中出现的数据不一致的问题
    优点:提供了数据强-致性.可以让MySQL应用到更多领域,比如金融
    不足:对网络性能要求高,只支持InnoDB存储引擎

    redis的主从复制

    在redis2.8版本之前主从复制过程如下图:

    1、 slave 服务启动,slave 会建立和master 的连接,发送sync 命令。

    2、master启动一个后台进程将数据库快照保存到RDB文件中

    (注意: 此时如果生成RDB文件过程中存在写数据操作会导致RDB文件和当前主redis数据不一致,所以此时master 主进程会开始收集写命令并缓存起来。

    3、master 就发送RDB文件给slave

    4、slave 将文件保存到磁盘上,然后加载到内存恢复

    5、master把缓存的命令转发给slave

    (注意: 后续master 收到的写命令都会通过开始建立的连接发送给slave。)

    当master 和slave 的连接断开时slave 可以自动重新建立连接。如果master 同时收到多个slave 发来的同步连接命令,只会启动一个进程来写数据库镜像,然后发送给所有slave。

    image-20200623164526963

    redis2.8之前完整复制的问题:

    在redis2.8之前从redis每次同步都会从主redis中复制全部的数据,如果从redis是新创建的从主redis中复制全部的数据这是没有问题的,但是,如果当从redis停止运行,再启动时可能只有少部分数据和主redis不同步,此时启动redis仍然会从主redis复制全部数据,这样的性能肯定没有只复制那一小部分不同步的数据高。

    redis2.8以后部分复制:

    从机连接主机后,会主动发起 PSYNC 命令,从机会提供 master的runid(机器标识,随机生成的一个串) 和 offset(数据偏移量,如果offset主从不一致则说明数据不同步),主机验证 runid 和 offset 是否有效, runid 相当于主机身份验证码,用来验证从机上一次连接的主机,如果runid验证未通过则,则进行全同步,如果验证通过则说明曾经同步过,根据offset同步部分数据。

    img

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 160,524
精华内容 64,209
关键字:

主从复制