MySQL主从复制包括异步模式、半同步模式、GTID模式以及多源复制模式，默认是异步模式 (如之前详细介绍的mysql主从复制)。所谓异步模式指的是MySQL 主服务器上I/O thread 线程将二进制日志写入binlog文件之后就返回客户端结果，不会考虑二进制日志是否完整传输到从服务器以及是否完整存放到从服务器上的relay日志中，这种模式一旦主服务(器)宕机，数据就可能会发生丢失。
数据库容灾的基础是副本。副本间同步的关键是日志，所以只要日志已持久化到备用副本，数据就不会丢。
异步复制（Asynchronous replication），MySQL默认的复制是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理。原理最简单，性能最好，但是主从之间数据不一致的概率很大。
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
转载：https://www.cnblogs.com/zero-gg/p/9057092.html
MySQL通过复制（Replication）实现存储系统的高可用。目前，MySQL支持的复制方式有：
关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。
关于对高可用的分级我们暂不做详细的讨论，这里只讨论常用高可用方案的优缺点以及选型。
主库将更新写入Binlog日志文件后，不需要等待数据更新是否已经复制到从库中，就可以继续处理更多的请求。Master将事件写入binlog，但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下，如果Master宕机，事务在Master上已提交，但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制，此时Slave也可能会丢失事务。MySQL复制默认是异步复制，异步复制提供了最佳性能。
何为半同步复制模式呢？在此我们先了解异步复制模式，这是MySQL的默认复制选项。异步复制即是master数据库把binlog日志发送给slave数据库，然后就没有了然后了。在此暴露一个问题，当slave服务器发生故障了，那么肯定会导致主从数据库服务器的数据不一致。
我们在考虑MySQL数据库的高可用的架构时，如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。与此同时，用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。这些都是MySQL高可用方案的基本标准。
半同步复制需要安装额外插件之后才能启用，然后通过相应的变量启用，在安装插件之前这些变量不可用
要监控半同步的情况，首选需要安装python connector for mysql ,
原因：1.数据安全问题，如果你将数据存贮在容器中，当容器rm后，你就无了，当然你可以使用外挂数据卷的方式，但我在某些大佬的文章上看到，即使你外挂的数据卷，docker volumes的设计是围绕union fs镜像层提供持久化存贮，如果容器异常崩溃，数据库未正常关闭，则可能损坏数据，而且外挂数据卷对物理机硬件损伤较大（这段话是我从大佬文章里抄的，但前面rm数据就不见了是我实践过的）
年后在进行腾讯二面的时候，写完算法的后问的第一个问题就是，MySQL的半同步是什么？我当时直接懵了，我以为是问的MySQL的两阶段提交的问题呢？结果确认了一下后不是两阶段提交，然后面试官看我连问的是啥都不知道，就直接跳过这个问题，直接聊下一个问题了。所以这次总结一下这部分的知识内容，文字内容比较多，可能会有些枯燥，但对于这方面感兴趣的人来说还是比较有意思的。
关于MySQL的复制架构，大体有下面三种方式，异步，全同步复制，半同步复制。 三种复制方式 第一种是异步复制，是比较经典的主从复制，搭建主从默认的架构方式，就是属于异步的，相对来说性能要好一些。但是还是会有丢失数据的情况。 第二种是全复制，比如说MySQL Cluster这样的方式，是属于全复制的，实际上MySQL Cluster其实发展并不大顺利，更多时候是一个实验室产品，但是时间定格在2016年12月12日，MySQL 5.7.17 GA的重大特性group replication插件
为了做到无损切换并且考虑到主机可能发生磁盘损坏且无法恢复的场景，需要用到日志复制技术，将本地日志及时同步到其他节点。实现方式有三种：
直到目前的最新版本为止，MySQL缺省依然使用异步复制策略。简单说所谓异步复制，指的是主库写二进制日志、从库的I/O线程读主库的二进制日志写本地中继日志、从库的SQL线程重放中继日志，这三步操作都是异步进行的。如此选择的主要理由是出于性能考虑，与同步复制相比，异步复制显然更快，同时能承载更高的吞吐量。但异步复制的缺点同样明显，不能保证主从数据实时一致，也无法控制从库的延迟时间，因此它不适于要求主从数据实时同步的场景。例如，为了分解读写压力，同一程序写主库读从库，但要求读到的数据与读主库的相同，异步复制不满足这种强数据一致性需求。异步复制的另一个问题是可能会有数据丢失，例如主库宕机时，已经提交的事务可能还没有传到从库上，如果此时强行主从切换，可能导致新主库上的数据不完整。
网络上关于 MySQL 主从复制的文章很多都是讲解如何实现，以及部分实现原理，缺乏对 MySQL 主从复制的全面介绍。例如主从复制的模式(半同步模式和异步同步模式)、同步的原理(binary log+position，GTID)、主从复制的常见问题都缺乏一个全面的总结。
“高可用”是互联网一个永恒的话题，先避开MySQL不谈，为了保证各种服务的高可用有几种常用的解决方案。
MySQL的复制默认是异步的，主从复制至少需要两个MYSQL服务，这些MySQL服务可以分布在不同的服务器上，也可以在同一台服务器上。
内容来源：2017年7月22日，UCloud高级研发工程师王松磊在“饿了么技术沙龙【第九弹】上海研发中心·运维专场”进行《数据库高可用架构》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。 阅读字数：3280 | 9分钟阅读 摘要 分享UCloud在数据库高可用上的最佳实践。首先介绍MYSQL常见的高可用方式，并分析其存在的问题，然后给出UCloud对此的思考和解决方法。 嘉宾演讲视频及PPT回顾：http://suo.im/2obXuQ MySQL
MySQL是一个RDBMS（关系型数据库管理系统），由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。由于其体积小、速度快、拥有成本低，尤其是开放源码这一特点，广受各大企业欢迎，包括腾讯，阿里，百度，网易，Google，FaceBook等互联网巨头企业 随着互联网的高速发展，互联网服务可用性变得越发重要，数据容灾也随之成为各企业的关键任务。在数据容灾中，数据库集群如何处理数据一致性也成为了各企业需要解决的问题。特别在一些新兴的金融服务中，MySQL也逐渐成为其核心数据库，如何保证金钱的准
要开启半同步，我们需要安装插件，基本的要求是在满足异步复制的情况下，版本在5.5以上，并且变量have_dynamic_loading为YES，即判断是否支持动态插件。
GTID模式：GTID是事务的ID，唯一识别号，全局唯一。对于主从复制简单来说就是不需要管binlog日志和复制点，简化复制操作和降低复制集群维护的难度，但是只支持带事务的引擎和语句
对于一些关键数据，例如账户数据，对可靠性和一致性的要求非常高。我们宁可牺牲短暂时间内的可用性，也不允许数据出现错误或丢失。所以早期我们会发现业界存在这种现象：DB设置了主备同步，主DB挂了，但是不敢切换到备DB，只能暂停服务。这种现象的主要原因有两点：
一、复制的意义 mysql的复制功能是构建基于MySql大规模，高性能应用的基础，我们可以通过为服务器配置一个或多个备库来进行数据同步；复制功能不仅有利于构建高性能的应用，同时也是高可用性，可扩展行，灾难恢复，备份以及数据仓库等工作的基础 二、复制的方式 Mysql支持3种方式：基于语句的复制、基于行的复制、混合复制。对应的binlog的格式也有三种：STATEMENT，ROW，MIXED (1)基于语句的复制（SBR） 每一条会修改数据的sql语句会记录到binlog中。优点是不需要记录每一条sql语句和
MySQL复制是MySQL成功的最重要原因之一，前东家某公司内网上有相关资料，低下评论戏称"核心科技"，今天将核心科技分享给大家
今天主要聊一下MySQL的异步复制、全同步复制与半同步复制，目前我们生产库实际上用的就是异步复制了，后面再转成半同步复制。
前面一篇，我们学习到了MySQL多版本并发控制（MVCC）实现原理，这一篇我们接着学习MySQL主从复制模式下的延迟解决方案。
在很多场景下，MySQL 的高可用都是借助主从复制实现的，而 MySQL 复制不断的演进，也使得她越来越受欢迎。这一节内容就来聊聊 MySQL 复制的演进。
查看大图请移步 https://www.jianshu.com/p/5ebf4f4c1cf8
前不久在工作过程中用到了kafka中间件，简单来说是个消息队列，除了支持高吞吐量、发布订阅等功能外，它还支持回放，我可以通过修改偏移量重新获取数据，这个功能是一个非常常见的使用场景，也是我选择kafka的一个重要原因。
MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。 Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。 另一方面，由于SQL Thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。 常见原因：Master负载过高、Slave负载过高、网络延迟、机器性能太低、MySQL配置不合理。
MySQL 复制在业界里有叫：mysql 同步，ab 复制等。专业名称就是叫：复制。
近期研究了下MySQL的半同步复制机制，想要体验一下。搭建环境是件麻烦事，然后就想到用Docker快速搭建环境。
1）主服务器将所有数据和结构更改记录到二进制日志中。 2）从属服务器从主服务器请求该二进制日志并在本地应用其内容。 3）IO：请求主库，获取上一次执行过的新的事件，并存放到relaylog 4）SQL：从relaylog中将sql语句翻译给从库执行
在基于MySQL传统复制的时代（MySQL版本低于5.5），MHA在MySQL高可用中可以说是独领风骚。
上篇文章我们聊了单机模式下，MySQL是如何保证数据一致性的，但是在实际的生产环境中，很少采用单机模式。现在所有的集群架构都是从MySQL的主从复制演变过来的。MySQL的主从复制是通过将主库的binlog发送至从库，从库重新提交主库的变更来实现主从数据的一致性。MySQL的主从复制主要分为三种：异步复制、半同步复制、组复制（MGR）。
要实施复制，首先必须打开 master 端的 binlog 功能，否则无法实现。因为整个复制过程实际上就是 slave 从 master 获取该 binlog 然后再在自己身上完全顺序的执行 binlog 中所记录的各种更新操作。
mysql默认是异步复制, 但是可以使用半同步插件(semisync_master.so和semisync_slave.so)来做半同步复制, 等待至少N个(rpl_semi_sync_master_wait_for_slave_count默认1)从库收到binlog后,才返回客户端提交成功. 当然超时(rpl_semi_sync_master_timeout默认10秒)后就变成异步了
1、打开主库和从库的MySQL服务，然后安装插件，半同步复制插件在目录/usr/local/mysql/lib/plugin下
1.异步复制 搭建简单，使用非常广泛，从mysql诞生之初就产生了这种架构性能非常好，可谓非成熟，但是这种架构数据是异步的，所以有丢失数据库的风险。 2.全同步复制 保证数据安全，不丢失数据，损失性能。 3.传统半同步复制 性能，功能都介于异步和全同步之间，从5.5开始诞生，目的是为了折中上述两种架构的性能以及优缺点。 4.无损复制（增强版的半同步复制） 数据零丢失，性能好，mysql5.7诞生。 异步复制原理： 在异步复制中，主库写数据导二进制日志且同步从库请求二进制日志后写入中断日志并fluh disk
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/81045843
MySQL实例主从配置，可以实现数据同步、备份、读写分离、容灾:可以在主库挂掉后从备用从库中选举新Master进行数据恢复动作。
又赶上一年一度的金九银十的日子，这段期间的招聘岗位相对前几个月会多些，如果在目前公司没有进步、没有前途时，这段时间可以准备一下，去外面看看机会。不过在外面找工作时，可以提前在网上看看招聘信息，看看自己是否达到公司要求。如果多看下高薪资的技术人员招聘要求时，就会发现对三高都有一定的要求，比如下面一家公司的要求就对高并发、高负载和高可用性系统设计要有开发经验。
文章集中整理总结mysql分库分表开源产品，分布式数据库的设计，以及实际应用案例等相关内容，部分附上本文作者实际应用过程中的理解。
CDB现在支持类型复制类型比较多，我这里选择以下几种复制类型压测对比： MySQL 5.6[异步|半同步|增强半同步]复制，5.7异步复制（当时5.7只支持异步复制).
主库在提交事务时，在客户端接收到查询结束反馈前必须保证二进制日志已经传输到至少一台备库上。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
