排查:Primary上的修改无法在Secondary体现 客户端进程在primary上修改成功,但是在Secondary上却无法看到修改结果.这个case假设你的可用性组有同步的健康问题.很多情况下这个情况会在几分钟之后自动解决. 如果几分之后依然看不到,那么可能在同步的工作流上有瓶颈问题.这个瓶颈会因为是不是同步提交的而不同. Commit Mode Possible Bottleneck Explanation Synchronous Commit Primary上长运行事务 seconda…

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

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

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

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 日志数据被刷新到磁盘…

DMV和系统目录视图 这里主要介绍AlwaysON的动态管理视图,可以用来监控和排查你的AG. 在AlwaysOn Dashboard,你可以简单的配置的GUI显示很多可用副本的DMV和可用数据库通过右击各自的表头并且选择你要加入和隐藏的DMV. 更多关于DMV信息查看: AlwaysOn Availability Groups Dynamic Management Views and Functions (Transact-SQL).查看更多AG目录视图查看:AlwaysOn Availabi…

健康模型概述 在成功部署AG之后,跟踪和维护健康状况是很重要的. 1.AG健康模型概述 AG的健康模型是基于策略管理(Policy Based Management PBM)的.如果不熟悉这个特性,可以查看:使用基于策略的管理来管理服务器 PBM的核心是策略,策略有以下部分组成: 1.目标,策略运行在有一组或者一个对象上. 2.条件,条件是bool表达式,指定目标的状态.如果条件false,就会发生错误. 3.归类,归类是对策略的简单归类 一旦你定义了一个策略,PBM会提供引擎来执行这些策略,获…

http://msdn.microsoft.com/en-us/library/azure/dn249504.aspx Tutorial: AlwaysOn Availability Groups in Azure (GUI) 28 out of 55 rated this helpful - Rate this topic Updated: October 23, 2013 Note For the PowerShell-based tutorial of the same scenario,…

使用Powershell监控AlwayOn健康 1.基本命令概述 AlwayOn Dashboard是很有用的查看整体AG健康状况的工具.但是这个工具不是用于7*24监控的.如果应用程序夜间发送严重的问题,Dashboard并不会有任何提示.那么可以使用Powershell命令来获取并通过SQL Agent调用创建告警. 1.1 Dashboard 首先创建一个AG.这个AG被配置为自动故障转移.查看这个AG的dashboard 通过查看AG的状态发现,AG状态不对.而且问题是来自于WSNAVE…

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

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…

AlwaysOn健康诊断日志 为了监控primary可用副本的健康状况,SQL Server资源DLL使用SQL Server2012的过程sp_server_diagnostics. SQL Server resource DLL维护了一个专用的连接到SQL Server实例,通过这个SQL Server实例定期的发送健康诊断信息到SQL Server resource DLL.健康诊断信息与集群中的AG中的failover policy耦合,被用来确定集群是否重启或者故障转移.这个过程是新S…

AlwaysOn等待类型 当排查AlwaysOn延迟,等待统计信息可以在DMV中查看累计的AlwaysOn等待类型. 查看AlwaysOn等待类型 SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE '%hadr%' ORDER BY wait_time_ms DESC 使用一下语句,获取捕获扩展事件,等待类型. CREATE EVENT SESSION [alwayson] ON SERVER ADD EVENT sqlos.wait…

AlwaysOn Ring Buffers 一些AlwaysOn的诊断信息可以从SQL Server ring buffers.或者从sys.dm_os_ring_buffers.ring buffer在SQL Server启动的时候被创建,SQL Server系统为内部诊断记录警告. 通过以下查询获取所有事件记录 SELECT * FROM sys.dm_os_ring_buffers WHERE ring_buffer_type LIKE '%HADR%' 为了让数据更加可控,可以通过日期,…

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在不其确定的…

一:下载git,https://git-scm.com/downloads(若下载速度慢,可下载百度下的)接下来,默认配置,一直next 二:在github上注册账号,并新建一个项目test(英文有点让你 蓝瘦 ,但是有百度) 三:打开git bash开始配置 git config --global user.email xxx@xxx.com git config --global user.name "username" cd ~/.ssh ssh-keygen -C 'xxx@x…

Github上怎么修改别人的项目并且提交给原作者!图文并茂! 写这篇博客的初衷,是因为我的项目Only需要一些朋友一起参与进来,但是很多的Git都不是很熟练,其实版本控制这种东西没有什么难度的,只要稍微掌握以下就好了,如果有兴趣的话也可以到Only这个项目进来 Only:https://github.com/LiuGuiLinAndroid/Only 好的,不多说,直接开车了,我们先简单的找一个项目,比如这个项目,我需要更改他的内容,我们就直接fork这个项目 紧接着你就可以看到这个项目已经被你…

在Java编程中,如何检查文件是否在服务器上被修改了? 以下示例显示如何检查文件是否在服务器上进行了修改. package com.yiibai; import java.net.URL; import java.net.URLConnection; public class FileModificationTime2 { public static void main(String[] argv) throws Exception { URL u = new URL("http://www.y…

排查线上问题常用的几个Linux命令 https://www.cnblogs.com/cjsblog/p/9562380.html top 相当于Windows任务管理器 可以看到,输出结果分两部分,前5行是总览,下面是具体的进程资源占用情况.下面逐行看一下 第1行 top - 18:14:58 up 112 days, 1:35, 1 user, load average: 0.00, 0.10, 0.11 依次表示:当前时间.系统已经运行的时间.当前登录的用户数.系统在过去的1分钟,5分钟,…

小结: 1. 子网掩码.子网IP计算 2. linux centos 修改ip地址细节介绍_LINUX_操作系统_脚本之家 http://www.jb51.net/LINUXjishu/66509.html #一分钟后重启[root@test ~]# shutdown -r 1 #立即重启 现在 [root@test ~]# shutdown -r now [2条命令] 原 192.168.13.101 修改为 192.168.14.101 ifconfig eth0 192.168.3.101…

一.java定位进程 在服务器中终端输入命令:top 可以看到进程ID,为5421的cpu这列100多了. 记下这个数字:5421 二.定位问题进程对应的线程 然后在服务器中终端输入命令:top -Hp 5421 作用是查看里程内部线程资源占用情况.5421为第二步获取到的进程id 可以看到第一行cpu占用特别高,就是它了.记住,此时第一列PID是线程ID:5463 注意这个ID是十进制,但是java线程堆栈是采用是16进制.那么我们转换一下. printf "%x\n" 5463 输…

前言 大多数情况下,我们会在打印日志时定义日志的LOGGER级别,用来控制输出的信息范围. 一方面,过多的输出会影响查看日志的效率,另一方面,过少的日志让问题定位变得困难. 但当线上出现问题时,线上容器通常定义在info级别,发生一些疑难问题时,光靠info级别的日志很难定位问题. 一个典型的场景:在一些需要打印MySQL语句的场景,如果你正在使用MyBatis框架,由于MyBaits中SQL语句是DEBUG级别的信息,通常在线上容器就没法看到. 一个丑陋的解决办法就是在沙箱/预发环境,将log…

前言:   本节是整个系列的重点文章,到现在,读者应该已经对整个高可用架构有一定的了解,知道独立的SQL Server实例和基于群集的SQL Server FCI的区别.上一节已经介绍了如何安装SQL Server Failover Cluster Instance(FCI)及其要求. 本节会深入AlwaysOn 可用组的内容,以演示部署为主线,包括如何启用只读路由和使用AlwaysOn组侦听器.并在最后演示故障转移. 在前面文章中对FCI和AlwaysOn可用组有了一定的平台要求.这里对其进行…

AlwaysOn是一种集合了高可用和灾难恢复两种功能的技术,它支持一个或多个数据库整体的发生故障转移,它实现了一定程度上的负载均衡,减轻了主服务器的压力,是目前最好的一种选择.那么当极端情况发生时,集群大多数节点都挂掉了,数据库所在的主节点Server也挂掉了.即当Windows 集群 Fail 时,如何快速从尚且存活的少数节点中,挑选一个来承接数据库服务. 1:测试目的 Windows Failover Cluster若因故障server节点太多, 会使整个Cluster fail, 此时其他…

利用Dump转储文件获取正式环境程序堆栈状态 服务异常找不到原因时,我们通常通过重新启动服务来尝试解决问题,但是在决定重启之前,请不要立刻重启Windows服务或站点 重启服务会让当前案发现场的内存证据丢失,即便是服务恢复正常了,也无法确认问题发生的原因,利用 Windows Dump 转储文件,可以将正在运行中的服务或站点的堆栈信息保存下来,然后在Visual Studio或WinDbg来查看线上服务的对象信息 Dump转储文件生成 Dump转储文件可以通过 任务管理器 -> 进程 -> 右…

I. 三种比较典型的内存泄漏 一. 闭包引用导致的泄漏 这段代码已经在很多讲解内存泄漏的地方引用了,非常经典,所以拿出来作为第一个例子,以下是泄漏代码: 'use strict'; const express = require('express'); const app = express(); //以下是产生泄漏的代码 let theThing = null; let replaceThing = function () { let leak = theThing; let unused =…

导读:近期有一个业务部门的同学反馈说他负责的C工程在小概率情况下SpringMvc会返回415,通过输出的日志可以确定是SpringMvc找不到content-type这个头了,具体为什么找不到了呢?请听我娓娓道来. 关键词:http 415,SpringMvc,nginx,lua,wireshark,jmeter 问题现象: 近期接到一个同学的反馈说,他负责的C工程在小概率的情况下SpringMvc会返回415,通过输出的日志发现请求头里面并没有content-type了,所以才导致Sprin…

在生产上我们经常会碰到一些不好排查的问题,例如线程安全问题,用最简单的threaddump或者heapdump不好查到问题原因.为了排查这些问题,有时我们会临时加一些日志,比如在一些关键的函数里打印出入参,然后重新打包发布,如果打了日志还是没找到问题,继续加日志,重新打包发布.对于上线流程复杂而且审核比较严的公司,从改代码到上线需要层层的流转,会大大影响问题排查的进度. 这个时候我们可以使用能够在线调试的工具帮助我们查找问题,例如btrace,可以动态的插入代码,极大提高我们查找问题的效率.本文…