Abstract
两个问题
实例迁移困难 ：在进行扩容时，共享存储的无服务器数据库在实例迁移上面临困难，或者必须限制资源使用在单一物理主机内，以避免潜在的迁移需求。这限制了无服务器数据库的灵活性和弹性。
无法扩展辅助节点：由于缺乏对辅助节点的强一致性支持，共享存储的无服务器数据库难以实现辅助节点的扩展，导致在处理读取请求时负载集中在主节点上，影响系统的扩展性。
无缝迁移（Seamless Migration）：
为了解决实例迁移的难题，论文提出了一种无缝迁移机制，使数据库实例可以在没有应用中断的情况下，从一个物理主机迁移到另一个主机。该机制包括：
连接维护（Connection Maintenance）：利用代理节点，保持应用与数据库之间的连接持续有效。当迁移发生时，代理节点会为新实例建立连接，并将应用的连接重映射到新实例，保证连接不中断。
事务迁移（Transaction Migration）：通过迁移旧实例的内存数据（如日志、事务元数据等）到新实例，确保未完成的事务在新实例上继续执行，实现完全透明的迁移体验。
读取扩展（Read Scale-out）：
为了支持辅助节点的扩展，论文利用了PolarDB的强一致性功能，使得辅助节点可以处理强一致性的读取请求。通过提供一个统一的强一致性端点，应用可以将所有读取请求分配到辅助节点，减轻主节点的负载。这样在读取压力较大时，可以通过扩展辅助节点来提升读取性能，而无需对主节点进行过度扩展。
1 Introduction
近年来，无服务器数据库的趋势日益凸显，重点在于提供高弹性和"按需付费"模式。无服务器数据库能够以细粒度的增量自动扩展，以满足不断变化的需求，应用程序的需求以及处理无法预测或安排的意外工作负载。部署无服务器数据库使用户只需为其使用的资源付费，从而实现显著的成本节约。
尽管已有一些不同架构的无服务器数据库（例如共享存储、共享无等[每个节点都有自己的计算和存储资源，不与其他节点共享,去中心化]），但作者将研究焦点放在了共享存储的无服务器数据库上，审查了一些商业无服务器数据库的设计，并揭示了当前无服务器数据库中存在的两个基本需求缺失：无缝迁移和读扩展。
•提出了一种新颖的策略，以实现数据库实例的快速无缝迁移，且无任何中断。
•设计并实现了 PolarDB Serverless，这是首个基于共享存储的 Serverless 数据库，支持无缝的即时跨机器横向扩展和读扩展。它已在阿里云实现商业化。
•对 PolarDB Serverless 在各种场景下进行了全面评估，展示了其出色的弹性
2 Background
2.1 基于共享存储的联机事务处理（OLTP）数据库
这种架构通常包括一个主节点和一个或多个辅助节点。主节点负责处理读和写请求，而辅助节点只处理不需要强一致性的读请求。如果当前的主节点出现故障，其中一个辅助节点可以迅速被提升为主节点。
PolarDB引入了一个代理节点，位于主节点和辅助节点之上，执行一些基本功能。这些功能包括读/写拆分、负载均衡、连接管理、故障转移处理、访问控制以及其他各种功能。
2.2 其他数据库
无共享架构：与共享存储架构不同，无共享架构涉及对整个数据库进行分区。在这种设置中，每个节点独立运行并维护其专用存储。一个节点只能访问其特定分区内的数据。当事务跨越多个分区时，需要使用跨分区分布式事务机制，如两阶段提交策略
一些新颖的方法：最近，一些学术方法探索了将共享内存集成到数据库中，以实现弹性内存使用
3.数据库日志
重做/撤销日志：许多数据库广泛采用 ARIES [29] 来撤销未提交的事务，采用了"no-force"策略，这意味着在事务提交时，不强制将修改后的数据写入存储；仅要求将日志持久化，从而提升系统性能。"Steal"策略允许在事务未提交前，将其修改的数据页写入存储，减少缓冲区占用。当未提交的事务回滚时，ARIES可以通过撤销日志来回滚已写入存储的修改。
二进制日志：二进制日志（binlog）是MySQL中的一个重要特性，用于记录对数据库的所有修改。它被用于各种工作负载，如崩溃恢复和副本同步。
3 Lessons
3.1 Seamless migration requirement 无缝迁移要求
数据库迁移：典型的共享存储数据库通常只支持一个主节点，当主节点负载增加时需要扩展资源。然而，如果当前物理主机的资源不足，系统必须选择将实例迁移到另一台资源充足的主机，或者放弃继续扩展。放弃扩展的做法违背了无服务器架构按需动态分配资源的基本原则。数据库实例的迁移过程需要执行多个步骤，包括停止旧实例和重新建立应用连接等，这会导致应用短暂中断，尤其在负载高峰期会影响用户体验。此外，迁移过程中需要恢复未写入存储的数据并回滚终止的事务。如果存在长时间运行的事务，这种中断时间可能会显著延长，给应用带来较大影响。
迁移的影响：在扩展过程中，实例迁移可能不可避免。一些无服务器数据库通过限制实例的最大资源使用量来减少迁移频率，但这种方式也限制了资源的弹性分配，无法很好地适应高峰负载。
作者通过实验测试现有无服务器数据库Aurora Serverless的迁移性能，发现提升辅助节点（次级节点）为主节点的过程大约需要15秒。这段时间内应用无法重新连接数据库，对用户来说，在应用高峰期出现这种长时间的连接断开是难以接受的。因此，迁移过程对应用的可用性和用户体验有显著影响。
避免/缓解迁移：为了减少迁移的频率和成本，许多数据库系统采用预留过量资源、限制单实例最大资源使用量以及控制每台物理主机实例数量等方法。然而，这些方法通常会导致资源未充分利用，增加云提供商的成本。尽管多实例部署能在一定程度上提高资源利用率，但在资源耗尽时，系统可能无法扩展，从而导致迁移带来的短暂停机，影响应用性能
3.2 Scale-out requirements 横向扩展要求
在传统的共享存储架构中，辅助节点仅支持"最终一致性"，导致强一致性读取请求必须通过主节点处理。随着读取负载增加，主节点需不断扩展来满足读取请求，但这种扩展受到单实例资源上限的限制。以Aurora Serverless为例，在读取负载增加时，主节点的Aurora容量单位（ACU）会迅速达到上限，系统性能受限。在此情况下，若辅助节点也支持强一致性，系统可以通过扩展辅助节点来承载更多的读取请求，从而缓解主节点的负担。
4 OVERVIEW OF POLARDB SERVERLESS
采用分离的共享存储架构，由一个主节点处理读/写请求，一个或多个辅助节点专门处理读请求。此外，它还包含一个代理节点，该代理节点位于主节点和辅助节点之上运行。该代理节点有助于实现读/写拆分、负载均衡和故障转移管理等功能，以及各种与无服务器相关的功能，包括连接管理和查询语句缓存。为了实现动态资源分配，PolarDB Serverless 配备了资源监控组件。该组件从所有数据库实例收集资源利用率数据，使其能够就资源分配或回收做出决策。
需要注意的是，PolarDB Serverless 仅支持单个主节点。因此，可以单独扩展主节点，而次节点可以扩展和横向扩展，这类似于大多数基于共享存储的服务器less数据库所采用的典型方法。然而，与其他服务器less数据库相比，PolarDB Serverless 有两个创新设计值得特别关注：无缝迁移机制和统一强一致性端点
5 IMPLEMENTATIONS
5.1 无缝迁移
5.1.1 连接维护
在实例迁移过程中，连接维护机制通过代理节点确保应用程序连接的持续有效。PolarDB Serverless通过代理节点为应用程序提供一个统一端点，应用程序与代理节点建立连接，而代理节点负责与数据库实例（包括多个辅助节点）建立连接。迁移发生时，代理节点会断开与旧实例的连接，但应用程序与代理节点的连接保持活动状态。迁移期间，应用请求会暂时缓存于代理节点，并在迁移完成后转发到新实例。代理节点随后与新实例建立连接，将缓存的请求发送至新实例。在整个迁移过程中，应用程序可以继续发送请求，虽然受影响的连接可能会有些延迟，但应用始终保持连接的稳定性和连续性。
5.1.2 实时事务迁移
两个重要部分：数据迁移和交易恢复
缓存同步：为了最小化数据流量，我们选择迁移与撤销数据相关的重做日志，而不是直接传输整个撤销页，一些用户可能会在他们的数据库中启用binlog，在这种情况下，内存中的binlog也需要迁移
事务重构：关键任务是精确回滚单个查询所做的更改，同时恢复最新的查询语句
二进制日志迁移：在迁移开始时，新实例会分配一定量的内存。然后，旧实例向新实例请求事务的内存地址。随后，它通过单向 RDMA 接口将其内存中的二进制日志传输到新实例的二进制日志缓存中。
5.2 迁移加速
PolarDB Serverless 采用两种策略来加速这一过程。第一种是基于 RDMA 的数据迁移，RDMA 网络已经是阿里巴巴的基础设施。另一种是提前为新实例进行预热。这包括从存储中预先加载必要的重做/撤销/二进制日志，并在可能的情况下提前对其进行解析。这可以节省大量 I/O 开销和 CPU 周期
5.3 安排策略
主节点扩展策略
读写分离优先：当主节点面临读请求压力时，优先选择增加辅助节点并将读请求分配给辅助节点，以减轻主节点负载，减少直接扩展主节点的需求。
预备新实例：当主节点资源接近不足（可用资源减少到 10%）时，提前准备一个新的实例作为辅助节点，并接收主节点的重做日志。这样在需要迁移时，可以快速将新实例提升为主节点。
主动迁移：通过观察应用的周期性使用模式，提前预测高峰期的扩展需求，提前进行主节点的迁移以避免高峰期的性能问题。
跨集群资源协调：在某些情况下，通过缩减另一个集群（如集群 B）在同一物理主机上的辅助节点，腾出资源来扩展当前集群（如集群 A）的主节点，而不是迁移主节点，从而提升资源利用率。
- 辅助节点扩展策略
节点数量最小化：在扩展辅助节点时，优先选择对现有辅助节点进行纵向扩展，避免频繁增加新节点以简化管理和节约带宽，只有在无法纵向扩展时才考虑增加新节点。
避免迁移：当当前主机可用资源低于 20% 时，不在该主机上继续扩展辅助节点，而是优先扩展到其他主机，以减少主节点迁移的可能性
Evaluation
迁移性能测试：通过在主节点达到一定负载时，将辅助节点提升为主节点来模拟实例迁移。测试中，观察 PolarDB Serverless 和 Aurora Serverless 在迁移过程中的吞吐量变化和事务中断情况。结果显示 PolarDB Serverless 能够在半秒内恢复吞吐量，而 Aurora Serverless 则需要约 15 秒
读密集型负载下的弹性扩展：使用 500 个线程的读密集型负载测试辅助节点的自动扩展能力。结果显示，PolarDB Serverless 能够快速响应负载增长，通过扩展辅助节点达到更高的吞吐量，而 Aurora Serverless 的吞吐量则受限于主节点
动态资源分配测试：在动态工作负载下观察 PolarDB Serverless 的 PCU（PolarDB Capacity Unit）分配和使用情况。随着负载增加，PolarDB Serverless 自动分配更多资源，并在负载稳定后维持资源分配在设定的水平