《sql.docserver.docalwayson架构及原理》由会员分享，可在线阅读，更多相关《sql.docserver.docalwayson架构及原理（6页珍藏版）》请在金锄头文库上搜索。
1、. .SQL Server AlwaysOnSQL Server AlwaysOn 架构及原理架构及原理SQL Server2012 所支持的 AlwaysOn 技术集中了故障转移群集、 数据库镜像和日志传送三者的优点，但又不一样。故障转移群集的单位是 SQL 实例，数据库镜像和日志传送的单位是单个用户数据库，而 AlwaysOn 支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，那么可用性组中的所有数据组会作为一个整体进展切换。AlwaysOn 底层依然采用 Windows 故障转移群集的机制进展监测和转移，因此也需要先建立 Windows Cluste
2、r， 只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。AlwaysOn 的关键特性：1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。2.一个主效劳器可以最多对应四个辅助效劳器，总数到达五个，而且辅助效劳器支持只读功能。3.辅助效劳器可以独立执行备份和 DBCC 维护命令。通过配置，可以实现客户端的只读请求可以被自动定向到辅助效劳器。4.主效劳器和辅助效劳器之间的数据会被加密和压缩，以提高平安性和网络传输效率。5.支持自动、手动和强制三种故障转移方式。6.有仪表盘用于监控 AlwaysOn 的运行状态。7.可以实现多站点的部署，即主站点和辅助
3、站点可以跨物理网络。. . 可修编-. .AlwaysOnAlwaysOn 的根本架构的根本架构在 Windows MSCS 故障转移群集的根底上部署 AlwaysOn 高可用组，用户可以在群集节点上安装 SQL Server 单机实例， 也可以安装 SQL Server群集实例， AlwaysOn仅要求所有 SQL Server 实例都运行在同一个 MSCS 中， 但 SQL Server 实例本身是不需要群集模式的，这与 SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的 SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本
4、地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。可用性组从 Windows 群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进展故障转移，当然这不包括系统数据库，系统数据库是不能参加高可用性组中的。因为需要借助 Windos 群集实现监控和转移，所以 AlwaysOn 会受到一些限制：一个可用性组中的所有可用性副本必须运行在单一的 Windows 群集上，跨不同Windows 群集的 SQL Server 实例不能配置成一个 AlwaysOn 可用性组。一个可用性组的所有可用性副本必须运行在 Windows 群集的不同节点上。运行在同一个节点上的两个
5、不同实例不能用作同一个可用性组的副本。如果某个可用性副本实例是一个 SQL 群集实例， 那同一个 SQL 群集的其他非活泼节点上安装的任何其他 SQL 实例都不能作为它的辅助副本。一个数据库只能属于一个可用性组。AlwaysOn 最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库PrimaryDatabase，同时这个可用性副本被称为主副本primaryreplica。其余的副本都被称为辅助副本. . 可修编-. .secondaryreplica，辅助副本上的数据库可能是不可访问的，或者是只能承受只读操作取决于可用性组的配置，这些数据库
6、被称为辅助数据库。一但发生故障转移， 任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下列图就显示了一个可用性组中各副本之间的关系。下列图展示了 AlwaysOn 可用性组与 Windows 故障转移群集之间的关系，在这个图中，Windows 的故障转移群集使用到了两个子网，在左边的子网里，有两个节点 ；右边的子网里有三个节点，其中最右边两个节点上创立了一个 SQL Server的群集实例，存放于共享存储；其他三个节点安装的是单机实例，存放于本地存储；一共四个实例组成了一个 AlwaysOn 可用性组，其中一个主副本，其他
7、的都是辅助副本。. . 可修编-. .侦听器侦听器AlwaysOn 创立后，客户端就需要进展连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创立一个侦听器，侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。一个侦听器包括虚拟 IP 地址、虚拟网络名称、端口号三个元素，一旦创立成功，虚拟网络名称会注册到 DNS 中，同时为可用性组资源添加 IP 地址资源和网络名. . 可修编-. .称资源。用户就可以使用此名称来连接到可用性
8、组中。与故障转移群集不同，除了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。SQL Server2012 早期版本的 SQL Server 只有在实例启动的时候地会尝试绑定 IP和端口， 但是 SQL Server2012 却允许在副本实例处于运行状况的时候随时绑定新的 IP 地址、网络名称和端口号。因此可以为随时为为可用性组添加侦听器，而且这个操作会立即生效。当添加了侦听器之后，在 SQL Server 的错误日志中可以看到类似：在虚拟网络名称上停顿和启动侦听器的消息。要注意的是，SQLBrowser 效劳是不支持 Listener 的。这是因为应用程序在使用Listener 的
9、虚拟网络名连接 SQLServer 时，是以一个默认实例的形式进展访问的只有主机名，没有实例名，因此客户端根本就不会去尝试使用 SQLBrowser效劳。各副本间的数据同步各副本间的数据同步AlwaysOn 必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里 AlwaysOn 通过三个步骤来完成：步骤 1：主副本记录发生变化的数据；步骤 2：将记录传输到各个辅助副本；步骤 3:把数据变化操作在辅助副本上执行一遍。具体实现如下：在主副本和辅助副本上，SQL Server 都会启动相应的线程来完成相应的任务。对于一般的 SQL Server 效劳器， 即没有配置高可
10、用性， 会运行 Log Writer 的线程，当发生数据修改事务时， 此线程负责将本次操对应的日志信息记录到日志缓冲区. . 可修编-. .中， 然后再写入到物理日志文件。 但如果配置了 AlwaysOny 主副本的数据库， SQLServer 会为它建立一个叫 Log Scanner 的线程，不连续的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各辅助副本。辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner 所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。 Log Scanner负责传送日志块，不需要等待 Log Writer 完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn 所带来的操作对数据库性能的影响。. . 可修编-
