Netflix描述了一个内部自动化平台，该平台能够将亚马逊RDS for PostgreSQL数据库迁移到亚马逊Aurora PostgreSQL上，从而降低近400个生产集群的运营风险并减少停机时间。该系统使服务团队能够通过自助式工作流程来启动迁移操作，并同时确保复制过程的准确性、切换过程的有序进行、变更数据捕获工作的协调性以及回滚机制的有效性。
Netflix通过一个基于Envoy构建的平台管理型数据访问层来处理数据库访问请求，这一层标准化了相互TLS认证机制，并将数据库端点与应用程序代码分离。由于各服务不会直接管理凭证或连接信息，因此迁移操作必须完全在这一层之下透明地进行。因此，所有复制协调、验证、切换处理、变更数据捕获以及回滚操作都是在基础设施层面完成的。
Netflix的工程师们强调道：“我们的目标是让将RDS数据库迁移到Aurora PostgreSQL的过程变得可重复且操作简便，同时确保事务性工作负载和变更数据捕获流程的准确性。”
迁移工作流程首先会使用亚马逊Web Services提供的功能，创建一个Aurora PostgreSQL集群，作为源RDS PostgreSQL实例的物理读副本。该副本会从存储快照中初始化，并持续复制来自源数据库的写前日志记录。在这一阶段，系统会验证复制槽的状态、WAL生成速度、参数兼容性以及复制延迟情况，以确保在切换之前，副本能够承受高峰写入负载。
RDS到Aurora PostgreSQL的迁移工作流程（来源：Netflix技术博客文章）
对于那些使用变更数据捕获机制的工作负载来说，包括那些依赖逻辑复制槽或下游流处理器的系统，自动化工具会在迁移前协调好各复制槽的状态。此时，变更数据捕获进程会被暂停，以防止WAL文件积累过多；同时，各复制槽的位置也会被记录下来，这样在完成迁移后，就可以在Aurora上重新创建相应的复制槽，并确保日志序列号的一致性。这样一来，既能保证数据传输的连续性，又能避免因WAL文件堆积而导致复制延迟加剧的问题。
作为早期采用者，Netflix的赋能应用团队对支持设备认证及合作伙伴计费工作流程的数据库进行了迁移。在复制过程中，工程师们发现由于某个处于非活跃状态的逻辑复制槽仍然保留着WAL段，从而导致OldestReplicationSlotLag指标值升高，进而加剧了复制延迟。在移除了这个无效的复制槽之后，复制过程恢复正常，迁移任务也成功完成，迁移后的各项指标都与迁移前的基准数据相符。
简化版的赋能应用概述（来源：Netflix技术博客文章）
当复制延迟接近零时，系统会进入一个受控制的静默状态。此时会修改安全组规则，并重新启动源RDS实例，从而在基础设施层阻止新的连接请求。在确认所有正在进行的交易都已经完成，且Aurora副本已经重放了所有的WAL记录之后，该副本就会被提升为可写入的Aurora集群，数据访问层也会将流量路由到新的端点。
据Netflix的工程师们介绍，回滚操作被视为一项非常重要的任务。在完成升级流程并确保所有流量都成功切换到新集群之前，原始的RDS实例会继续保持其权威源的地位。如果在同步过程中验证失败，或者在升级后的健康检查中发现异常，系统可以通过数据访问层将流量重新路由回RDS集群。由于应用程序与物理端点是解耦的，因此只需恢复路由配置即可使系统回到之前的状态，而无需进行任何重新部署操作。此外，如果需要，CDC消费者也可以从原始集群上之前记录的位置继续执行数据读取操作。