【问题标题】:How to implement schema migration for PostgreSQL database如何实现 PostgreSQL 数据库的架构迁移
【发布时间】:2020-05-11 11:05:31
【问题描述】:

我需要为 PostgreSQL 实现架构迁移机制。 只是为了消除歧义:对于模式迁移,我的意思是我需要将我的数据库结构升级到最新版本,而不管它们在特定服务器实例上的当前状态如何。

例如,在版本一中我创建了一些表,然后在版本二中我重命名了一些列,在版本三中我删除了一个表并创建了另一个。我有多个服务器,在其中一些服务器上我有版本一,一些版本三等。

我的想法:

  • 生成的输出生成哈希

pg_dump --schema-only

每次在我更改数据库架构之前。这将是一种可靠的方式来确定将来应该应用补丁的数据库版本。

  • 包含补丁列表及其应应用的相关哈希值。
  • 当我需要升级我的数据库时,我将运行一个应用程序,该应用程序将搜索与当前数据库结构相对应的哈希(通过计算本地数据库的哈希并将其与我拥有的哈希集进行比较)并应用相关的补丁。李>
  • 重复直到找不到下一个哈希。

您能否指出这种方法的任何不足之处?

【问题讨论】:

    标签: postgresql schema-migration


    【解决方案1】:

    你听说过https://pgmodeler.io 吗?在我工作的公司,我们决定这样做,因为它甚至可以在本地和远程之间执行模式差异。我们对此非常满意。

    否则,如果您更喜欢免费的解决方案,您可以开发一个迁移工具,该工具可用于应用您存储在单个存储库中的迁移。此外,此工具可以依赖您保存在单独架构中的 migration 表,以便您的数据库始终知道应用了哪些迁移。

    这种方法的美妙之处在于,迁移既可以涉及架构更改,也可以涉及数据更改。

    我希望这能给你一些想法。

    【讨论】:

    • 感谢您的建议,但我们不能使用 GUI 解决方案,并且迁移表的方法不提供任何保证:有人可以更改某些内容而无需在该表中反映此更改。
    • 如果应用某些迁移的唯一方法是使用同时更新migration 表的工具怎么办?这可能会强制团队中的协议:)
    • 是的,这可以解决问题,但是团队很大,分散在多个国家/地区,权限由多人管理,技能水平也各不相同。很难遵守口头规则。
    • 如果允许太多人更改数据库架构,这几乎感觉像是一个组织问题。抱歉帮不上忙,试试这个相关链接:stackoverflow.com/questions/175451/…
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-06-09
    • 1970-01-01
    • 2014-07-08
    • 2011-08-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多