14:25分左右,某数据库主副本服务器崩溃报错,在数据库无法接收SQL语句进行调整的情况下重启了主副本服务器. 由于服务器重启时间会比较长,为了保证主副本服务器重启期间数据库能正常进行写入,强制将主库切换到辅助服务器.并通知连接字符串中不能自动切换的部分应用的数据库直接配置到新的主副本服务器. 而由于咱们AlwaysOn的同步模式是异步模式,原本应该承担只读路由的新只读辅助副本无法同步新主副本的数据,意味着AlwaysOn配置失效,进而导致使用只读数据库连接的大部分应用不可用. 整个Alwasy

最近帮客户实施的基于SQL Server AlwaysOn跨机房切换项目 最近一个来自重庆的客户找到走起君,客户的业务是做移动互联网支付,是微信支付收单渠道合作伙伴,数据库里存储的是支付流水和交易流水. 由于客户那边没有DBA,所以找到走起君商量一个数据库服务器搬迁项目. 项目背景 客户需要把在10楼的服务器全部搬到15楼,而且需要在有限的停机时间之内,客户使用的数据库是SQL Server2008R2,Windows2008R2 客户的两个重要要求 1.总停机时间少于10分钟 2.数据不能有任

SQL Server 2012 读写分离设置 - AlsoIn 时间 2014-07-21 17:38:00  博客园-所有随笔区 原文  http://www.cnblogs.com/also/p/3858887.html 主题 SQL ServerSQL 引用: http://technet.microsoft.com/zh-cn/library/jj161766.aspx 微软新一代数据库产品SQL Server 2012已经面世一段时间了,不管从功能还是性能上讲,较之其早期产品都有了很大

基于Windows Server 2008 R2的WSFC实现SQL Server 2012高可用性组(AlwaysOn Group) 2012年5月 微软新一代数据库产品SQL Server 2012已经面世一段时间了,不管从功能还是性能上讲,较之其早期产品都有了很大提升.特别是其引入高可用性组(AlwaysOn Group, AG)这一概念和功能,大大增强和提高了SQL Server的可用性,在之前的镜像数据库的基础上有了质的变化. SQL Server 2012高可用性组在实现过程中较之早

原文转至:http://www.tuicool.com/articles/a6rmiam/ 引用: http://technet.microsoft.com/zh-cn/library/jj161766.aspx 微软新一代数据库产品SQL Server 2012已经面世一段时间了,不管从功能还是性能上讲,较之其早期产品都有了很大提升.特别是其引入高可用性组(AlwaysOn Group, AG)这一概念和功能,大大增强和提高了SQL Server的可用性,在之前的镜像数据库的基础上有了质的变化

AG排查和监控指南 1. 排查场景 如下表包含了常用排查的场景.根据被分为几个场景类型,比如Configuration,client connectivity,failover和performance. Scenario 笔记 Scenario Type Description Troubleshoot AlwaysOn Availability Groups Configuration (SQL Server) 排查:AG配置 Configuration 提供了一些典型的配置AG实例发生问题的

监控AG性能 AG的性能的性能方面,在关键任务数据库上进行语句级维护性能是很重要的.理解AG如何传输日志到secondary副本对评估RTO和RPO,表明AG是否性能不好. 1. 数据同步步骤 为了评估是否有性能问题,首先需要理解同步过程.性能问题可能出现在同步过程的任何一个环节,瓶颈的定位可以让你深入的理解问题.以下图标演示了数据通过过程: Sequence Step Description Comments Useful Metrics 1 Log Generation 日志数据被刷新到磁盘

排查AG配置 本文主要用来帮助排查在AG配置时出现的问题,包括,AG功能被禁用,账号配置不正确,数据库镜像endpoint不存在,endpoint不能访问. Section Description AlwaysOn Availability Groups Is Not Enabled 如果实例没有启动AG特性,实例就不支持任何AG相关的功能 Accounts 在SQL Server在运行的情况下,正确的账号配置 Endpoints 诊断关于实例的镜像endpoint问题. System name

CLUSTER.LOG(AG) 作为故障转移资源,在SQL Server和windows故障转移集群服务的资源DLL(hadrres.dll)之间有额外的内部交流,DLL无法被SQL Server监控.WSFC log,CLUSTER.LOG可以诊断WSFC集群或者SQL Server Resource DLL的问题. 以下演示了SQL Server和windows集群管理的关系.windows集群管理用来初始化AG资源创建,释放或者状态修改. 1.生产集群日志 有2个方式生产集群日志: 1.在

AG扩展事件 SQL Server 2012定义了一些关于AlwaysOn的扩展事件.你可以监控这些扩展事件来帮助诊断AG的根本问题.你也可以使用以下语句查看扩展事件: SELECT * FROM sys.dm_xe_objects WHERE name LIKE '%hadr%' 1.AlwaysOn健康(AlwaysOn_health)会话 AlwaysOn_health扩展会话当你在创建AG并捕获AlwaysOn相关事件的子集.这个会话被配置为有用的,方便的工具来帮助你开启调试AG.创建A

Windows cluster要求同一个cluster中的所有windows版本都是相同的,这样就出现一个问题,当我们要将对windows进行升级时,(例如从windows 2008 R2升级到windows 2012)不得不搭建一套新的windows cluster.你可以选择使用新的硬件搭建,或者将现有windows cluster中的节点一台一台的evict掉,重装/升级系统后加入到新的windows cluster中.具体的cluster升级方案我就不在这里讨论.马上进入主题: SQL

最近搭建了一套SQLServer2016 AlwaysOn AG. (后记:经实际测试,使用SQLServer2012 也同样可以在Winserver2016上搭建基于工作组的AlwaysOn AG,其实基于工作组的AG仅仅只是WindowsServer2016的WSFC新功能.) 笔者是采用修改各节点的hosts文件,以及修改计算机名的dns后缀,来避免需要另外一台DNS服务器. 上面128,129,130三个IP属于AlwaysOn的三个节点服务器 IP100属于可用性组侦听器IP IP15

排查:AG超过RTO 自动故障转移或者手动转移之后,没有数据都是,你可能会发现切换时间超过了你的RTO.或者当你评估切换时间同步提交secondary副本,发现超过了你的RTO. 1. 通常原因 通常引起故障转移超过RTO的原因: 1.报表负荷堵塞了Redo线程. 2.因为资源争用,Redo线程被落下. 2. 报表负荷堵塞了Redo线程 Redo线程在secondary副本被一个只读长运行语句堵塞. 原因: 在secondary副本,只读查询获得Sch-s锁,这些sch-s锁会堵塞redo线程获

排查:AG超过RPO 在异步提交的secondary上执行了切换,你可能会发现数据的丢失大于RPO,或者在计算可以忍受的数据都是超过了RPO. 1.通常原因 1.网络延迟太高,网络吞吐量太低,导致Primary的日志堆积 2.磁盘IO瓶颈导致LOG固化速度降低 2. 网络延迟太高,网络吞吐量太低,导致Primary的日志堆积 很多超过RPO的原因是日志发送到secondary副本不够快. 原因: Primary副本在日志发送启动了流量控制,因为日志发送超过了最大运行的非通知信息的量.直到这些信息

SQL Server错误日志(AG) SQL Server错误日志会记录影响AG的时间,比如: 1.和Windows故障转移集群交互 2.可用副本的状态 3.可用数据的状态 4.AG endpoint的状态 5.AG Listener的状态 6.SQL Server resource DLL和SQL Server实例的租用状态 7.AG的错误事件 出现以下状态就需要检查错误日志: 1.无法连接到可用性数据库 2.非预料的AG故障转移 3.AG的Resolving状态不可预期 4.AG在不其确定的

从0开始搭建SQL Server AlwaysOn 第一篇(配置域控) 第一篇http://www.cnblogs.com/lyhabc/p/4678330.html第二篇http://www.cnblogs.com/lyhabc/p/4682028.html第三篇http://www.cnblogs.com/lyhabc/p/4682986.html第四篇http://www.cnblogs.com/lyhabc/p/6136227.html AlwaysOn是SQL Server2012推出

从0开始搭建SQL Server AlwaysOn 第三篇(配置AlwaysOn) 第一篇http://www.cnblogs.com/lyhabc/p/4678330.html第二篇http://www.cnblogs.com/lyhabc/p/4682028.html第三篇http://www.cnblogs.com/lyhabc/p/4682986.html第四篇http://www.cnblogs.com/lyhabc/p/6136227.html 这一篇是从0开始搭建SQL Serve

从0开始搭建SQL Server AlwaysOn 第四篇(配置异地机房节点) 第一篇http://www.cnblogs.com/lyhabc/p/4678330.html第二篇http://www.cnblogs.com/lyhabc/p/4682028.html第三篇http://www.cnblogs.com/lyhabc/p/4682986.html第四篇http://www.cnblogs.com/lyhabc/p/6136227.html 这一篇是从0开始搭建SQL Server

原文地址: http://www.cnblogs.com/lyhabc/p/4682986.html 这一篇是从0开始搭建SQL Server AlwaysOn 的第三篇,这一篇才真正开始搭建AlwaysOn,前两篇是为搭建AlwaysOn 做准备的 步骤 这一篇依然使用step by step的方式介绍怎麽搭建AlwaysOn 请先使用本地用户Administrator登录这两个集群节点并执行下面的操作,先不要用域用户DCADMIN登录 1.两个集群节点都需先安装.NET Framework

健康模型扩展 第一部分已经介绍了AlwayOn健康模型的概述.现在是创建一个自己的PBM策略,然后设置为制定的归类.创建这些策略,创建之后修改一下配置,dashboard就会自动评估这些策略. 场景,你有一个异步副本,当被primary落下太多的时候想要在dashboard上显示.一下是创建策略放入健康模型的过程. 1.定义条件 连接到SSMS,打开到条件,右击新建. 设置条件名,然后选择相应的方面.方面是逻辑属性的集合,我们使用这些属性来构成bool表达式这样来定义条件.AlwayOn相关的方