揭秘 Amazon Aurora DSQL 跨区域同步延迟！（系列②）

于 2025-02-24 21:13:53 发布
阅读量1k 收藏 20
点赞数 12
分类专栏： 亚马逊云科技 文章标签： 数据库 服务器 mysql aws 亚马逊云科技
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/rralucard123/article/details/145837360
版权

1. 引言

在上一篇文章 「探索 Amazon Aurora DSQL：基本操作全解析（系列①）」 中，我们确认了 Aurora DSQL 的基本使用方法，包括如何连接到 DSQL 集群并执行 SQL 语句。

本篇文章的关注点在于：Aurora DSQL 在 US-East-1 写入的数据能多快地同步到 US-East-2？

Aurora DSQL 采用了一种高效的同步机制，但要深入理解其具体实现并不容易。因此，我们决定通过实际测试，测量数据同步所需的时间，以直观地感受其性能。

需要注意的是，本文中的延迟数据仅反映测试执行时的情况，并非严格的性能测试结果，仅供参考。

2. 测试内容

本次测试主要关注 Aurora DSQL 的跨区域同步速度，并与 Aurora Global Database 的异步复制延迟 进行对比。具体测试如下：

1 区域间网络延迟（ping）

  • 通过 ping 命令测量 US-East-1 与 US-East-2 之间的网络延迟，仅限于 EC2 实例之间的通信。

2 EC2 实例到 Aurora DSQL 的写入延迟

  • 测量 US-East-1 的 EC2 实例 向 本地 Aurora DSQL 集群 以及 远程（US-East-2）的 DSQL 集群 执行 INSERT 操作时的延迟。

3 Aurora DSQL 跨区域同步速度（核心测试）

  • 在 US-East-1 的 EC2 实例 中向 US-East-1 的 Aurora DSQL 集群 执行 INSERT 操作；
  • 然后，在 US-East-2 的 EC2 实例 连接 US-East-2 的 Aurora DSQL 集群 执行 SELECT，以测量数据同步所需时间。

4 Aurora Global Database 的异步复制延迟（对比实验）

作为对比，我们还测试了 Aurora Global Database 的异步复制速度：

  • US-East-1 的 EC2 实例 向 US-East-1 的 Aurora Global Database（主实例） 插入数据；
  • US-East-2 的 EC2 实例 连接 US-East-2 的 Aurora Global Database（只读副本） 执行 SELECT，测量数据复制的延迟。

3. 构成图

在创建 Aurora DSQL 的同一区域中，分别准备用于执行 SQL 语句的 EC2 实例（Amazon Linux 2023，t2.micro）。

作为对比参考，在创建 Aurora DSQL 的同一区域中，创建 Aurora 全局数据库（PostgreSQL 16.4，r5.large），并设置：

  • us-east-1 为 主实例（primary）
  • us-east-2 为 从实例（secondary）

4. 步骤

4.1 区域间延迟（ping）

为了确认 us-east-1 和 us-east-2 之间的距离，首先在两个区域内的实例之间执行 ping 测试（使用 EIP）。

[ec2-user@ip-10-0-0-110 ~]$ ping x.x.x.x (us-east-2インスタンスのEIP)
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttl=121 time=13.7 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=121 time=13.0 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=121 time=13.0 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=121 time=12.4 ms
64 bytes from x.x.x.x: icmp_seq=5 ttl=121 time=12.9 ms
64 bytes from x.x.x.x: icmp_seq=6 ttl=121 time=12.9 ms
64 bytes from x.x.x.x: icmp_seq=7 ttl=121 time=12.6 ms
64 bytes from x.x.x.x: icmp_seq=8 ttl=121 time=13.2 ms
64 bytes from x.x.x.x: icmp_seq=9 ttl=121 time=13.5 ms
64 bytes from x.x.x.x: icmp_seq=10 ttl=121 time=13.2 ms
^C
--- x.x.x.x ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 12.420/13.049/13.719/0.360 ms

us-east-1 和 us-east-2 之间的 ping 延迟大约为 13ms（往返）。

作为参考，在 东京（ap-northeast-1） 和 大阪（ap-northeast-3） 之间的实例进行 ping 测试，往返延迟约为 10ms。因此，如果未来 DSQL 在日本推出，并在东京和大阪之间使用，预计延迟水平也会相近。

4.2 EC2 实例 - Aurora DSQL 之间的延迟

测量 EC2 实例（Python 脚本） 向 Aurora DSQL 执行 INSERT 语句时的延迟，分为以下两种情况：

  1. 同一区域（同一区域内的 EC2 实例到 DSQL）的延迟
  2. 跨区域（EC2 实例向另一个区域的 DSQL）的延迟

其架构示意图如下所示。

实施方法

在测试前，预先创建一个用于测量延迟的表，表结构包括以下三列：

  • id：唯一标识符
  • EC2 实例时间：记录 EC2 实例 执行 INSERT 语句的时间
  • DSQL 服务器时间：记录 Aurora DSQL 处理 INSERT 请求的时间
postgres=> CREATE TABLE time_list (id INTEGER not null, instance_time TIMESTAMP not null, dsql_time TIMESTAMP not null, PRIMARY KEY(id));
使用以下 Python 脚本测量延迟

该脚本的工作原理如下：

  1. 首先，在 EC2 实例上获取当前系统时间。
  2. 然后，通过 SQL 语句获取 Aurora DSQL 服务器的时间。
  3. 将 EC2 实例时间和 DSQL 服务器时间插入到同一行，以计算延迟。
  4. 由于启用了 AUTO COMMIT，每次 INSERT 后都会自动提交，并触发 DSQL 在 Linked Region 之间的数据同步。
  5. 每 10ms 重复执行一次 INSERT 操作。
测试结果

同一区域内的延迟

[ec2-user@ip-10-0-0-110 ~]$ python3 insert-us-east-1.py
ID    Instance Time                  DSQL Time
1     2025-02-10 01:53:02.047760 2025-02-10 01:53:02.046821
2     2025-02-10 01:53:02.270401 2025-02-10 01:53:02.269634
3     2025-02-10 01:53:02.304991 2025-02-10 01:53:02.304108
4     2025-02-10 01:53:02.338620 2025-02-10 01:53:02.337666
5     2025-02-10 01:53:02.371345 2025-02-10 01:53:02.370401
6     2025-02-10 01:53:02.403060 2025-02-10 01:53:02.402765
7     2025-02-10 01:53:02.435984 2025-02-10 01:53:02.434993
8     2025-02-10 01:53:02.468278 2025-02-10 01:53:02.467330
9     2025-02-10 01:53:02.500519 2025-02-10 01:53:02.499536
10    2025-02-10 01:53:02.531806 2025-02-10 01:53:02.530837

跨区域延迟

[ec2-user@ip-10-0-0-110 ~]$ python3 insert-us-east-2.py
ID    Instance Time                  DSQL Time
1     2025-02-10 02:10:20.543390 2025-02-10 02:10:20.548469
2     2025-02-10 02:10:20.813969 2025-02-10 02:10:20.819066
3     2025-02-10 02:10:20.883989 2025-02-10 02:10:20.889074
4     2025-02-10 02:10:20.953425 2025-02-10 02:10:20.958444
5     2025-02-10 02:10:21.002607 2025-02-10 02:10:21.007618
6     2025-02-10 02:10:21.050416 2025-02-10 02:10:21.068457
7     2025-02-10 02:10:21.113137 2025-02-10 02:10:21.118171
8     2025-02-10 02:10:21.161655 2025-02-10 02:10:21.166648
9     2025-02-10 02:10:21.209806 2025-02-10 02:10:21.214818
10    2025-02-10 02:10:21.258429 2025-02-10 02:10:21.263434

由于 Instance Time 的获取是在前，理论上 Instance Time 的时间戳应该早于 DSQL Time。

然而，在 同一区域内的测试结果 中，DSQL Time 反而比 Instance Time 更早。
这可能是由于以下几个因素造成的：

  1. EC2 实例和 DSQL 依赖 TimeSync Service 进行时钟同步，但同步的精度存在误差。
  2. Python 和 SQL 语句在获取时间时存在一定的调用延迟，导致时间戳记录存在偏差。
  3. 在毫秒/微秒级别精确获取时间戳具有一定难度，受操作系统调度、网络通信等因素影响。

基于以上分析，我们暂时认为，在 同一区域内，Aurora DSQL 几乎可以实现零延迟写入。

跨区域（us-east-1 → us-east-2）的延迟情况

  • 测得的 INSERT 延迟约为 5ms。
  • 此前测得的 us-east-1 与 us-east-2 之间的 ping 往返延迟（RTT）约为 13ms。

结合这些数据，我们可以推测 Aurora DSQL 在跨区域同步上的额外开销较低，基本符合预期，与物理网络延迟的数值相当。

4.3 Aurora DSQL 集群间的数据同步延迟

本次测试的核心内容是：

  • 在 us-east-1 的 EC2 实例上，向 us-east-1 的 DSQL 集群持续执行 INSERT 操作。
  • 在 us-east-2 的 EC2 实例上，向 us-east-2 的 DSQL 集群执行 SELECT 查询，观察在查询时数据同步到了哪个时间点。

通过这种方式，我们可以测量 Aurora DSQL 在跨区域数据同步中的延迟。

实施方法

  • 在 us-east-1 的 EC2 实例上，每 10ms 间隔执行 INSERT 操作，每次插入一行记录，包含：

    • EC2 实例时间（Instance Time）
    • Aurora DSQL 服务器时间（DSQL Time）
    • AUTO COMMIT 开启，确保每次 INSERT 操作后立即提交

  • 使用的脚本与「4.2 EC2 实例 - Aurora DSQL 之间的延迟」章节相同。

  • us-east-2 侧的脚本如下：

    • 在 us-east-1 侧的 INSERT 操作持续进行的状态下，
    • us-east-2 的 EC2 实例 连接 us-east-2 的 DSQL 集群 执行 SELECT 查询，
    • 检查 SELECT 查询时获取的最新记录，计算数据同步的延迟。
import psycopg
import boto3
import os, sys
import time
from datetime import datetime

def main(cluster_endpoint):
    region = 'us-east-2'

    # Generate a password token
    client = boto3.client("dsql", region_name=region)
    password_token = client.generate_db_connect_admin_auth_token(cluster_endpoint, region)

    # connection parameters
    dbname = "dbname=postgres"
    user = "user=admin"
    host = f'host={cluster_endpoint}'
    sslmode = "sslmode=require"
    #sslrootcert = "sslrootcert=system"
    password = f'password={password_token}'

    # Make a connection to the cluster
    conn = psycopg.connect('%s %s %s %s %s' % (dbname, user, host, sslmode, password))
    conn.set_autocommit(True)
    cur = conn.cursor()

    itime = datetime.now()
    print(f"Instance Time(start) : {itime}")

    cur.execute("select NOW()")
    results = cur.fetchone()[0]
    formatted_time = results.strftime("%Y-%m-%d %H:%M:%S.%f")  # %fはマイクロ秒を表示
    print(f"Database Time(finish): {formatted_time}")

    cur.execute("SELECT * FROM time_list")
    
    itime = datetime.now()
    print(f"Instance Time(finish): {itime}")

    results = cur.fetchall()  
    print(f"{'ID':<5} {'Instance Time':<30} {'DSQL Time':<30}")

    for row in results:
        print(f"{row[0]:<5} {row[1]} {row[2]}")

if __name__ == "__main__":
    # Replace with your own cluster's endpoint
    cluster_endpoint = "xxxxxxxxxxxxxxxxxxxx.ycq.dsql.us-east-2.on.aws"
    main(cluster_endpoint)
测试结果
在 10ms 间隔下连续执行 INSERT 的情况下

使用上述脚本进行测试，每 10ms 执行一次 INSERT，共执行 400 次，在此过程中 执行 1 次 SELECT。

测试结果如下：

  • INSERT 记录总数：400 条
  • SELECT 查询时可获取的最新记录时间戳：X
  • 计算出的 Aurora DSQL 数据同步延迟：X ms

从结果可以观察到，在 10ms 间隔高频插入的情况下，Aurora DSQL 的数据同步延迟表现如何。

[ec2-user@ip-10-0-15-4 ~]$ python3 dsql-select.py　※10ms間隔
Instance Time(start) : 2025-02-10 02:03:14.326589
Database Time(finish): 2025-02-10 02:03:14.325649
Instance Time(finish): 2025-02-10 02:03:14.458220
ID    Instance Time                  DSQL Time

1     2025-02-10 02:03:11.161942 2025-02-10 02:03:11.160994
2     2025-02-10 02:03:11.343008 2025-02-10 02:03:11.342087
3     2025-02-10 02:03:11.377308 2025-02-10 02:03:11.376310
～中略～
94    2025-02-10 02:03:14.303955 2025-02-10 02:03:14.303032
95    2025-02-10 02:03:14.335718 2025-02-10 02:03:14.334773
96    2025-02-10 02:03:14.368579 2025-02-10 02:03:14.367585
timestamp处理内容
a02:03:14.326 589us-east-2 的 EC2 实例开始处理（SELECT 开始前）
b02:03:14.325 649us-east-2 DSQL 执行 SELECT 完成
c02:03:14.458 220us-east-2 EC2 实例完成处理（SELECT 结果接收）
d02:03:14.368 579获取到的最新记录中 us-east-1 EC2 实例的时间戳
e02:03:14.367 585获取到的最新记录中 us-east-1 DSQL 的时间戳
对获取到的时间戳值进行确认
  • 在 us-east-2 的 EC2 实例 执行 SELECT 查询的时间点 a（02:03:14.326589） 时，
    查询到的最新记录中，us-east-1 侧的时间戳（d/e）竟然比 a 更靠后，
    这导致了 逻辑上不合理的结果。
  • 可能的原因包括：
    • EC2 实例与 DSQL 之间的时钟同步误差（TimeSync Service 可能存在一定的偏差）。
    • Python 或 SQL 获取时间戳的精度限制，导致查询时间戳和数据写入时间戳出现错位。
    • 毫秒/微秒级的时间戳测量误差，在当前方法下可能难以避免。
500ms 间隔的连续 INSERT
  • 为了获得更清晰的结果，
    us-east-1 侧的 EC2 实例 将 INSERT 执行间隔调整为 500ms，
    并使用相同的方法重新进行测试，以减少测量误差的影响。
[ec2-user@ip-10-0-15-4 ~]$ python3 dsql-select.py 　※500ms間隔
Instance Time(start) : 2025-02-12 07:57:16.100630
Database Time(finish): 2025-02-12 07:57:16.099583
Instance Time(finish): 2025-02-12 07:57:16.246476
ID    Instance Time                  DSQL Time                     
1     2025-02-12 07:57:07.569067 2025-02-12 07:57:07.568210
2     2025-02-12 07:57:08.249154 2025-02-12 07:57:08.248505
3     2025-02-12 07:57:08.772726 2025-02-12 07:57:08.772051
～中略～
15    2025-02-12 07:57:15.046144 2025-02-12 07:57:15.045614
16    2025-02-12 07:57:15.567858 2025-02-12 07:57:15.567327
17    2025-02-12 07:57:16.089342 2025-02-12 07:57:16.088828
timestamp处理内容
a07:57:16.100 630us-east-2 的 EC2 实例开始处理（SELECT 开始前）
b07:57:16.099 583us-east-2 DSQL 执行 SELECT 完成
c07:57:16.246 476us-east-2 EC2 实例完成处理（SELECT 结果接收）
d07:57:16.089 342获取到的最新记录中 us-east-1 EC2 实例的时间戳
e07:57:16.088 828获取到的最新记录中 us-east-1 DSQL 服务器的时间戳
对获取到的时间戳值进行进一步确认

  • 在 us-east-2 的 EC2 实例 执行 SELECT 查询的时间点 a（07:57:16.100630） 时，
    查询到的最新记录中，us-east-1 侧的时间戳（d/e）约比 a 早 120ms。

  • 根据这一结果，可以推测：

    • DSQL 集群之间的数据同步至少在 500ms 内完成，即 INSERT 之后的 500ms 内，数据已成功同步至 us-east-2。
    • us-east-2 侧能够查询到最新的 INSERT 结果，说明 Aurora DSQL 在此间隔下的同步性能表现良好。

4.4 Aurora Global Database 的异步复制延迟

  • 作为参考，在 Aurora Global Database 上进行相同的验证。Aurora Global Database 的设定如下：
    • 引擎：PostgreSQL 16.4（接近 Aurora DSQL（Preview））
    • 实例类型：db.r5.large（设置为 Global Database 所需的最小配置）
    • 冗余架构：us-east-1 为 Primary，us-east-2 为 Secondary（通常仅支持只读）

实施方法
  • 执行与「4.2 EC2 实例 - Aurora DSQL 之间的延迟」及「4.3 Aurora DSQL 集群间的数据同步延迟」相同的测试。（将连接的 端点 从 Aurora DSQL 切换为 Aurora Global Database）
  • 由于 us-east-2 的 Aurora Global Database（Secondary）为只读实例，无法写入，因此省略从 us-east-1 EC2 实例向 us-east-2 进行写入测试。
结果
EC2 实例 - Aurora Global Database（Primary）之间的延迟（同一区域内）
[ec2-user@ip-10-0-0-110 ~]$ python3 aurora-insert.py
ID    Instance Time                  Aurora Time
1     2025-02-10 00:35:22.082938 2025-02-10 00:35:22.083393
2     2025-02-10 00:35:22.096639 2025-02-10 00:35:22.097042
3     2025-02-10 00:35:22.109740 2025-02-10 00:35:22.110143
4     2025-02-10 00:35:22.123324 2025-02-10 00:35:22.123743
5     2025-02-10 00:35:22.136899 2025-02-10 00:35:22.137323
6     2025-02-10 00:35:22.149976 2025-02-10 00:35:22.151701
7     2025-02-10 00:35:22.164577 2025-02-10 00:35:22.165006
8     2025-02-10 00:35:22.178305 2025-02-10 00:35:22.178722
9     2025-02-10 00:35:22.191660 2025-02-10 00:35:22.192067
10    2025-02-10 00:35:22.204872 2025-02-10 00:35:22.205272
Aurora DSQL 的同区域写入延迟
  • 与 Aurora DSQL 之前的测试结果没有显著差异，始终满足 实例时间 < Aurora 时间，
    这表明在 同一区域内，可以在数毫秒级别完成 INSERT。
Aurora Global Database 之间的异步复制延迟

  • 测试方法：

    • 与 Aurora DSQL 的测试相同，在 us-east-1 侧以 10ms/500ms 间隔连续执行 INSERT，
    • 同时在 us-east-2 侧执行 SELECT 以监测数据同步情况。

  • 注意：

    • Aurora Global Database 采用异步复制，
    • 其复制机制与 Aurora DSQL（同步处理）不同，可能会表现出不同的延迟特性。
[ec2-user@ip-10-0-15-4 ~]$ python3 aurora-select.py　※10ms間隔
Instance Time(start) : 2025-02-10 00:47:57.652112
Database Time(finish): 2025-02-10 00:47:57.652392
Instance Time(finish): 2025-02-10 00:47:57.655129
ID    Instance Time                  Aurora Time
1     2025-02-10 00:47:54.465371 2025-02-10 00:47:54.465772
2     2025-02-10 00:47:54.479214 2025-02-10 00:47:54.479581
3     2025-02-10 00:47:54.492804 2025-02-10 00:47:54.493156
～中略～
238   2025-02-10 00:47:57.599869 2025-02-10 00:47:57.600225
239   2025-02-10 00:47:57.612945 2025-02-10 00:47:57.613302
240   2025-02-10 00:47:57.625803 2025-02-10 00:47:57.626162
[ec2-user@ip-10-0-15-4 ~]$
timestamp处理内容
a00:47:57.652 112us-east-2 的 EC2 实例开始处理（SELECT 开始前）
b00:47:57.652 392us-east-2 Aurora（Secondary）执行 SELECT 完成
c00:47:57.655 129us-east-2 EC2 实例完成处理（SELECT 结果接收）
d00:47:57.625 803获取到的最新记录中 us-east-1 EC2 实例的时间戳
e00:47:57.626 162获取到的最新记录中 us-east-1 Aurora（Primary）的时间戳
[ec2-user@ip-10-0-15-4 ~]$ python3 aurora-select.py  ※500ms間隔 
Instance Time(start) : 2025-02-12 13:34:12.982551
Database Time(finish): 2025-02-12 13:34:12.982938
Instance Time(finish): 2025-02-12 13:34:12.986455
ID    Instance Time                  Aurora Time                     
1     2025-02-12 13:34:08.100501 2025-02-12 13:34:08.101002
2     2025-02-12 13:34:08.604676 2025-02-12 13:34:08.605241
3     2025-02-12 13:34:09.109176 2025-02-12 13:34:09.109742
4     2025-02-12 13:34:09.613155 2025-02-12 13:34:09.613710
5     2025-02-12 13:34:10.117047 2025-02-12 13:34:10.117648
6     2025-02-12 13:34:10.621244 2025-02-12 13:34:10.623301
7     2025-02-12 13:34:11.128629 2025-02-12 13:34:11.129190
8     2025-02-12 13:34:11.637546 2025-02-12 13:34:11.638114
9     2025-02-12 13:34:12.141808 2025-02-12 13:34:12.142391
10    2025-02-12 13:34:12.646207 2025-02-12 13:34:12.646776
処理内容timestamp
a在 us-east-2 EC2 实例上开始处理（在 SELECT 开始前）13:34:12.982551
bus-east-2 Aurora(Secondary)中 SELECT 已完成13:34:12.982938
c在 us-east-2 的 EC2 实例上处理完成（收到 SELECT 结果）13:34:12.986455
d获取到的最后一条记录中的 us-east-1 的 EC2 实例时间13:34:12.646207
e获取到的最后一条记录中的 us-east-1 的 Aurora（主）时间13:34:12.646776

在 10 毫秒间隔 进行 INSERT 时，us-east-2 侧 SELECT 的时间 (a) 与最后一条记录的时间 (d/e) 之间的差约为 26 毫秒。
而在 500 毫秒间隔 进行 INSERT 时，时间 a 与 d/e 之间的差约为 335 毫秒。

虽然复制似乎可以在 数十毫秒级别的延迟 下完成，但由于 较小数值的严格测量较为困难，
因此，这次测试我们认为 Aurora Global Database 的复制延迟大致在 500 毫秒以内。

4.5 总结

  • 将截至目前测得的数值整理成图表（仅基于本次的测量方法和时间点获取的数值，并非严格精确的数据）。

  • us-east-1 和 us-east-2 之间的区域网络延迟（RTT）约为 13ms。
  • 无论是 Aurora DSQL 还是 Aurora Global Database，在同一区域内执行 INSERT/SELECT 所需的时间都可以忽略不计。
  • Aurora DSQL 和 Aurora Global Database 之间的同步/异步复制似乎能在数十毫秒级别完成，但本次测试方法无法进行严格测量。
    • 在本次测试条件下（仅 INSERT 一行记录），同步/异步复制均能在 500ms 内完成。

5. 感想

  • 由于是初学者，测量方法是否合适仍存在一定问题，但可以确认数据同步似乎可以在 极低延迟 下完成。
  • 通过查阅 re:Invent 发表的资料，希望能够理解 为何能够实现低延迟同步 及其 具体机制。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值