淮安谁家做网站,单页面优化,全球访问量最大的网站,36 氪 网站如何优化因为篇幅原因#xff0c;AlwaysOn可用性组被拆成了两部分#xff1a;理论部分和实战部分。而实战部分又被拆成了准备工作和AlwaysOn可用性组搭建。 三篇文章各自的链接#xff1a; SQL Server - 高可用与灾难恢复#xff08;HADR#xff09;技术 -- AlwaysOn… 因为篇幅原因AlwaysOn可用性组被拆成了两部分理论部分和实战部分。而实战部分又被拆成了准备工作和AlwaysOn可用性组搭建。 三篇文章各自的链接 SQL Server - 高可用与灾难恢复HADR技术 -- AlwaysOn理论篇 SQL Server - 高可用与灾难恢复HADR技术 -- AlwaysOn实战篇之建立活动目录域、DNS服务器和Windows故障转移群集准备工作 SQL Server - 高可用与灾难恢复HADR技术 -- AlwaysOn实战篇之AlwaysOn可用性组搭建 前言 SQL Server 2012引入了全新的HADR技术 -- AlwaysOn。AlwaysOn可谓是集SQL Server 2012之前各种HADR的优点于一身比如故障转移群集的高可用行日志传送的数据副本可访问镜像技术的高同步和自动页面修复。同时它的可用性组概念又规避了故障转移群集必须是整个实例完全转移的“缺点”。在架构上的可拓展性也是其一大优势。多只读辅助副本来帮助减轻主副本的数据读取负载对于某些大型应用是一大利器。以及可以再与故障转移群集相结合来实现更高层次的高可用也体现了其对于大型应用的支持。 AlwaysOn可用性组的前提条件 1服务器不能是域控制器 2服务器OS需要是Windows Server 2008或以后的版本 3服务器需要是Windows故障转移群集的节点 AlwaysOn可用行组数据库的要求 1只能是用户数据库这点和镜像技术是一样的 2可读写 3多用户模式 4完全恢复模式 5做过完整备份 6不属于其他的可用性组 重要特性 1多用户数据库为可用性单位 2虚拟网络服务器名 3三种故障转移模式 4最多可以有8个辅助服务器SQL SERVER 2012最多4个SQL SERVER 2014最多8个 5主服务器和辅助服务器数据加密和压缩 6自动修复某些类型的数据页面损坏 7辅助服务器数据只读分担一部分主服务器负载 8辅助服务器可以执行备份和DBCC命令 9AlwaysOn专属Dashboard、DMV、Performance Counter和Extended Events支持 与其他高可用与灾难恢复HADR技术对比 SQL Server 2012之前的版本提供的高可用与灾难恢复HADR技术众多但是难有一种是“完美”或者说可以被看成是一种解决方案的。各自都存在一些优缺点。 集群优点是可以故障转移缺点是共享了同一份数据无副本一旦数据出问题就完全不可访问自动故障转移是整个实例级别 日志传送最老的HADR技术依赖于事务日志。优点是一个数据库可以同时有一个或多个数据库副本而且还是可以访问的可以实现读写分离分担主服务器压力缺点是一旦灾难发生会出现短暂的数据丢失。不支持自动故障转移。恢复时间相当长。相当于把副本备份然后还原到当前的生产数据库在承当数据丢失的情况下前提是故障是数据库级别不能是硬件或者实例Windows服务级别。 事务复制这个不是灾难恢复技术只是作为高可用技术的一种。依赖于事务日志。优点是高可用的对象可以细化到表级别也可以把它看成是ETL技术的一种选择用于分发数据到其他的订阅节点是非常好的技术对于实现读写分离也是一个选择。缺点是一旦灾难发生会出现数据丢失而且会给服务器增加负担。和日志传送一样依赖于事务日志注定很多缺点两者都相似。 数据库镜像SQL Server 2005后的HADR技术。优点是可以保证不会出现任何数据丢失也支持故障转移缺点是副本不可访问仅在故障转移时才可访问无法读写分离减轻服务器压力。 AlwaysOn可以说它就是对其他高可用与灾难恢复HADR技术的集大成者吸取了数据库镜像的数据库级别的故障转移日志传送的副本可访问只读特点故障转移集群的多节点和自动故障转移和检测的能力。它不像故障转移集群必须是对整个实例级也不像数据库镜像和日志传送只能对单个数据库AlwaysOn的核心思想是“可用性组”每个可用性组包含的是一个或若干个数据库然后把整个可用性组一起进行故障转移。 《SQL Server 2012实施与管理实战指南》一书中总结了这5种技术的一些特点。 AlwaysOn和Windows群集的关系 AlwaysOn的故障转移特性是基于Windows群集实现的。因为故障侦测和转移也具备了一些Windows群集的特性 1同一可用性组的可用性副本必须处在同一Windows群集内 2同一可用性组的可用性副本必须运行在不同的Windows节点上 3如果某个可用性副本是一个SQL群集实例同一SQL群集的其他非活跃节点上安装的任何其他SQL实例不能作为它的辅助副本 4一个数据库只能属于一个可用性组 使用虚拟网络服务器名和Listener由Listener来决定是否Failover Listener决定把客户端请求是否重定向到其他的辅助副本上。它本身是不支持SQL Browser的因为使用虚拟网络服务器名本身就是使用默认实例的一种用法。既然是使用默认实例那也就不存在命令实例和其端口号一说了。那SQL Browser也就没用了。如果本身使用虚拟网络服务器名每个副本都使用默认实例。 架构流程图 可用性模式 异步提交模式事务被提交前无需先等待某个辅助副本将事务日志固化。这种模式下一般辅助数据库都是出于SYNCHRONIZING状态。这种模式一般适用于那些主副本和辅助副本物理距离远的情况。 同步提交模式事务被提交前需要先等待某个辅助副本将事务日志固化。这种模式下辅助数据库会出于SYNCHRONIZED状态。 AlwaysOn事务提交流程 可用性副本连接状态 DISCONNECTED: 主副本和辅助副本间互相发送ping。默认超时时间为10秒。最低为5秒。建议10秒甚至更长避免SQL Server过于繁忙。 可用性模式对事务复制的影响 事务复制的Log Reader不会去处理那些尚未复制到辅助副本的日志记录。因为如果事务复制处理了这些日志就会造成订阅服务器的记录比辅助服务器的数据新鲜度要新。这时一旦发生Failover辅助副本就会被自动切换成主副本这样就会出现辅助副本的数据比订阅服务器的记录旧。这种情况是不允许。 故障转移形式 AlwaysOn通过加载了一个名为hadrres的DLL。因为AlwaysOn其实也是依托Windows群集服务所以其实也是由RHS.exe进程来加载这个DLL。从名字可以看出是High Availibility Disaster Recovery Resource的简称。也就是其实这条进程是用于控制可用性组资源的上下线的。 AlwaysOn和SQL Server的群集其实是一样通过调用存储过程sp_server_dianostics来检查群集的状态。调用方法存在hadrres.dll中。hadrres.dll开启一条线程连接到SQL Server并且一直保持不断调用这个存储过程来获取SQL Server的状态信息。返回结果和AlwaysOn可用性组的FailureConditionLevel配置进行对比以决定是否切换到辅助副本上。 HealthCheckTimeout间隔为30000毫秒。一个实例只会运行一次sp_server_dianostics不管有多少个可用性组。多个可用性组将选择最小的间隔设置值值除以3作为生效的间隔。sp_server_dianostics只是检查实例的状态而不是检查数据库的状态。 故障恢复模式自动手动和强制 AlwaysOn是否触发故障转移是由故障恢复模式和可用性模式决定的 自动故障转移 1主副本和辅助副本连接状态置为DISCONNECTED并且断开所有客户端连接 2等待辅助副本把日志操作前滚redo完毕 3辅助副本切换为主副本此时如果没有任何可用辅助副本主副本的可用性组状态就是NOTSYNCHRONIZED 4原来的主副本变成可用后变成辅助副本同步现有主副本后面生成的日志记录 手动故障转移 当主副本和辅助副本处于SYNCHRONIZED状态时可以执行手动故障转移。此时不会出现数据丢失。 强制故障转移 当主副本停止辅助副本进入“RESOLVING”角色。此时RESOLVING角色既不是主副本也不是辅助副本。如果执行强制故障转移把辅助副本转成主副本可能出现数据丢失。而且其他副本在执行完强制故障转移之后可能需要重新配置可用性组因为强制故障转移形式导致新的主副本不能确定与其他副本间的数据一致性。 手动故障转移的途径 1T-SQL语句 2SSMS UI界面 3) PowerShell 多子网可用性组的故障转移 客户端应用程序使用MultiSubsetFailover来支持多子网可用性组的故障转移配置Listener Split Brain大脑分裂 大脑分裂是指发生故障转移时存在新的主副本上线和旧的主副本仍然在线存在的这种同时出现两个主副本的情况。为了避免这种情况AlwaysOn可用性组有一个叫LeaseTimeout意思是如果主副本在LeaseTimeout之前没有收到Windows群集服务的消息就会自动终止SQL Server的运行。因为其实主动权在Windows群及服务手中。它认定故障转移发生并转向另外的新的主副本从而不发生通信消息给旧的主副本。LeaseTimeout很快就到这样旧的主副本就会终止自己的服务。从而避免大脑分裂。 只读辅助数据库 辅助副本上的数据库是可以被配置成只读然后通过AlwaysOn的只读路由功能将只读请求重定向到只读辅助副本上从而已经分担主副本的工作负载。鉴于SQL Server允许最多可以有6个辅助副本也就是意味着我们最多可以有6个只读辅助数据库来分担读的压力。当然越多的辅助副本数据滞后的可能性就越大因为每个辅助副本的负载都不尽相同与其增加多副本倒不如把资源集中在两个或者三个副本上。建议不要超过4个副本。把主副本和辅助副本都放置在同一局域网同一台交换机相连配置主副本和辅助副本的可用性模式为异步提交模式。虽然这样数据滞后的发生可能性会增大也就是数据出现延迟。这里其实是有两种方案。一种是多个辅助副本每个副本包括主副本和辅助副本的硬件配置相同参考了携程的架构设计而且把辅助副本的数量保持在2个内。另外一种是主副本和辅助副本的硬件配置不相同根据其角色的特征选定硬件这种可以参考携程的数据库架构。前者的好处是可以把可用性模式设置为同步提交模式让可用性数据库的数据延迟降至最低。这是基于相同的硬件和处在局域网高速网络的条件考虑下做出的判断。加上限定了尽可能少的辅助副本来避免过多副本造成的数据滞后影响。理论上是可以。不过即便如此数据的延迟也肯定还是会出现。最重要的一点也是缺点就是硬件代码太高了。容易造成硬件浪费。如果不是大型应用而且对数据实时性的要求又很高可以考虑这套做法也就是把资源都尽量集中在两个或者三个机器或者群集上。第二种做法是主副本使用SAN存储结构加上SQL Failover群集多个辅助副本使用SSD存储结构保证数据读取和写入的速度可用性模式配置成异步最后加上负载均衡硬件机器来分散数据读取请求。可以参考《数据库技术与应用专场-03AlwaysOn技术在携程核心数据库的应用》。对于整个架构我唯一处在的疑问在于配置成异步提交模式以为着会出现数据延迟。而携程的做法是通过一张代表可用性资源组时间戳的表来代表数据的新鲜度然后应用程序在读取辅助副本数据的时候检查这张表以判断是否超过数据延迟的容许程度以决定是否把数据读取访问返回给主副本。如果可以有效地控制好数据延迟的上限那也可以接受。因为这样假设一旦出现N个线程排队等待修改同一行数据的情况这个时候交易事务提交后到了主副本中检查数据行的数据版本提交表单中带有的来自于辅助副本上和数据库中的当前行是否一致不一致则说明数据过期这个时候事务失败。其实也就是要结合应用程序和数据库技术最后需要承当起一定的代价。我是这么看的。 SQL SERVER实现只读辅助数据库的重导向依靠的是 1它的“只读路由”功能 2辅助数据库配置为只读模式 3应用程序发起连接时指定了ApplicationIntent为READONLY。 ApplicationIntent 目前支持ApplicationIntent的数据库驱动有SQLNCLI11 ODBC和OLEDB、.NET FRAMEWORK的SQLClient和JDBC for SQL Server 4.0 只读路由 SQL Server的只读路由功能会帮助你分流一部分的读取请求去到辅助数据库上。但是需要说明在多个辅助数据库的情况下到底最后面会去到哪个辅助数据库上是会收到路由配置和副本的状态影响的。所以说本身SQL Server自己是没有办法实现负载均衡。要实现比较真实的负载均衡你需要依靠专业的负载均衡机器来帮助实现通过直接访问实例名或者通过应用程序层面编写一套自己的算法来分摊负载。 主副本的连接访问类型ALL -- 默认允许读写READ_WRITE -- 不允许连接字符串带有Application_Intent Readonly 辅助副本的连接访问类型ALL -- 只是为了满足那些无法使用Application_Intent的客户端其实无论如何只要尝试修改数据都会报错READ_ONLY -- 为了支持只读路由自动分流数据读取NONE -- 不接受任何访问请求 只读路由的工作前提是Application_Intent READONLY和使用Listener来连接可用性组。 辅助数据库上的潜在性能问题 阻塞和死锁 由于辅助数据库需要和主数据库进行数据同步写入操作是几乎可能不间断的发生而又因为可能同时也是一个只读的数据库所以锁的冲突、阻塞和死锁是潜在的问题。阻塞问题在AlwaysOn是有行版本控制来解决的。所有对辅助数据库的数据查询都运行在快照隔离级别下。即便如此查询还是会申请架构共享锁Sch-S所以还是存在和DDL语句相冲突。死锁也是可能发生的不过AlwaysOn的事务日志重写是优先级别高而不可能被选为牺牲者。 行版本控制和临时统计信息带来的Tempdb的空间增长 行版本控制和临时统计信息可能带来的Tempdb的空间增长。需要对Tempdb的合理配置比如Growth和Maximum Size的配置数据文件数量的配置文件location的选择。 监控AlwaysOn可用性组的运行状态 1系统视图和动态管理视图DMV 实例级别的 sys.dm_hadr_cluster sys.dm_hadr_cluster_members sys.dm_hadr_cluster_networks sys.dm_hadr_instance_node_map sys.dm_hadr_name_id_map 可用性组级别 sys.availability_groups sys.availability_groups_cluster sys.dm_hadr_availability_groups_states 可用性副本级别 sys.availability_replicas sys.availability_read_only_routing_lists sys.dm_hadr_availability_replica_cluster_nodes sys.dm_hadr_availability_replica_cluster_states sys.dm_hadr_availability_replica_states sys.fn_hadr_backup_is_preferred_replica 可用性数据库级别 sys.availability_databases_cluster sys.databases sys.dm_hadr_auto_page_repair sys.dm_hadr_database_replica_states sys.dm_hadr_database_replica_cluster_states 与可用性组的Listener相关 sys.availability_group_listener_ip_addresses sys.availability_group_listeners sys.dm_tcp_listener_states 2性能计数器 SQL Server:Availability Replica SQL Server:Database Replica 3Dashboard 4) AlwaysOn_health会话Extended Events 5SQLDIAG拓展事件日志 理论篇到此就结束了。接下来的实战篇因为篇幅原因被拆成了两部分1活动目录域、DNS服务器和Windows故障转移群集2AlwaysOn可用性组搭建 参考 《SQL Server 2012实施与管理实战指南》 AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups SQL Server 2012 - High Availability - AlwaysOn in Real-life Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server) Windows Server Failover Clustering (WSFC) with SQL Server SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns AlwaysOn 可用性组概述 (SQL Server) 转载于:https://www.cnblogs.com/jenrrychen/p/5199488.html
