携程旅行网数据库专家 俞榕刚 《AlwaysOn技术在携程核心数据库的应用》

AlwaysOn技术在携程核心数据库中的应用携程旅行网俞榕刚携程SQLServer运维介绍酒店机票度假团购商旅….基本情况：上百台生产SQLServer数据库服务器另外有非生产/备机/托管/BI等服务器很多数据库大小在一个T以上BatchRequests/sec经常达到上万数据库主要版本:SQLServer2012SP2CU1支撑携程各个业务条线SQLServer运维主要包括，但不限于：24*7支持业务数据库层面变更数据库全方位监控数据库性能分析调优运维工具脚本开发数据库架构调整数据库主监控面板监控面板显示主要监控指标：红色(严重告警),黄色(告警),绿色(正常)点击显示具体情况：日志传输和镜像日志传输：辅助数据库主要用于支持人员进行复杂离线查询数据延迟会有半个小时到一个小时。追加日志和离线查询会有冲突镜像：接近实时传递数据到辅助数据库。辅助数据库不可读。数据延迟通常在秒级别。用于：1）异地灾备。2）在辅助数据库上创建快照，快照可读，用于BI取数数据库群集群集：使用于快速切换，保持高可用。备节点处于待机状态。采用3+2或者5+2的方案，来提高备节点利用率。共享存储容易成为瓶颈数据库标配高可用架构包括群集(快速切换)镜像(BI取数，异地灾备)日志传输(离线查询)复制分发技术水平扩展使用事务复制，两层或三层架构以表为单位，分发到多台服务器通过A10负载均衡，提供业务访问复制分发的优点：可根据需要建立链路复制分发的缺点：运维相当复杂容易碰到延迟SQL2012功能AlwaysOn支持异步模式和同步模式支持自动故障转移数据库存储在本地磁盘上支持对副本数据库只读操作最多支持4个辅助副本SQL2012新功能AlwaysOn基本运作原理见右图：AlwaysOn和复制分发比较AlwaysOn复制分发数据复制单位以库为单位，全库复制以表为单位数据传输模式通过日志，数据成块打包传输通过日志，数据逐条传输订阅端个数限制最多只能4个，2014版本可以有8个订阅端可以有多个延迟主要因素磁盘性能存储性能是否可以做高可用可以不可以运维很方便，基本透明复杂，需要了解细节使用模式比较固定，如一拖二，一拖一千变万化，从而链路会很复杂携程数据库AlwaysOn架构通过Cluster做主节点高可用读节点使用PCI-ESSD来大幅度提升IO性能前端使用A10负载均衡，写节点可以加入，但是比重很低第五个节点支持BI取数，以及异地灾备功能。运维主要通过拉出拉入A10负载均衡，以及群集切换来实现。复制分发到AlwaysOn改造AlwaysOn和复制分发可以并存搭建AlwaysOn，初始化数据通过A10拉出拉入,对服务器逐一切换回收复制分发订阅服务器改造后的收益系统更加稳定。AlawaysOn不太会出问题，而复制分发问题比较多，人工干预比较多。数据延迟大幅度减小。即使有延迟，也迅速回落。在秒级别内。监控变得更加简单。只对整个数据库做监控，无需考虑复杂链路运维更加方便。兼有高可用和读写分离，可以拉出A10负载均衡做维护AlwaysOn延迟监控AlwaysOn以数据库为单位进行数据传递在参与AlwaysOn的数据库中，建立一个监控表AGDelayCheck（AG_updatetime,datetime)在写端，每隔1秒以时间戳更新该表数据。在读端，检查该表时间，获得延迟信息，并前端展示。AlwaysOn延迟监控AlwaysOn延迟监控AlwaysOn延迟监控AlwaysOn运维经验计划任务的执行，需要在其他节点上也进行部署。在计划任务里，判断是否是主节点延迟判断：应用程序可以根据延迟情况，自动决定是否切换查询到写库上统计信息更新问题：在写库上数据的变更，统计信息如何在读库上反映出来？读写库负载会相差很大。读库也会产生统计信息。AlwaysOn运维经验副本上的阻塞问题:查询语句(需申请架构锁)有时候会被统计信息更新(拥有架构锁)阻塞。Redo线程(如Apply写库上的DDL语句)有时候也会被复杂查询(拥有架构锁)所阻塞，导致AlwaysOn延迟。群集的仲裁模式：需要注意群集节点的仲裁，防止脑裂现象和SSD搭配使用，能极大缓解应用性能瓶颈。