SQL数据库集群（Always On）

数据库集群是一种将多个数据库服务器连接在一起，以提高性能、可用性和可扩展性的技术。

什么是数据库集群？

1. 基本概念

数据库集群是由多个数据库实例（服务器）组成的，它们通常共享数据并协同处理请求。集群通过分散不同的任务和负载来提高整体性能和容错能力。

2. 高可用性

• 故障转移：当集群中的某个数据库服务器出现故障时，其他服务器会自动接管其工作，确保系统的持续可用性。这样可以避免单点故障。
• 冗余：通过在集群中维护多个副本，数据不会因为某个实例的宕机而丢失。

3. 负载均衡

• 请求分发：数据库集群能够将客户端的请求均匀地分发到多个数据库实例，从而避免服务器过载。
• 资源利用：通过充分利用集群中所有服务器的计算和存储资源，提高了整体系统的吞吐量。

4. 扩展性

• 横向扩展：用户可以通过增加更多的数据库服务器来扩展集群的能力，从而应对数据增长和流量增加的需求。
• 灵活性：不同的应用可以根据需要选择合适的集群架构，支持多种不同的数据存储和处理需求。

5. 架构类型

数据库集群有几种不同的架构，常见的有：

• 主从复制架构：

• 主节点（Master）：负责处理所有写请求。
• 从节点（Slave）：负责从主节点复制数据，处理读取请求。
• 这种架构通常用于提高读取性能，主节点可以在负载较高时将读取请求分发给从节点。

• 共享存储架构：

• 所有节点都可以访问一个共享的存储设备。
• 在这种架构中，数据在存储上是共享的，不同服务器可以直接访问同一数据。

• 无共享架构（Sharding）：

• 数据根据某种规则分散存储在不同的服务器上。
• 这种架构能够水平扩展，适合大型应用。

6. 数据库集群的优缺点

• 优点：

• 高可用性和冗余：能够提供更好的容错能力。
• 性能提升：通过负载均衡和并行处理提高性能。
• 灵活的扩展性：可以根据需求动态调整集群规模。

• 缺点：

• 复杂性：集群配置和管理相对复杂，需要有专业的技术支持。
• 成本：维护多个实例需要额外的硬件和软件成本。
• 数据一致性：在多个实例中保持数据一致性可能会带来挑战，尤其在写操作频繁的情况下。

7. 应用场景

• 大型网站和应用：例如电子商务、社交媒体等平台，通常需要处理高流量和高并发请求。
• 数据分析：需要同时处理大量数据查询和报表生成的场景。
• 高可用性要求的系统：金融、医疗等领域中，数据不可丢失且需要随时可用的系统。

什么是发布和订阅？

发布和订阅属于sqlserver的复制技术，引用官网的解释：

复制是一组技术，它将数据和数据库对象从一个数据库复制和分发到另一个数据库，然后在数据库之间进行同步以保持一致性。

官网说明： https://learn.microsoft.com/zh-cn/sql/relational-databases/replication/sql-server-replication?view=sql-server-ver15发布订阅可以做什么？

正如上面所说的，发布订阅可以让你在不同的数据库中交换数据。那么具体的应用场景呢？

下面我总结了几个：

数据库读写分离：

通过对一个主库的进行“事务复制”，我们可以将每次主库的更新都同步到只读库上，从而达到读写分离的效果，进而提高系统性能。

数据库高可用方案：能将主库的更改实时同步到其他库中

与其他系统进行数据对接：

在与第三方公司做对接时，可以直接将数据库中的指定表/指定列，甚至指定行的数据同步更新到对方的数据库里面，这样就减少了开发量。

Alwayson介绍

整库同步的技术

AlwaysON是一种整库同步的技术，所有的成员服务器都维护一套相同的数据库副本。当主副本上的数据发生变化时，数据会实时同步到辅助副本上。这点与数据库镜像非常类似。

AlwaysOn是SQL Server 2012提供的全新综合、灵活、高效经济的高可用性和灾难恢复解决方案。它整合了镜像和群集的功能，基于Os 故障

转移群集(Windows Server Fail0ver cluster)，通过在同一个WSFC的不同Node上，安装独立的SQL Server实例，定义AlwaysOn Group，

个数据库最多可以部署4个镜像。当热备机出现故障时，可以手工或自动实现故障转移，交换主辅数据库的角色,

AlwaysOn的亮点在于镜像可读。对于OLTP应用，可以将读操作集中的报表等操作转移到Read-Only的辅助库上，极大地减少Primary DB的0、CPU等资源占用。由于辅助库是独立的SQL实例，因此创建临时表等TempDB操作不受影响。

Docker部署Alwayson参考链接

 https://blog.csdn.net/weixin_43053507/article/details/137034818

 https://blog.csdn.net/qianglei6077/article/details/107055554

怎么做发布订阅？

使用发布订阅实现读写分离

在这个读写分离下，我们要求有一个主数据库，一个只读数据库。对于主数据库的更新，只读数据库要在尽可能少延迟的情况下同步更改(基于事务发布的延迟也就1-5秒)。

准备数据服务器1 A数据库 上面准备好数据库test以及一张表Student，

服务器2 B数据库 上新建一个test数据库就可以了。

新建发布

创建如下（手动创建一样）

登录后复制

CREATE DATABASE Test --创建的数据库名称

USE Test --使用库

Go

--创建表
CREATE TABLE Student
(
Id INT PRIMARY KEY IDENTITY, -- 主键
StuName NVARCHAR(50),--姓名
Age INT --年龄
)

Go

--向表中插入数据
INSERT INTO Student VALUES('张三',18)
INSERT INTO Student VALUES('李四',20)
INSERT INTO Student VALUES('王五',22)

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.

开始之前先避个坑

第二种开启代理方法

代理没启动发布后会有错误提示

进入正题先在A数据库发布

第一次发布都会有以下步骤，一直下一步就好

这里我们选刚刚新建的数据库

这里我们选事务发布

1. 快照发布:                                  

发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。

快照发布是完全按照数据和数据库对象出现时的状态来复制和分发它们的过程[2]。首先在某一时刻将发布数据库进行快照后产生镜像文件，然后在约定的时刻或时间间隔内由分发代理程序将文件复制到订阅数据库。订阅服务器复制的内容是发布数据库某一时刻的状态。

快照方式不实时进行数据同步，而是每隔一个时段或在某一个时间点进行数据库复制，同步方式为单向同步。

优点是数据复制方式稳定，不必监视对数据的更新。由于是将数据库复制到订阅服务器，所以在大数据量的同步场景下存在以下缺点：占用网络带宽较大、数据同步周期较长。快照方式适用于以下场景：

（1）主库数据量小、更新不频繁。

（2）主从库接受同步延迟。快照方式由于复制数据量大导致延迟较高，可以利用读写较少的时间（如深夜）进行快照复制，将影响范围缩减至最低。 

2.事务发布:

在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。

事务发布是将发布服务器的初始快照将复制到订阅服务器。订阅服务器接收到初始数据后，代理服务会连续监测数据变化，当发布服务器上发生数据修改时，会将这些新增的事务传递给日志代理，然后日志代理通知订阅服务器，订阅服务器进行新增事务的执行。

主从服务器之间通过新增事务复制的方式进行主从同步，发布数据库上增删改等操作的事务日志会在短时间内复制到订阅数据库。

相对快照复制，事务复制优点是复制内容小、数据传递快，所以从库更新延迟小，对大数据量的同步有可靠保证。缺点是如果主库进行读写操作频繁，则同步过程中会对服务器性能造成影响。由于发布和订阅服务之间是实时进行事务传递，所以要保证两者之间相互连接的网络稳定可靠。

这种同步方式适用于以下应用场景：

（1）要求主从库同步延迟小。因为复制的内容是数据库更改的增量，且事务日志内容较小，所以可以在较短的时间实现同步。

（2）主库频繁进行DML操作（增加、删除、修改）。如果采用快照方式同步，则同步时延过高，不能做出及时响应。

（3）数据同步方式为单向。同步的方向是由发布同步至订阅服务器，订阅服务器上的数据库为只读状态。但如果订阅数据库上产生更改，则不会将事务回传至发布服务器。 

使用事务发布方式实现数据同步（Data synchronization through transaction publishing）:

1.SQL Server中要进行数据同步需要满足以下条件：

2.被同步的数据表需要有主键，如果没有主键则会增加一个int类型的自增列id（增量为1）;

3.SQL Server代理服务必须启动;

4.在进行SQL Server注册时，发布服务器和订阅服务器必须使用计算机名称，不能使用IP地址或别名注册。 

3. 对等发布:

对等发布支持多主复制。发布服务器将事务流式传输到拓扑中的所有对等方。所有对等节点可以读取和写入更改，且所有更改将传播到拓扑中的所有节点。

4. 合并发布:

在订阅服务器收到已发布数据的初始快照后，发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Compact Edition 只能订阅合并发布。

他们的限制如下：

1、快照复制和事务复制是单向的(2005及以后的版本中加入了订阅端可更新的事务复制)。

2、合并复制是双向的。

3、快照复制对表结构没有要求。

4、事务复制要求表有主键。

5、合并复制要求表有 rowguid 列。

到这里，发布就已经成功了！！！去看一下

新建订阅

直接在主服务器上的发布上右键->新建订阅

注意：这里我们使用服务器2的的计算机名字，使用IP的话会报错(查看计算机名 win键 + R 输入cmd，在小黑框里输入hostname即可)

订阅成功

可以看到数据已经同步

再添一条，看效果

原创作者: zhouwenhao 转载于: https://blog.51cto.com/zhouwenhao/11670023