【巡检问题分析与最佳实践】PolarDB 流量 & 代理问题

往期分享RDS MySQL

RDS MySQL 实例空间问题

RDS MySQL 内存使用问题

RDS MySQL 活跃线程数高问题

RDS MySQL 慢SQL问题

RDS MySQL 实例IO高问题

RDS MySQL 小版本升级最佳实践

RDS PostgreSQL

RDS PostgreSQL 实例IO高问题

RDS PostgreSQL 慢SQL问题

RDS PostgreSQL CPU高问题

RDS SQL Server

RDS SQL Server 磁盘IO吞吐高问题

RDS SQL Server CPU高问题

RDS SQL Server 空间使用问题

PolarDB

PolarDB MySQL CPU高问题

Redis

Redis 流控问题

Redis 内存高问题

Redis CPU高问题

MongoDB

MongoDB 内存高问题

MongoDB 磁盘IO高问题

MongoDB 空间使用问题

概述

PolarDB集群原生支持读写分离方式接入业务 但是在真实业务中 经常出现节点上负载不均情况 严重的话可能导致单节点承担大量的流量被拖跨 最终整个集群雪崩影响业务。

本文主要描述PolarDB代理的配置方法以及流量不均时如何定位。

数据库代理基本信息

在RDS MySQL产品中 数据库代理需要单独购买并配置 而在PolarDB M集群中 默认即开启数据库代理功能 同时功能也比 MySQL的数据库代理更为强大。

主地址 读写 直接指向主节点 只能配置连接名 无法配置代理功能集群地址 读写方式可配置 支持标准代理配置 不可删除自定义地址 读写方式可配置 支持标准代理配置 可删除地址配置(ENDPOINT)只读类型

在选定读写模式是【只读】类型的情况下 配置项比较少 需要注意的是只读类型的endpoint如果只使用单节点 尽量不要应用在生产环境中。

另外可调整的参数是【并行查询】 此配置只在只读endpoint中可配置 在PolarDB 8.0 中支持了并行查询 如果只读endpoint承接一些AP类业务流量 可以单独提供只读节点给此endpoint 并且尽量和TP业务节点不要重合 同时对并行查询的并行度单独调整 以充分利用CPU资源执行并行查询。

读写类型

读写类型中需要注意的点主要是

一致性级别最终一致性 不考虑数据的同步情况 按负载进行节点请求的调度 会出现写入的数据未同步完成 只读节点上读取不到的情况 抽象如图

会话一致性 简单理解就是指在同一个连接里的前后请求 一般在写入后立即请求数据时使用 也是PolarDB推荐的一致性配置 抽象如图

全局一致性 每一个会话都要判断只读节点是否已经同步到最新数据 对一致性要求最高的场景下启用 抽像如图

以上三种一致性级别 需要根据业务需求配置。主库不接受读 满足一致性需求的前提下 将读请求全部分流到只读节点执行 如果不满足一致性需求 只读同步完成 流量还是会路由到主实例。事务拆分 将事务头部的读取语句拆分到只读节点上以承担主节点压力 如图

连接池

会话级连接池 用以缓存连接信息 主要是连接风暴的场景下使用 例如PHP大量短连接的场景下 无法控制连接到实例的总连接数事务级连接池 标准连接池方案 对长连接进行复用 类似Druid等连接池中间件 控制连接实例的总连接数

注意endpoint配置读写模式时 系统表查询会被路由到主节点 即使节点没有配置在当前endpoint 可能对一些业务场景有影响 例如

select * from information_schema.processlist;

读写模式下 即使没有配置主节点 写请求会自动路由到主节点如果对一致性有要求 推荐使用会话一致性 可以满足大部分业务场景 如果小部分业务的一致性要求不能在同一会话中完成 dml - select) 可以考虑使用hint方式强制读主节点 例如

/*FORCE_MASTER*/ select * from information_schema.processlist;

流量定位

有时观察实例性能 会发现实例的流量不均匀 需要定位原因 防止流量倾斜导致的实例性能问题。

常见问题主节点负载高 只读节点负载低的情况场景一 都是业务侧直接连接了主地址导致只读没有分流 特别是在【RDS一键迁移PolarDB】的最终切换过程中 默认原RDS地址会切换到PolarDB的主地址上 这种情况下会导致流量全部流转到rw节点。此类问题需要业务侧调整连接地址为集群或自定义地址。场景二 使用的是读写分离地址 但业务上有大量的写 在代理层会把所有的写流量路由到主节点。此类场景可以尝试打开【主库不接受读】和【事务拆分】 尽可能让只读节点承担一些读流量只读节点负载高 主节点负载低此类场景一般是预期内的只读节点承截流量 例如配置了主不接受读和事务拆分 同时大量的请求都是读请求时 此类场景是比较理想的PolarDB流量分配 即使只读节点资源不够 也可以通过快速添加新的只读节点以分担负载 监控曲线例如

以上两种都是预期内的负载分配 但有可能负载情况不在预期 如集群地址中有多个只读节点 但只有某个节点负载非常高 此类情况就需要定位是否有流量异常或者实例性能异常的情况。

异常定位实例复用由于PolarDB可以自定义多个endpoint 不同endpoint之前节点也可以复用 就有可能造成流量交叉导致实例负载不平均 例如TP业务和 AP业务不同的地址 但配置了相同的只读节点 如果出现交叉使用的节点负载异常 有很大可能就是不同业务之间的资源争抢 可以尝试将问题节点从某个地址中摘除 再对比负载情况。另外不建议节点交叉部署。实例本身性能问题在某些情况下 实例可能是由于自身问题导致资源负载高 例如在《PolarDB MySQL CPU高问题》 一文提到的AHI问题 不同节点分配的流量会导致AHI的分配也不相同 可能会导致某个节点上出现争抢问题 此时就要定位具体原因以优化节点性能。另外代理层是按负载情况分配的 如果单节点负载高 流量也会自动向负载低的节点倾斜 可能导致集群性能整体出现问题。来源定位目前PolarDB还未完全接入DAS历史数据诊断 如果需要定位异常流量来源 只能观察当前连接请求的情况 在一键诊断- 会话管理 入口 可以查看用Hosts维度会话的统计 以确认是否有非预期的业务来源访问。同时可将正常节点与异常节点做对比以定位异常流量来源

本文转自网络，原文链接：https://developer.aliyun.com/article/786108
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！