迁移PostgreSQL DbaaS提供者之间我们最近帮助迁移生产PostgreSQL数据库运行在一个给定的DBaaS平台…另一个DBaaS的平台。当涉及到供应商“锁定”,一些供应商更容易比别人(甚至更友好)来处理,但它绝不是一个简单的过程。而在传统环境中我们通常会解决这个问题通过创建一个复制的服务器和切换数据库请求在正确的时刻,情况复杂时不可能创建一个直接复制流外部提供者的平台。

在这篇文章中,我们将分享我们用于这种特殊情况下的方法。它并不打算提供一个循序渐进的、放之四海而皆准的解决方案,但我们希望它会为你服务的“灵感”在处理类似的情况。你可能会发现一些地方我们的方法比其他人更有用;考虑满足您的独特需求和有创造力。像往常一样,不管你计划的设计,确保你在测试/测试涉及的所有步骤登台环境首先是在实践中我们经常进入另一个石头我们不知道躺在我们的路径。

媒介DBaaS实例

当我们之间不能直接复制DBaaS实例,我们仍然可以尝试“链”在某种程度上通过一个中间球员(阅读:服务器):

源DBaaS→→目标DBaaS中间服务器

在这种特殊情况下,源DBaaS生产日常基础备份和流WAL段外部可访问存储,一个S3 bucket,用于存档。我们利用这个来创建一个中间PostgreSQL服务器从最新的基础备份可用和配置这消费上可用的细胞膜部分存储。注意在哪里安装这个中间服务器:你可能想要安装它接近源DBaaS或接近目标DBaaS代替。在作出选择的时候,考虑网络带宽以及常用工具的可用性的基础设施提供者。

然而,这中间服务器不是一个确切的PostgreSQL副本:尽管它有操作hot_standby使它只会更新为最新的细胞膜文件可供使用。因为它必须作为一个操作备用服务器我们不可能直接从使用目标DBaaS复制逻辑复制;我们将不得不等待,只把它作为一个副本一次中间PostgreSQL服务器操作备用模式已经消耗所有文件和被提升主。最小化应用程序停机,诀窍是执行迁移两个步骤:

  1. 把中间服务器尽可能同步源DBaaS,停止所有连接到源DBaaS,允许中间服务器使用最新的WAL段生成,促进为主,最后直接数据库请求。
  2. 配置目标DBaaS intermediate-now-turned-primary服务器使用逻辑复制副本,等到这个新副本了,促进新副本为主和故障转移生产流量。

我们详细讨论每一个步骤在接下来的部分。

创建中间PostgreSQL服务器

我们开始安装过程raybet52 实例在一个单独的服务器可以访问S3 bucket和目标DBaaS实例。为此,我们的服务器配置雷竞技下载官网Percona库和后安装说明。我们确保使用相同的主要PostgreSQL释放源DBaaS实例上运行和PostgreSQL相应配置,使用自定义操作设置(如work_mem从源DBaaS)复制而调整其他(如实例的配置shared_buffers我们的中间服务器规格。尽管理论上该服务器将控股生产流量只有短暂的时间你应该让它至少能像当前的生产实例。其他三个设置你应该确保正确地调整:

  • hot_standby = ' '
  • wal_level =“逻辑”
  • listen_address要么0.0.0.0或相对应的IP地址的网络接口,可以达到目标DBaaS实例。

您还应该确保任何相关防火墙允许之间的通信部分,包括pg_hba.conf文件;中间服务器必须能够访问目标DBaaS实例,反之亦然。

填充中间服务器

我们利用日常S3 bucket中可用的二进制备份和恢复最新的一个中间的实例。为此,我们使用wal-e(虽然更加现代wal-g应该工作)。他们的Github页面包含简单安装说明使用皮普。我们最终使用提前相反,二进制文件安装下/ / bin / wal-e。

为了安全地存储S3的凭证,我们把它们放在/etc/wal-e.d/env和使用envdir(从daemontools包)通过他们沿着wal-e。验证,我们可以访问存储我们尝试列出了可用的备份使用下面的命令:

然后我们继续填充中间服务器上的第一步,这是恢复最新的备份。确保PostgreSQL停止,使配置文件的一个副本(如果需要)和清理数据目录(在本例中,/var/lib/postgresql/11/main)之前进行备份的获取:

如果备份包括配置文件内的数据目录中,您可能需要调整。特别注意recovery.conf文件:它应该显示服务器将运行在待机模式,以及它如何可以访问WAL赶上主文件,在我们的案例中也可以在S3 bucket。这是我们的recovery.conf文件看起来像:

有了这个文件,你现在可以重新开始PostgreSQL中间服务器上:考虑一切顺利,应该运行和处理所有WAL文件可用,直到它消耗他们所有,然后再停止。检查错误日志/ syslog PostgreSQL证明的情况。

流量切换到中间服务器

当archive_timeout变量设置为大于0的值在源DBaaS服务器可能触发创建一个新的WAL文件每一个archive_timeout秒当服务器是在低(写)的活动,而不是自然生成WAL段在此期间。这是一个很好的提示理解细胞膜的速度段生产,因此可以使用备用服务器,比如我们中间PostgreSQL实例。当计划维护窗口切换流量中间服务器,试图让它尽可能的与主同步,可以实现通过保持recovery.conf文件位置,然后再开始PostgreSQL。

一旦时间切换到,终止所有现有连接到主,确保没有创建新的服务器并观察活动几秒钟。有疑问时,您可以创建一些人工加载力产生新的WAL段(s),如:

开始一次PostgreSQL中间服务器的recovery.conf文件仍然存在消费最新WAL段。当它停下的时候,删除或重命名recovery.conf最后一次文件并启动它。确保一切看起来好然后促进为主:

您可以通过检查服务器验证推广工作不再是在恢复模式:

现在您可以将您的数据库请求重定向到中间服务器。

设置新主出版商

逻辑复制在PostgreSQL使用发布和订阅模型所以你必须配置一个出版商覆盖数据库中的所有表(s)你想要复制的DBaaS的目标。这个过程可能会非常简单,连接到目标数据库(雷竞技下载官网在我们的示例中)并创建一个出版商(我们将调用percpub):

关于逻辑复制性能:一个很重要的问题必须有一个方法来唯一地标识每个元组更改被应用,在理想的情况下通过一个主键或唯一键(非空)。当一个目标表缺乏这两种,副本的身份必须设置为全部,整个元组组合将用于识别它,这使得比较过程更加昂贵,导致更高的开销。

配置目标DBaaS复制品

首先,确保这个实例也配置了wal_level =“逻辑”或者你不会看到任何复制,这是明显的需求不如预期的一致。以不同的方式完成这个设置的变化根据供应商参与。

除了优化其他PostgreSQL设置目标DBaaS的因此,创建目标数据库和一个用户可以访问它。一旦完成,您将能够构建模式和目标数据库采取的模式对象pg_dump与- s选项(“转储的模式,没有数据从中间服务器”)和恢复目标DBaaS实例。这可以通过一个命令封装了两个行动,应该从中间服务器运行:

确保调整值数据库,主机名,用户在上面的命令和一个如下所示。

一旦完成后您可以创建订阅的模式:

这应该足够了;目标DBaaS实例将初始数据复制,然后从中间服务器同步所有更改。你可以参照它的进步通过查询:

两个重要的注意事项:

  1. 注意,它可能很难创建一个逻辑复制槽在忙,高事务服务器。你可能想要做后立即促进中间服务器为主,在应用程序启动前连接到它。这样做不能早些时候因为逻辑解码备用服务器上目前是不可能的。
  2. 逻辑复制不ddl复制;确保你冻结任何数据库模式的改变,直到你完成迁移。

最终的转换

一旦目标DBaaS赶上主要可以通过促进计划最终转换这个副本作为主人和重定向生产流量。

就是这样:我们能够完成上述步骤后迁移。我们希望你会发现他们是有用的;你可以让我们知道在下面评论部分。

我们的白皮书”为什么选择PostgreSQL ?”看着PostgreSQL的特点和优点,提出了一些实际的用法示例。我们还研究如何对企业有用PostgreSQL从Oracle迁移。

下载

1评论
最古老的
最新的 大多数投票
内联反馈
查看所有评论
泰勒的水域

花了多长时间?数据库有多大?有多少连接/交通收到吗?

0