主从复制,mysql临时设置主从

主从复制，mysql临时设置主从？

主从同步的详细过程如下：

1. 主服务器验证连接。

2. 主服务器为从服务器开启一个线程。

3. 从服务器将主服务器日志的偏移位告诉主服务器。

4. 主服务器检查该值是否小于当前二进制日志偏移位。

5. 如果小于，则通知从服

同步JK触发器和主从JK触发器的区别？

回答如下：同步JK触发器和主从JK触发器的主要区别在于它们的时钟输入和输出。

同步JK触发器在时钟信号的上升沿或下降沿触发，并且具有单一的输出。而主从JK触发器包含两个JK触发器，其中一个是主触发器，另一个是从触发器，它们的时钟信号相反，主触发器在时钟上升沿触发，从触发器在时钟下降沿触发。

主从JK触发器的输出由从触发器控制，它在时钟上升沿之前保持不变，这可以提供更稳定的输出。虽然它们的真值表相同，但是它们的内部结构和工作原理不同。

mysql主从复制是什么概念？

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

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

1. 正常的复制为：事务一（t1）写入binlog buffer；dumper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。 2. 异常的复制为：事务一（t1）写入binlog buffer；dumper 线程通知slave有新的事务t1；binlog buffer 进行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. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 没有收到事务，也就是还没有写入到relay log 之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。 在此情况下，slave会少一个事务的数据。

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

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

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

该参数有两个值：

AFTER_COMMIT（5.6默认值）

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

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

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

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

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

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

图：Without ACK receiving thread

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

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

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

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

4 性能提升

Binlog 互斥锁改进

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

MySQL 5.7对binlog lock进行了以下两方面优化

1.移除了dump thread对binlog的互斥锁

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

5 性能提升组提交

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

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

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

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

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

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

trx1 1…..2trx2 1………….3trx3 1…………………….4trx4 2……………………….5trx5 3…………………………..6trx6 3………………………………7trx7 6………………………………..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可分发

综上所述

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

mysql主从复制和mgr区别？

MySQL主从复制和MySQL Group Replication (简称为mgr) 都是MySQL数据库的高可用性解决方案，但它们之间有以下几点不同：

复制方式不同：主从复制是一种异步复制方式，即主库上的数据变更会异步地传输到从库上，而mgr是一种基于Paxos协议的同步复制方式，即主库上的数据变更会同步地传输到所有的从库上。

数据一致性不同：由于主从复制是异步复制，因此在主库上的数据变更还没有同步到从库上时，从库上的数据可能会与主库上的数据不一致。而mgr是同步复制，因此在主库上的数据变更同步到所有从库之前，所有从库上的数据都是一致的。

配置方式不同：主从复制需要手动配置主库和从库之间的关系，而mgr则可以通过MySQL Shell命令行工具自动配置。

故障恢复方式不同：在主从复制中，如果主库出现故障，需要手动将从库切换为主库。而在mgr中，如果主库出现故障，系统会自动将其中一个从库切换为新的主库。

总之，主从复制和mgr都是MySQL数据库的高可用性解决方案，但它们之间的复制方式、数据一致性、配置方式和故障恢复方式等方面存在一些不同。选择哪种方案取决于具体的业务需求和技术架构。

SQLServer主从数据同步？

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

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

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

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

快照复制

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

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

事务复制

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

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

结果：

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

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

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

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