精华内容
下载资源
问答
  • 主从同步:为了保证一致性,从库会实时与主库同步数据,但是会有延迟。 可能会产生的问题 同步延迟可能会导致主从数据不一致。例如:主库正在进行写操作,从库同时也正在读操作,但此时从库还未同步到主库的最新...

    数据库集群架构

    目前流行的数据库集群架构包括以下三点:
    一主多从:高可用方案,主库挂掉,从库会变成主库;
    读写分离:减少单机数据库压力,主库提供写服务,从库提供读服务;
    主从同步:为了保证一致性,从库会实时与主库同步数据,但是会有延迟。
    在这里插入图片描述

    可能会产生的问题

    同步延迟可能会导致主从数据不一致。例如:主库正在进行写操作,从库同时也正在读操作,但此时从库还未同步到主库的最新数据,导致从库读到脏数据。

    如何解决

    忽略:在业务不保证数据强一致性的情况下,可以选择忽略(技术永远是为业务提供服务的!);
    强制性读写主库:读写都落在主库上,从库只用来做备库防止主库挂掉,可以采用缓存方式缓解主库压力(先读缓存再读数据库);
    在这里插入图片描述
    选择性读写主库:上面的那种方案对于主库来说压力还是很大,可以考虑多加一个缓存来判断主从是否同步完成。当写请求主库的时候,同时缓存记录一个key(key值可以是数据库名:表名:主键的形式),超时时间设置为主从同步的延迟时间。读的时候,先判断缓存里是否有这个key,有就说明主从同步还没完成,此时读主库。无就说明同步已完成,此时读从库。
    在这里插入图片描述

    展开全文
  • Redis是一种高性能的内存数据库;而MySQL是基于磁盘文件的关系型数据库,相比于Redis来说,读取速度会慢一些,但是功能强大,可以用于存储持久化的数据。在实际工作中,我们常常将Redis作为缓存与 ...

    Redis是一种高性能的内存数据库;而MySQL是基于磁盘文件的关系型数据库,相比于Redis来说,读取速度会慢一些,但是功能强大,可以用于存储持久化的数据。在实际工作中,我们常常将Redis作为缓存与MySQL配合来使用,当有数据访问请求的时候,首先会从缓存中进行查找,如果存在就直接取出,如果不存在再访问数据库,这样就提升了读取的效率,也减少了堆后端数据库的访问压力。可以说使用Redis这种缓存架构是高并发架构中非常重要的一环。

    在这里插入图片描述

    当然我们也可以对MySQL做主从架构并且进行读写分离,让主服务器(Master)处理写请求,从服务器(Slave)处理读请求,这样同样可以提升数据库的并发处理能力。不过主从架构的作用不止如此,我们今天就从下面几个方面了解一下它:

    1、为什么需要主从同步,设置主从同步有什么样的作用?
    2、主从同步的原理是怎样的?在进行主从同步的同时会引入哪些问题?
    3、为了保证主从同步的数据一致性,都有哪些方案?

    为什么需要主从同步

    首先不是所有的应用都需要对数据库进行主从架构的设置,毕竟设置架构本身是有成本的,如果我们的目的在于提升数据库高并发访问的效率,那么首先需要考虑的应该是如何优化你的SQL和索引,这种方式简单有效,其次才是采用缓存的策略,比如使用Redis,通过Redis高性能的优势把热点数据保存在内存数据库中,提升读取的效率,最后才是对数据库采用主从架构,进行读写分离。

    按照上面的方式进行优化,使用和维护的成本是由小到大的。

    主从同步设计不仅可以提升数据库的吞吐量,还有以下三个方面的作用。

    首先是可以读写分离,我们可以通过主从复制的方式来同步数据,然后通过读写分离提升数据库的并发处理能力。

    简单来说就是同一份数据被放在了多个数据库中,其中一个数据库是Master主库,其余的多个数据库是Slave从库。当主库进行更新的时候,会自动将数据复制到从库中,而我们在客户端读取数据的时候,会从从库进行读取,也就是采用读写分离的方式。互联网的应用往往是“读多写少”的需求,采用读写分离的方式,可以实现更高的并发访问。原本所有的读写压力都由一台服务器承担,现在有多个“兄弟”帮忙处理读请求,这样就减少了对后端大哥(Maste)的压力。同时,我们还能对从服务器进行负载均衡,让不同的读请求按照策略均匀的分配到不同的从服务器中,让读取更加顺畅。读取顺畅的另一个原因,就是减少了锁表的影响,比如我们让主库负责写,当主库出现写锁的时候,不会影响到从库进行SELECT操作。

    第二个作用就是数据备份。我们通过主从复制将主库上的数据复制到了从库上,相当于是一种热备份机制,也就是在主库正常运行下进行备份,不会影响到服务。

    第三个作用是具有高可用性。我刚才讲的数据备份实际上是一种冗余的机制,通过这种冗余的方式可以换取数据库的高可用性,也就是当服务器出现故障或者宕机的情况下,可以切换到从服务器上,让从服务器充当主服务器,保证服务的正常运行。

    关于高可用性的程度,我们可以用一个指标衡量,既正常可用时间 / 全年时间。比如要达到全年99.999%的时间都可用,就意味着系统在一年中的不可用时间不得超过5.256分钟,其他时间都需要保持可用的状态。需要注意的是,这5.256分钟包括了系统崩溃的时间,也包括了日常维护操作导致的停机时间。

    事实上,更高的高可用性,意味着需要付出更高的成本代价,在现实中我们需要结合业务需求和成本来进行选择。

    主从同步的原理是怎样的

    提到主从同步的原理,我们就需要了解在数据库中的一个重要日志文件,那就是Binlog二进制文件,它记录了对数据库进行更新的事件,事实上主从同步的原理就是基于Binlog进行数据同步的。在主从复制过程中,会基于三个线程来操作,一个主库线程,两个从库线程。

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

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

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

    在这里插入图片描述

    你能看到主从同步的内容就是二进制日志(Binlog),它虽然叫二进制日志,实际上存储的是一个又一个的事件(Event),这些事件分别对应着数据库的更新操作,比如INSERT、UPDATE、DELETE等。另外我们还需要注意的是,不是所有版本的MySQL都默认开启了服务器的二进制日志,在进行主从同步的时候,我们需要先检查服务器是否已经开启了二进制日志。

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

    这种情况下该怎么办呢?

    如何解决主从同步的数据一致性问题

    可以想象下,如果我们想要操作的数据都存储在同一个数据库中,那么对数据进行更新的时候,可以对记录进行加写锁,这样在读取的时候就不会发生数据不一致的情况了。但这时从库的作用就是备份数据,没有做到读写分离,分担主库的压力。

    在这里插入图片描述

    因此我们还需要想办法,在进行读写分离的时候,解决主从同步中数据不一致的问题,也就是解决主从之间数据复制方式的问题,如果按照数据一致性从弱到强来进行划分,有以下三种复制方式。

    方式1:异步复制

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

    在这里插入图片描述

    方式2:半同步复制

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

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

    在这里插入图片描述

    方式3:组复制

    组复制技术,简称MGR。是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算法实现的。

    总结

    我今天讲解了数据库的主从同步,如果你的目标仅仅是数据库的高并发,那么可以先从 SQL 优化,索引以及 Redis 缓存数据库这些方面来考虑优化,然后再考虑是否采用主从架构的方式。

    在主从架构的配置中,如果想要采取读写分离的策略,我们可以自己编写程序,也可以通过第三方的中间件来实现。

    自己编写程序的好处就在于比较自主,我们可以自己判断哪些查询在从库上来执行,针对实时性要求高的需求,我们还可以考虑哪些查询可以在主库上执行。同时,程序直接连接数据库,减少了中间件层,相当于减少了性能损耗。

    采用中间件的方法有很明显的优势,功能强大,使用简单。但因为在客户端和数据库之间增加了中间件层会有一些性能损耗,同时商业中间件也是有使用成本的。我们也可以考虑采取一些优秀的开源工具,比如 MaxScale。它是 MariaDB 开发的 MySySQL 数据中间件。比如在下图中,使用 MaxScale作为数据库的代理,通过路由转发完成了读写分离。同时我们也可以使用 MHA 工具作为强一致的主从切换工具,从而完成 MySQL的高可用架构。

    在这里插入图片描述

    在这里插入图片描述

    展开全文
  • 主流数据库均支持这种完全的同步模式。已经有人提到MySQL的Semi-sync功能(从MySQL5.6开始官方支持,此前的版本可以考虑Google出的非官方补丁),就是基于这种原理。 不过,一般不建议使用这种同步模式。
        主机与备机之间的物理延迟是不可控的,也是无法避免的。但是如果仅仅需要满足这种强一致性,是相对简单的事:只需要在主机写入时,确认更新已经同步到备机之后,再返回写操作成功即可。主流数据库均支持这种完全的同步模式。已经有人提到MySQL的Semi-sync功能(从MySQL5.6开始官方支持,此前的版本可以考虑Google出的非官方补丁),就是基于这种原理。
    
        不过,一般不建议使用这种同步模式。显而易见,如果写操作必须等待更新同步完成,肯定会极大地影响性能,除非你不在乎性能。
    
        问题的关键在于,主从架构是一种用于数据容错的<b>高可用性</b>解决方案,而不是一种处理<b>高并发压力</b>的解决方案。它的目的是主机当机以后备机可以马上顶上,而不是让备机来分担并发压力。完全同步机制也只是用于保证主机当机以后数据不会丢失,而不是保证从备机读取数据时的一致性。因此,我根本也不主张你使用从备机读取数据以分担并发压力这种方式。
    
        解决方式是,不要试图在数据库层解决并发的读操作问题,至少不要在主从架构的数据库层解决。要在数据库层之上架构一个redis这样的分布式缓存来解决,它是专门干这个的。其性能肯定远高于从备机读取数据。
    
        分布式缓存也存在着一些限制,例如不能完全支持事务处理。这取决于你的应用场景。对于一般的互联网应用,并发压力大但不要求支持事务,可以考虑分布式缓存。对于银行这样严格要求强一致性的应用,对于写入延迟一般没什么要求(延迟几个小时都可以接受,数据不出错就行),可以适用完全同步的模式。
    
        另外,不建议你使用“通过版本库判断最新版本再分别路由到主机或备机”的山寨版解决方案。这会对应用层的代码造成严重污染。
    
    


    展开全文
  • 在聊数据库与缓存一致性问题之前,先聊聊数据库主库与从库的一致性问题。 问:常见的数据库集群架构如何? 答:一主多从,主从同步,读写分离。 如上图: (1)一个主库提供写服务 (2)多个从库提供读服务...

    在聊数据库与缓存一致性问题之前,先聊聊数据库主库与从库的一致性问题。

     

    问:常见的数据库集群架构如何?

    :一主多从,主从同步,读写分离。

    如上图:

    (1)一个主库提供写服务

    (2)多个从库提供读服务,可以增加从库提升读性能

    (3)主从之间同步数据

    画外音:任何方案不要忘了本心,加从库的本心,是提升读性能。

     

    问:为什么会出现不一致?

    :主从同步有时延,这个时延期间读从库,可能读到不一致的数据。

    如上图:

    (1)服务发起了一个写请求

    (2)服务又发起了一个读请求,此时同步未完成,读到一个不一致的脏数据

    (3)数据库主从同步最后才完成

    画外音:任何数据冗余,必将引发一致性问题。

     

    问:如何避免这种主从延时导致的不一致?

    :常见的方法有这么几种。

     

    方案一:忽略

    任何脱离业务的架构设计都是耍流氓,绝大部分业务,例如:百度搜索,淘宝订单,QQ消息,58帖子都允许短时间不一致。

    画外音:如果业务能接受,最推崇此法。

     

    如果业务能够接受,别把系统架构搞得太复杂。

     

    方案二:强制读主

    如上图:

    (1)使用一个高可用主库提供数据库服务

    (2)读和写都落到主库上

    (3)采用缓存来提升系统读性能

    这是很常见的微服务架构,可以避免数据库主从一致性问题。

     

    方案三:选择性读主

    强制读主过于粗暴,毕竟只有少量写请求,很短时间,可能读取到脏数据。

     

    有没有可能实现,只有这一段时间,可能读到从库脏数据的读请求读主,平时读从呢?

     

    可以利用一个缓存记录必须读主的数据。

    如上图,当写请求发生时:

    (1)写主库

    (2)将哪个库,哪个表,哪个主键三个信息拼装一个key设置到cache里,这条记录的超时时间,设置为“主从同步时延”

    画外音:key的格式为“db:table:PK”,假设主从延时为1s,这个key的cache超时时间也为1s。

     

    如上图,当读请求发生时:

    这是要读哪个库,哪个表,哪个主键的数据呢,也将这三个信息拼装一个key,到cache里去查询,如果,

    (1)cache里有这个key,说明1s内刚发生过写请求,数据库主从同步可能还没有完成,此时就应该去主库查询

    (2)cache里没有这个key,说明最近没有发生过写请求,此时就可以去从库查询

    以此,保证读到的一定不是不一致的脏数据。

     

    总结

    数据库主库和从库不一致,常见有这么几种优化方案:

    (1)业务可以接受,系统不优化

    (2)强制读主,高可用主库,用缓存提高读性能

    (3)在cache里记录哪些记录发生过写请求,来路由读主还是读从

     

    文字很短,不能解决所有问题,但希望能给大家一些启示。

    展开全文
  • 内容: 简述数据库主从同步如何实现 主从同步: 主从的引入: 为了解决当主节点宕机时,引起数据的丢失,往往会在一个主节点启动多个从结点来进行备份 同步: 既然是备份,那么就有一个备份的过程,而在这个备份...
  • 如果数据库使用的是读写分离的DB,在日常使用的时候由于主从同步延迟,会出现写之后立刻读,没办法读到最新的修改。 例如我们一开始插入了一条name='张三'的数据,这里用了写连接,写到了主库,然后后面的代码又要去...
  • 数据库的读写操作就特别大,就会导致服务器受不了那么多用户的请求和对数据的操作,导致服务器负荷,相应的用户的等待时间就会特别长,给用户的体验特别差,而主从同步就很好的解决的这种并发的问题主从同步:...
  • mysql数据库主从判断

    万次阅读 2016-12-19 16:01:12
    在上一家公司做项目的时候遇到的一个问题如何判断mysql主从数据库是否同步?当时我还没有接触到mysql主从服务的使用,于是就在网上搜索各种资料,例如什么如何查看mysql主从状态信息之类的问题。到最后有了一个...
  • [数据库]MYSQL主从同步

    2019-02-20 14:12:12
    关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用mysql...
  • mysql主从同步

    2020-07-05 22:55:48
    MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即...这种问题如何解决呢? 1. MySQL数据库主从同步延迟原理。 2. MySQL数据库主从同步延迟是怎么产生的。 3. MySQL数据库主从同步延迟解
  • MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力;②在从主服务器进行备份,避免备份期间影响主服务器服务;...这种问题如何解决呢? 1. MySQL数据...
  • MySQL的主从同步延时怎么解决

    万次阅读 2020-10-15 16:18:30
    如何解决MySQL主从同步的延时问题? MySQL查看数据库运行状态:show status; 可以看到Seconds_Behind_Master这个信息,是slave落后master的秒数,我们可以通过Seconds_Behind_Master数字查看slave是否落后master。 ...
  •   大型网站为了减轻服务器处理海量的并发访问,所产生的性能问题,采用了很多...主从同步如何实现?   同步工作主要又三步,第一步就是主服务器(master)将对数据的操作记录到二进制日志文件(Binary log)中,
  • 导读:本文是作者用MySQL数据库手动注册binlog文件造成主从同步异常后,详述整个分析与解决的过程。 一、问题来源 因为某些需求,想将备份的binlog文件恢复到主库并且进行注册,在不关闭主从同步的情况下...
  • MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力;②在从主服务器进行备份,避免备份期间影响主...这种问题如何解决呢?1. MySQL数据库主从同...
  • MySQL读写分离原理及主从同步延时解决 1、 为什么要读写分离 高并发场景下,往往小部分数据在缓存中是读取不到的。 缓存里读取不到数据可分为两种原因: 缓存服务刚启动或只是缓存预热了部分数据。 缓存的内存塞满...
  • 关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用mysql...
  • MySQL主从同步的简单理解 许多大型网站为了减轻海量用户对于服务器并发访问量的性能问题,会使用很多解决的方案, ...如何解决,解决方案之一就是主从分离。 主从那长话短说就是,一台服务器我处理不了就用...
  • 关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用mysql...
  • mariadb的主从同步和读写分离

    千次阅读 2017-03-14 14:39:01
    数据库的优化设计对以后web项目能否承担高并发所带来的巨大负担是个非常好的解决方案...接下来说说如何实现数据库主从同步和读写分离 看个人情况,可有三四台主机都没问题。本人现在是用2台服务器,实现2台服务器数据
  • MySQL主从同步原理

    千次阅读 2017-12-30 16:58:15
    前言关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用...
  • 如何扩容 应用拆分的垂直拆分 ...分库解决多个表之间的IO竞争、单机容量问题。 分表,即水平数据拆分。分表提高了单表查询速度。 先按照业务维度进行垂直拆分,不同的应用可以使用不同的数据库,再根.

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 180
精华内容 72
关键字:

如何解决数据库主从同步问题