lienlien
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、然后我们点击"更新目标"，则被删除的数据会由发布端同步到订阅端。如：
我们再次进行验证订阅，显示已经通过订阅。Echa攻城狮
现在信息科技的高速发展离不开数据库，在国内使用最多的数据库主要有：SQL Server、MySQL、Oracle ，其实不管是哪种数据库，在数据量及并发量达到一定程度后，单一数据库节点都会存在性能降低的现象。为了避免数据库瓶颈影响性能，就需要对数据库做分布式集群部署，而分布式集群部署又要依懒数据的主从同步。
什么是数据库主从同步？
数据库的主从同步架构是当下最为常见的一种数据库架构，通过主从同步可以使数据从一个数据库节点复制到另一个数据库节点，这样才能保障数据库分式布集群部署时数据是同步统一的。
在主从同步数据时，一台服务器会充当主服务器（Master），其它服务器便会充当从服务器（Slave），一般是一主多从模式。
数据库主从同步的目的
数据库主从同步的主要作用有以下几点：
便于架构扩展，降低单节点服务器压力；
读写分离：将数据库读操作与写操作分离至不同服务器，使得数据库并发性更好；
数据热备：将主库数据同步到从库数据库后，一旦主库服务器发生故障可以切换到从库服务器，保障了业务稳定。
数据库主从同步带来的一些问题
上面提到的都是数据库主从同步的优点，但在实际实施过程中，数据库主从同步也会带来一些问题，最为常见的就是：主库与从库之间的同步存在延迟！
这种同步延迟会导致：明明向主库写入了数据，但在一段时间内无法从从库中查询到，看上去数据存在不统一，也就无法保证主从架构下的强一致性。
如何规避数据库主从同步的延迟？
可以这样说，数据库主从同步操作带来的延迟是不可避免的，但我们可以通过一些方案来尽可能降低延迟时间，比如说：
将主库和从库放置在同一网络节点，避免不同网关带来的通信开销；
主从节点同步时统一走内网IP通讯，不要走公网IP；
如果主从同步的延迟影响了业务，建议在数据库上层加个Redis来缓冲数据。
网络圈
延时只能逼近，不能解决，先说说你的问题场景，究竟对延时需要多高的要求。
梦虚竹林
你需要在主机写入之后，保证在备机一定能够读取到已经写入的数据，也就是说，你需要主从架构下的强一致性。
主机与备机之间的物理延迟是不可控的，也是无法避免的。但是如果仅仅需要满足这种强一致性，是相对简单的事：只需要在主机写入时，确认更新已经同步到备机之后，再返回写操作成功即可。
