万利娱乐


万利娱乐 万利娱乐李红艳,我问你一件事,你是不是喜欢王博?玟单刀直入。
万利娱乐中午的时候见到了老潘,我又跟老潘了解了些情况,开场子的是什么人,有什么背景,还有老潘和看场子的、放水的都是什么关系等。万利娱乐但是,辛茹的语气显然告诉他,她不是那么想的。万利娱乐老婆盯着我看了半天,说“老公,你脸小,长的真小气~”我白了她一眼说:“你脸大,不止大气,简直是阔气!!”@捧腹网 万利娱乐某年的秋天,我依然不停地向前爬着,爬着,但脚步越来越缓,我累了,真累了这时,天空飞来一只美丽的蝴蝶正向我招手,定睛一看,这不是久违的毛毛虫姐姐么。金色的阳光下,挥舞着彩色的翅膀,比她的蝴蝶爸妈当年还要漂亮。多年不见,她已经蜕变成一只翩翩起舞,婀娜多姿的蝴蝶。她向我描述着这些年她飞越过的名山大川,对了,还有那棵我们曾今约好同往的红果树此时蚯蚓弟弟也探出了脑袋,羡慕的听着,在他的旁边还多了一只可爱的小蚯蚓。
万利娱乐更听不到朗朗笑语
万利娱乐一个新手去收高利贷,他把借条拿出来奸笑着说:“白纸黑字明明白白地写着你欠我老板100万!难道你想赖帐?!”  人家表示确实没有那么多钱,他威胁道:“哼哼!别怪我没提醒你!明天再交不出钱,你的房子就像它一样。”  他掏出打火机就把借条烧了……

皇冠足球比分

大发论坛时时彩平台尊龙娱乐是黑网吗海天国际娱乐城注册送钱凯发娱乐亚美国际娱乐城 金龙国际 www.am8.com 亚洲城娱乐 老k国际娱乐城 666k8.com 金威国际娱乐城 名人国际娱乐城 ag娱乐平台 V博娱乐城 战神赌博娱乐城澳门明珠国际线上娱乐神州棋牌明m88娱乐918博【注册送钱e8889.com】当旺娱乐城博彩太阳娱乐城注册送钱e8889.com捕鱼退现金的游戏瑞博国际娱乐城白金会88娱乐场博彩论坛北京赛车论坛态度如何呀?

Fanr

  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理
  337 Posts :: 0 Stories :: 172 Comments :: 0 Trackbacks

公告

监控AG性能

AG的性能的性能方面,在关键任务数据库上进行语句级维护性能是很重要的。理解AG如何传输日志到secondary副本对评估RTORPO,表明AG是否性能不好。

1. 数据同步步骤

为了评估是否有性能问题,首先需要理解同步过程。性能问题可能出现在同步过程的任何一个环节,瓶颈的定位可以让你深入的理解问题。以下图标演示了数据通过过程:

 

Sequence

Step Description

Comments

Useful Metrics

1

Log Generation

日志数据被刷新到磁盘。日志必须被复制到secondary副本。日志记录进入到发送队列.

SQL Server:Database > Log bytes flushed\sec

2

Capture

每个数据库的日志被获取并且发送到相关的partner队列,每个数据库副本都有一个队列。在可用组在连接的情况下,并且数据移动并没有被挂起,获取进程持续运行,并且数据库副本显示要不是同步的,要不是正在同步,如果获取进程不能及时扫描并把消息放入队列,日志发送队列就会筑高。

SQL Server:Availability Replica > Bytes Sent to Replica\sec, which is an aggregation of the sum of all database messages queued for that availability replica.

log_send_queue_size (KB) and log_bytes_send_rate(KB/sec) on the primary replica.

3

Send

数据库副本中的消息出队列,并且发送到相关的secondary副本.

SQL Server:Availability Replica > Bytes sent to transport\sec and SQL Server:Availability Replica > Message Acknowledgement Time(ms)

4

Receive and Cache

每个secondary副本接受并且缓存这些信息.

Performance counter SQL Server:Availabiltiy Replica > Log Bytes Received/sec

5

Harden

日志在secondary副本被刷新。在日志刷新后,一个通知被发送到primary副本。一旦日志被固化,就表示不会再有数据丢失。

Performance counter SQL Server:Database > Log Bytes Flushed/sec

Wait typeHADR_LOGCAPTURE_SYNC

6

Redo

Redo刷新secondary副本中的pagePage被存放在redo队列等待被redo完成。

SQL Server:Database Replica > Redone Bytes/sec

redo_queue_size (KB) andredo_rate.

Wait type REDO_SYNC

2.流量控制门(Flow Control Gates)

AG被设计时,在primary副本上带了流量控制,为了避免太多资源消耗,比如网络,内存资源在所有可用副本上的消耗。这些流量控制不会影响可用副本的健康状态,但是会影响可用数据库性能,包括RPO

日志被primary副本捕获之后,有2个级别的流量控制。

Level

Number of Gates

Number of messages

Useful Metrics

Transport

1 per availabiltiy replica

8192

Extended event database_transport_flow_control_action

Database

1 per availability database

11200 (x64)

1600 (x86)

DBMIRROR_SEND

Extended event hadron_database_flow_control_action

一旦到达任意一个阀值,log信息就不会被发送到指定副本或者指定数据库。一旦从副本收到通知,已发送的消息下降,就可以再发。

除了流量控制,还有一个因素会阻止日志发送。副本的同步要保证LSN是顺序的被发送的。在日志被发送之前,日志的LSN会通过最小通知LSN检查,保证小于阀值。如果2LSN的空隙大于阀值,消息就不会被发送。一旦空隙小于阀值,消息就会被发送。

2个性能指标,SQL Server:Availability Replica > Flow control/sec SQL Server:Availability Replica > Flow Control Time (ms/sec) 表示在上一秒,有多少流量控制被激活并且有多少时间是用来等待流量控制。等待值越高表示RPO越多。跟多信息查看:排查:AG超过RPO

3.评估故障转移时间

故障转移时间的公式如下:

如果AG有多个可用库,最高的故障转移时间变长了限制RTO总要因素。

Tdetection错误诊断时间,是用来发现系统错误的时间。这个时间依赖于集群设置级别,而不是个别可用性副本的设置。根据设置的自动故障转移的条件,故障转移在SQL Server出现严重的内部错误会出发,比如,孤立的自旋锁。这个时候诊断在sp_server_diagnostics发送到WSFC集群马上启动。故障转移也会因为超时发生,比如集群健康检查超时(HealthCheck Timeout 默认30秒)或者资源DLL和SQL Server实例的租用超时(Leasetimeout 默认20秒)。这个诊断时间为超时的间隙。具体看:Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server).

Secondary副本唯一要做的事情就是,redo这些获取的日志。Redo时间是Tredo,公式如下:

Redo_queueredo队列的长度,redo_rateredo的速度。这2个值可以查看:sys.dm_hadr_database_replica_states

Toverhead over head的时间就是WSFC集群故障转移,数据库online的时间。通常这个时间都很小。

4.评估RPO

RPORPO的公司如下:

Log_send_queue可以查看sys.dm_hdar_database_replica_stateslog_send_queue_size和日志的生成速度,SQL Server:Database > Log Bytes Flushed/sec.

如果AG包含了多个可用性数据库,最大的 Tdata_loss  会变成限制RPO的关键。

Log发送队列表示所有数据会因为严重错误丢失的。不能使用log_send_rate来代替log生成速度,因为RPO评估数据丢失是基于日志生成速度的,而不是基于同步速度的。

最简单的评估 Tdata_loss 是使用last_commit_time.priamry会把这个值发给所有的secondary,你可以计算primary副本和secondary 副本的值的差,来评估需要多久secondary副本可以追上primary副本。虽然不能准确的表示数据丢失,但是已经很接近了。

5.监控RPORTO

本章介绍如何对RPORTO进行监控,RPORTO的计算请查看上面2节的介绍。你可以监控这2个值,在超过阀值时发送告警。

通过以下步骤创建AG的告警:
1.启动ageng服务
2.点开ALwaysOn启动用户定义AlwaysOn策略
3.创建条件, Database Replica State/ Add(@EstimatedRecoveryTime, 60) <= 600
4.创建条件 Database Replica State/EstimatedDataLoss<=3600
5.创建RTO策略,创建RPO策略

6.性能排查场景

Scenario

Description

排查:AG超过RTO

自动或者手动故障转移后,没有数据丢失,但是故障转移超过了RTO。或者评估发现故障转移时间超过了

排查:AG超过RPO

强制故障转移后,都是的数据超过了RPO。或者异步提交的replica能够承受的数据丢失超过了RPO

排查:Primary上的修改无法在Secondary体现

客户端程序可以成功的完成primary的修改,但是查询replia却没有反应。

7. 使用扩展事件

以下扩展时间可以用来排查副本在同步中的情况:

Event Name

Category

Channel

Availability Replica

redo_caught_up

transactions

Debug

Secondary

redo_worker_entry

transactions

Debug

Secondary

hadr_transport_dump_message

alwayson

Debug

Primary

hadr_worker_pool_task

alwayson

Debug

Primary

hadr_dump_primary_progress

alwayson

Debug

Primary

hadr_dump_log_progress

alwayson

Debug

Primary

hadr_undo_of_redo_log_scan

alwayson

Analytic

Secondary

 

 

posted on 2015-11-24 12:15 Fanr_Zh 阅读(...) 评论(...) 编辑 收藏