Aerospike集群单点XDR同步Lag过高问题解决

发布于 2022-4-21 22:19
浏览
0收藏

(转载公众号:晓磊聊DB)

一、名词解释
什么是Aerospike数据库?Aerospike是一款分布式NoSQL数据库:

  • 数据混合存储架构(key存储时:key是以索引的方式存内存,value存SSD硬盘)
  • 作为分布式数据库,大规模数据下的扩展性和稳定性
  • 高性能+强一致
  • 相比于纯内存的Redis方案,显著降低成本
  • 运维成本的降低:易维护+自动rebalance数据
    什么是XDR?跨数据中心复制 (XDR) 在 Aerospike 群集之间透明地、异步地复制数据。对于核心数据,一般都需要有备用集群,Aerospike使用 XDR 将数据从主机房集群同步到下游的从集群。 

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区

二、同步lag问题描述
通过监控发现集群某个节点(下图中78这台服务器)长期都有大量的数据要同步,并且lag较高(其他节点没有lag)。 

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区三、分析排查
1、既然上面的Aerospike集群中只有单节点存在lag,首先判断是不是这个节点“写偏移”导致的,查看下面的监控确实发现78这个节点的avg写入是其他集群节点的10倍。

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区这个集群只有2个业务线在用,并且通过aql show sets方式查看sets数据变化情况,发现esc_join这个sets(对应mysql的table)数据写入变化较多(平均2~3w/s)

+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
| disable-eviction | ns       | objects     | stop-writes-count | set                                    | memory_data_bytes | device_data_bytes | truncate_lut | tombstones |
+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
| "false"          | "mediav" | "115437494" | "0"               | "esc_join"                             | "0"               | "140764973360"    | "0"          | "0"        |
| "false"          | "mediav" | "37096386"  | "0"               | "unionad_xxxxx_imei"                   | "0"               | "66129833424"     | "0"          | "0"        |
...................................
| "false"          | "mediav" | "893118"    | "0"               | "mob_xxxxx_imei"                       | "0"               | "217015248"       | "0"          | "0"        |
| "false"          | "mediav" | "12590"     | "0"               | "unionad_xxxxx_sug"                    | "0"               | "15481216"        | "0"          | "0"        |
+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
[127.0.0.1:3000] 12 rows in set (0.001 secs)

+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
| disable-eviction | ns       | objects     | stop-writes-count | set                                    | memory_data_bytes | device_data_bytes | truncate_lut | tombstones |
+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
| "false"          | "mediav" | "115457756" | "0"               | "esc_join"                             | "0"               | "140749777408"    | "0"          | "0"        |
| "false"          | "mediav" | "37096386"  | "0"               | "unionad_xxxxx_imei"                   | "0"               | "66129833424"     | "0"          | "0"        |
.................................
| "false"          | "mediav" | "893118"    | "0"               | "mob_xxxxx_imei"                       | "0"               | "217015248"       | "0"          | "0"        |
| "false"          | "mediav" | "12590"     | "0"               | "unionad_xxxxx_sug"                    | "0"               | "15481216"        | "0"          | "0"        |
+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
[127.0.0.1:3000] 12 rows in set (0.001 secs)

+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
| disable-eviction | ns       | objects     | stop-writes-count | set                                    | memory_data_bytes | device_data_bytes | truncate_lut | tombstones |
+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
| "false"          | "mediav" | "115483502" | "0"               | "esc_join"                             | "0"               | "140743240720"    | "0"          | "0"        |
| "false"          | "mediav" | "37096386"  | "0"               | "unionad_xxxxx_imei"                   | "0"               | "66129833424"     | "0"          | "0"        |
.................................
| "false"          | "mediav" | "893118"    | "0"               | "mob_xxxxx_imei"                       | "0"               | "217015248"       | "0"          | "0"        |
| "false"          | "mediav" | "12590"     | "0"               | "unionad_xxxxx_sug"                    | "0"               | "15481216"        | "0"          | "0"        |
+------------------+----------+-------------+-------------------+----------------------------------------+-------------------+-------------------+--------------+------------+
[127.0.0.1:3000] 12 rows in set (0.002 secs)​

通过业务归属查到对应的负责人询问和协助排查写入情况,初步认定是写入偏移导致的,这里简单描述下Aerospike的写入分配:Aerospike 使用partition方案在各节点间分配数据,每个namespace(相当于mysql的database)被拆分为4096个partition,每个partition都有2个副本来保证可用性。当一个KV写入时,Aerospike使用 RIPEMD160 算法将一条记录的主键散列成 20 byte 的内存索引(RIPEMD160算法在发生hash冲突时具有极强的稳定性),其中分区id从这20 byte的前12个byte来确定。分区是 Aerospike 中最小的数据所有权和迁移单位,Aerospike 在群集中自动分配这些分区。

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区

经过业务方排查,从接口调用等方面来看没有只针对某些keys的变更或者写入,从“写入异常”的78节点来看hot-keys,并且进行了hot-keys的统计发现并没有一小撮keys“过热”,从其他集群节点也查看了hot-keys情况跟78节点hot-keys的数据量和分布基本一致,从而排除写偏移导致的问题。

Mar 03 2022 18:04:59 GMT+0800: INFO (info): (ticker.c:725) {mediav} xdr-from-proxy: write (155545,0,0) delete (0,0,0,0)
Mar 03 2022 18:04:59 GMT+0800: INFO (info): (dc.c:1469) xdr-dc shyc-queryad: nodes 9 lag 26026 throughput 5477 latency-ms 3 in-queue 2306245 in-progress 36 complete (233214491,0,132723,0) retries (0,0,0) recoveries (437,292) hot-keys 43788323
Mar 03 2022 18:05:09 GMT+0800: INFO (info): (ticker.c:654) {mediav} xdr-client: write (846728899,0,0) delete (0,0,0,0)
Mar 03 2022 18:05:09 GMT+0800: INFO (info): (ticker.c:725) {mediav} xdr-from-proxy: write (155545,0,0) delete (0,0,0,0)
Mar 03 2022 18:05:09 GMT+0800: INFO (info): (dc.c:1469) xdr-dc shyc-queryad: nodes 9 lag 26036 throughput 5547 latency-ms 3 in-queue 2302292 in-progress 21 complete (233269989,0,132769,0) retries (0,0,0) recoveries (437,292) hot-keys 43803497
Mar 03 2022 18:05:19 GMT+0800: INFO (info): (ticker.c:654) {mediav} xdr-client: write (847012485,0,0) delete (0,0,0,0)
Mar 03 2022 18:05:19 GMT+0800: INFO (info): (ticker.c:725) {mediav} xdr-from-proxy: write (155545,0,0) delete (0,0,0,0)
Mar 03 2022 18:05:19 GMT+0800: INFO (info): (dc.c:1469) xdr-dc shyc-queryad: nodes 9 lag 26046 throughput 5171 latency-ms 3 in-queue 2299422 in-progress 24 complete (233321718,0,132819,0) retries (0,0,0) recoveries (437,292) hot-keys 43819544

写热点的排查路子已经断了,还能有啥原因导致的该节点同步lag过高?这个节点到底跟其他节点有什么不同,因为是同步lag的问题,我开始从XDR的配置开始寻找一些区别,我对比了集群各个节点的XDR配置,我发现只有这个节点的forward配置跟其他节点不一致。 

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区这里就要了解下forword ture/false的含义了,先来官方说明的截图: 

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区啥意思呢?就是默认false的情况下,源Aerospike集群同步到下游的目的Aerospike集群,目的Aerospike只有设定为true才能再往目的Aerospike集群下游Aerospike集群同步,主要用在Aerospike的链式复制架构中。听着很绕对不对?其实拿mysql的一个参数:logslaveupdates来类比最合适了,大家看到这个mysql参数应该能理解forward=ture的配置含义了。

说回到本次问题,我需要再给大家再详细的说明下我的架构:本来集群A和集群B都有不同的业务写入,希望通过XDR的配置使得集群A/B成为同城互备集群。因为A集群的一台78节点设定了forward=ture,导致A->B,B->A,A->B,形成一个死循环,导致的问题。

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区四、解决
(1)调整transaction-queue-limit参数来缓解lag,这个参数用来控制XDR在内存中单partition事务队列的最大元素数量,每个元素占用25字节。为啥要调整这个队列大小,因为从本文前面的AS日志中的in-queue的挤压情况,想通过增加事务队列来降低lag,事实证明只是简单缓解了lag上涨,没有真正的解决问题。下面的命令是将该参数调整到默认的2倍。

asinfo -v 'set-config:context=xdr;dc=DataCenter1;namespace=someNameSpace;transaction-queue-limit=32768'

下面是官网对transaction-queue-limit的解释:

transaction-queue-limit
Maximum number of elements allowed in XDR's in-memory transaction queue per partition, per namespace, per datacenter. Each element is 25 bytes.

Value must be a power of 2 and must be expressed as an integer, not an exponent.

Default: 16*1024 = 16384.
Minimum: 1024.
Maximum: 1048576.​

(2)真正的解决:修改Aerospike集群78这个节点forward,禁止XDR的复制循环。

asinfo -v "set-config:context=xdr;dc=shyc-queryad;namespace=mediav;forward=false"

从下面2张图可以看出来,一段时间后,Aerospike再也没有出现lag,集群的写入也回归正常。 

Aerospike集群单点XDR同步Lag过高问题解决-开源基础软件社区

五、思考
(1)善于“找不同”,在Aerospike集群其他集群都没有问题,只有单节点有问题时,就需要找出该节点的数据库配置、节点硬件/软件环境跟其他其他节点的“不同”,找到了“不同”就是很好的解决问题突破点。

(2)业务沟通和协调,有时的读写“热点”可能是上游的数据偏移导致的,大家都知道2/8原则(在一个数据库中80%的操作都集中在20%的热数据上),如果是过于“集中”,可能是上游数据出了“问题”,需要找研发确认。

(3)其实对于这种单点的请求过多,还可以通过tcpdump抓包的方式查看写入情况。

(4)监控要做的更好,目前aerospike的exporter只有到事例级别,没有到sets(对应mysql的table)级别,其实可以通过Aerospike提供的接口将每个sets的数量、使用内存、使用磁盘的监控完善,这样可以通过监控更好的看到sets的变化情况,能够及时发现和定位问题。

 

标签
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐