本文目录

1. 高并发场景下，如何实现数据库主从同步
2. 两个变频器不同步怎么调
3. redis主从同步怎么实现
4. SQLServer主从数据同步，如何解决延时

高并发场景下，如何实现数据库主从同步

在谈这个特性之前，我们先来看看mysql的复制架构衍生史。MySQL的复制分为三种：第一种，即普通的replication。搭建简单，使用非常广泛，从mysql诞生之初，就产生了这种架构，性能非常好，可谓非常成熟。但是这种架构数据是异步的，所以有丢失数据库的风险。第二种，即mysqlcluster。搭建也简单，本身也比较稳定，是mysql里面对数据保护最最靠谱的架构，也是唯一一个数据完全同步的架构，绝对的零丢失。不过性能就差远些了。第三种，即semi-syncreplication，半同步，性能，功能都介于以上两者之间。从mysql5.5开始诞生，目的是为了折中上述两种架构的性能以及优缺点。“我们今天谈论第三种架构

我们知道，普通的replication，也即mysql的异步复制，依靠mysql二进制日志也即binarylog进行数据复制。比如两台机器，一台主机也即master，另外一台是从机，也即slave。

1.正常的复制为：事务一（t1）写入binlogbuffer；dumper线程通知slave有新的事务t1；binlogbuffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relaylog；slave的sql线程写入到本地数据库。这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。2.异常的复制为：事务一（t1）写入binlogbuffer；dumper线程通知slave有新的事务t1；binlogbuffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。

3.很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，mysql从5.5开始推出了半同步。

即在master的dumper线程通知slave后，增加了一个ack，即是否成功收到t1的标志码。也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复。

我们可以看到半同步带来的新问题：1.如果异常发生，会降级为普通的复制。那么从机出现数据不一致的几率会减少，并不是完全消失。2.主机dumper线程承担的工作变多了，这样显然会降低整个数据库的性能。3.在MySQL5.5和5.6使用after_commit的模式下,即如果slave没有收到事务，也就是还没有写入到relaylog之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。在此情况下，slave会少一个事务的数据。

随着MySQL5.7版本的发布，半同步复制技术升级为全新的Loss-lessSemi-SynchronousReplication架构，其成熟度、数据一致性与执行效率得到显著的提升。

MySQL5.7对数据复制效率进行了改进1主从一致性加强支持在事务commit前等待ACK

新版本的semisync增加了rpl_semi_sync_master_wait_point参数来控制半同步模式下主库在返回给会话事务成功之前提交事务的方式。

该参数有两个值：

AFTER_COMMIT（5.6默认值）

master将每个事务写入binlog,传递到slave刷新到磁盘(relaylog)，同时主库提交事务。master等待slave反馈收到relaylog，只有收到ACK后master才将commitOK结果反馈给客户端。

AFTER_SYNC（5.7默认值，但5.6中无此模式）

master将每个事务写入binlog,传递到slave刷新到磁盘(relaylog)。master等待slave反馈接收到relaylog的ack之后，再提交事务并且返回commitOK结果给客户端。即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relaylog中。

因此5.7引入了after_sync模式，带来的主要收益是解决after_commit导致的mastercrash主从间数据不一致问题，因此在引入after_sync模式后，所有提交的数据已经都被复制，故障切换时数据一致性将得到提升。

2性能提升支持发送binlog和接受ack的异步化

旧版本的semisync受限于dumpthread，原因是dumpthread承担了两份不同且又十分频繁的任务：传送binlog给slave，还需要等待slave反馈信息，而且这两个任务是串行的，dumpthread必须等待slave返回之后才会传送下一个events事务。dumpthread已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS.

图：WithoutACKreceivingthread

为了解决上述问题，在5.7版本的semisync框架中，独立出一个ackcollectorthread，专门用于接收slave的反馈信息。这样master上有两个线程独立工作，可以同时发送binlog到slave，和接收slave的反馈。

图：WithACKreceivingthread3性能提升控制主库接收slave写事务成功反馈数量

MySQL5.7新增了rpl_semi_sync_master_wait_slave_count参数，可以用来控制主库接受多少个slave写事务成功反馈，给高可用架构切换提供了灵活性。

如图所示，当count值为2时，master需等待两个slave的ack

4性能提升

Binlog互斥锁改进

旧版本半同步复制在主提交binlog的写会话和dumpthread读binlog的操作都会对binlog添加互斥锁，导致binlog文件的读写是串行化的，存在并发度的问题。

MySQL5.7对binloglock进行了以下两方面优化

1.移除了dumpthread对binlog的互斥锁

2.加入了安全边际保证binlog的读安全

5性能提升组提交

5.7引入了新的变量slave-parallel-type，其可以配置的值有：

DATABASE（5.7之前默认值），基于库的并行复制方式；LOGICAL_CLOCK（5.7新增值），基于组提交的并行复制方式；

MySQL5.6版本也支持所谓的并行复制，但是其并行只是基于DATABASE的，也就是基于库的。如果用户的MySQL数据库实例中存在多个DATABASE，对于从机复制的速度的确可以有比较大的帮助，如果用户实例仅有一个库，那么就无法实现并行回放，甚至性能会比原来的单线程更差。

MySQL5.7中增加了一种新的并行模式：为同时进入COMMIT阶段的事务分配相同的序列号，这些拥有相同序列号的事务在备库是可以并发执行的。

MySQL5.7真正实现的并行复制，这其中最为主要的原因就是slave服务器的回放与主机是一致的即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制，对于二进制日志格式也无特殊的要求（基于库的并行复制也没有要求）。

因此下面的序列中可以并发的序列为（其中前面一个数字为last_committed，后面一个数字为sequence_number）：

trx11…..2trx21………….3trx31…………………….4trx42……………………….5trx53…………………………..6trx63………………………………7trx76………………………………..8

备库并行规则：当分发一个事务时，其last_committed序列号比当前正在执行的事务的最小sequence_number要小时，则允许执行。

因此，

a)trx1执行，last_commit<2的可并发，trx2,trx3可继续分发执行

b)trx1执行完成后，last_commit<3的可以执行，trx4可分发

c)trx2执行完成后，last_commit<4的可以执行，trx5,trx6可分发

d)trx3、trx4、trx5完成后，last_commit<7的可以执行，trx7可分发

综上所述

我们认为MySQL5.7版对Loss-Less半同步复制技术的优化，使得其成熟度和执行效率都得到了质的提高。我们建议在使用MySQL5.7作为生产环境的部署时，可以使用半同步技术作为高可用与读写分离方案的数据复制方案。

两个变频器不同步怎么调

可以两台变频器用同一个频率和启动信号，这样就可以同步了；还有一个方法就是前面一台变频器用电位器做给定，第一台的模拟输出信号做第二台机器的频率给定，这样也能做到同步；还有一种是主从控制方式的；就看您具体的现场工况了。

redis主从同步怎么实现

Redis主从同步是通过Redis的复制功能实现的。主节点将自己的数据发送给从节点，从节点接收数据并更新自己的数据，从而实现主从数据同步。

具体实现步骤如下：

1.配置主从节点：在主节点的配置文件中设置slaveof从节点的IP和端口号，从节点的配置文件中设置自己的IP和端口号。

2.主节点创建快照文件：主节点会定期创建快照文件，将自己的数据保存到磁盘上。

3.从节点连接主节点：从节点会向主节点发送SYNC命令，请求主节点发送数据给自己。

4.主节点发送数据：主节点收到SYNC命令后，会将自己的数据发送给从节点。如果主节点有新的写操作，也会将写操作发送给从节点。

5.从节点接收数据：从节点接收到主节点发送的数据后，会更新自己的数据。

6.从节点成为主节点：如果主节点出现故障，从节点会成为新的主节点，继续提供服务。

需要注意的是，主从同步是异步的，从节点的数据可能会比主节点的数据旧。如果需要保证数据的一致性，可以使用Redis的哨兵或集群功能。

SQLServer主从数据同步，如何解决延时

SQLServer中的高可用特性工作中使用SQLServer高可用特性的场景也就是数据库主从复制，可以用的特性有三个：复制、镜像、日志传送。复制（发布-订阅模式）：

复制严格来说并不算是一个为高可用性设计的功能，但的确可以被应用于高可用性。复制提供了数据库对象级别的保护。复制使用的是发布-订阅模式，即由主服务器（称为发布服务器）向一个或多个辅助服务器或订阅服务器发布数据。复制可在这些服务器间提供实时的可用性和可伸缩性。它支持筛选，以便为订阅服务器提供数据子集，同时还支持分区更新。订阅服务器处于联机状态，并且可用于报表或其他功能，而无需进行查询恢复。

SQLServer提供四种复制类型：快照复制、事务复制、对等复制以及合并复制。

我们一般选择快照复制或事务复制，两者概念介绍如下：

快照复制

1、概念快照复制是完全按照数据和数据库对象出现时的状态来复制和分发它们的过程。快照复制不需要连续地监控数据变化，因为已发布数据的变化不被增量地传播到订阅服务器，而是周期性的被一次复制。

2、适用情况数据主要是静态的，比如将数据仓库复制到数据集市中一段时间内允许有已过时的数据拷贝的情况小批量数据站点经常脱离连接，并且可接受高延迟

事务复制

1、概念使用事务复制，初始快照数据将被传播到订阅服务器，因此该订阅服务器就具有了一个所谓的初始负载，这是可以开始工作的内容。当出版服务器上发生数据修改时，这些单独的事务会被及时捕获并复制到订阅服务器。并保留事务边界，当所有的改变都被传播后，所有订阅服务器将具有与传播服务器相同的值。

2、适用情况需要数据修改经常在其发生的几秒钟内被传播到订阅服务器需要事务是原子性的订阅服务器在通常是连接到出版服务器上的应用程序不能忍受订阅服务器接收改变的高延迟创建发布-订阅的数据库服务器名不能是IP，只能是具体的服务器名称，如：可以执行以下SQL查看：

结果：

如果上下一致，则说明没有问题，否则就需要改成一致的。如果右键点击创建发布或订阅都不报错，那么可以进行下一步。根据具体情况使用不同的复制类型，这里我使用了事务复制：具体创建过程参考https://www.cnblogs.com/zhaow/articles/8275064.html，这里我们创建个名叫DBPublishZW20180815的发布。并且成功地在订阅数据库中创建了订阅，如：创建发布-订阅后，我们可以监测发布和订阅状态，如：还可以监测发布JOB和Agent的运行状态：

复制中发布服务器和订阅服务器内容不一致的解决办法在事务复制的过程中，有时候会由于各种各样的原因导致发布服务器和订阅服务器的数据不一致，造成这种情况往往是由于以下几种原因之一：①某个Agent运行出现错误或者Agent进程崩溃②比较大型的发布是使用了备份还原，而不是快照复制初始化，而备份后发布端修改了数据③非DistributionAgent线程修改了订阅服务器的数据上面三种情况是最常见的导致发布端和订阅端数据不一致的原因，其中第三种原因往往出现的最多，在这种情况下，通常来说，可以通过重新初始化订阅来解决该问题，但对于比较大的订阅来说，或者发布和订阅之间相隔太远而造成网络宽带的问题，则重新初始化订阅就不是那么吸引人的提案了。因此通过数据对比分析工具来比对有差异的数据，并仅仅更新那些和源不同步的数据则是更好的选择。这类工具包括类似Redgate和xSql的数据对比工具，也可以使用VisualStudio自带的数据对比工具。首先，我删除订阅库中表中的一条数据（其实订阅库应该是只读的），此时订阅库就与发布库数据不一致了。我们来看下监测结果：

可以看到，这里已经有了数据不同步的Log了，还可以看到发布-订阅的整个过程Log：

使用VisualStudio自带的数据对比工具关于VisualStudio的SQLSERVER数据库项目介绍：1、打开VS，点击文件-新建项目-SQLSERVER数据库项目（tips:安装vs时需要添加数据库管理插件）2、创建项目后，在创建的解决方案下右键点击导入-数据库-选择数据库所在连接，导入设置默认就好，如果你们的数据库权限范围较高的话，根据自身情况设置3、启动成功后，会自动扫描数据库的相关配置加载到VS列表当中，这样对系统的数据库架构就一览无遗了4、打开某个表的结构文件，可以看到我们表结构设计，相关的索引、主键、触发器等，当然都只是结构，并且我们在界面上修改后，同时会生成对应的SQL语句，我们可以直接到数据库中F5执行以下即可由于我本机VisualStudio没装这个项目类型，所以参考https://www.cnblogs.com/CareySon/p/3302369.html吧！1、找出被删除的数据2、然后我们点击"更新目标"，则被删除的数据会由发布端同步到订阅端。如：我们再次进行验证订阅，显示已经通过订阅。

OK，本文到此结束，希望对大家有所帮助。