將現(xiàn)有應(yīng)用程序遷移到 Citus 有時(shí)需要調(diào)整 schema 和查詢以獲得最佳性能。 Citus 擴(kuò)展了 PostgreSQL 的分布式功能，但它不是擴(kuò)展所有工作負(fù)載的直接替代品。高性能 Citus 集群需要考慮數(shù)據(jù)模型、工具和所使用的 SQL 功能的選擇。

第一步是優(yōu)化現(xiàn)有的數(shù)據(jù)庫模式，以便它可以在多臺(tái)計(jì)算機(jī)上高效工作。

• 確定分布策略

選擇分布鍵(distribution key)

識(shí)別表的類型

• 為遷移準(zhǔn)備源表

添加分布鍵

回填新創(chuàng)建的列

接下來，更新應(yīng)用程序代碼和查詢以處理 schema 更改。

• 準(zhǔn)備申請(qǐng) Citus

建立開發(fā) Citus 集群

向查詢添加分布鍵

啟用安全連接

檢查跨節(jié)點(diǎn)流量

在開發(fā)環(huán)境中測(cè)試更改后，最后一步是將生產(chǎn)數(shù)據(jù)遷移到 Citus 集群并切換生產(chǎn)應(yīng)用程序。我們有技術(shù)可以最大限度地減少此步驟的停機(jī)時(shí)間。

• 遷移生產(chǎn)數(shù)據(jù)

小型數(shù)據(jù)庫遷移

大數(shù)據(jù)庫遷移

確定分布策略

選擇分布鍵

遷移到 Citus 的第一步是確定合適的distribution key 并相應(yīng)地規(guī)劃表分布。在多租戶應(yīng)用程序中，這通常是租戶的內(nèi)部標(biāo)識(shí)符。我們通常將其稱為“租戶 ID(tenant ID)”。用例可能會(huì)有所不同，因此我們建議您在此步驟中進(jìn)行徹底檢查。

如需指導(dǎo)，請(qǐng)閱讀以下部分：

• 確定應(yīng)用程序類型

https://docs.citusdata.com/en/v10.2/develop/app_type.html#app-type

• 選擇分布列

https://docs.citusdata.com/en/v10.2/sharding/data_modeling.html#distributed-data-modeling

我們很樂意幫助您檢查您的環(huán)境，以確保選擇了理想的 distribution key。為此，我們通常會(huì)檢查 schema 布局、更大的表、長(zhǎng)時(shí)間運(yùn)行和/或有問題的查詢、標(biāo)準(zhǔn)用例等。

確定表的類型

一旦確定了 distribution key，請(qǐng)查看 schema 以確定如何處理每個(gè)表以及是否需要對(duì)表布局進(jìn)行任何修改。我們通常建議使用電子表格進(jìn)行跟蹤，并創(chuàng)建了您可以使用的模板。

• https://docs.google.com/spreadsheets/d/1jYlc22lHdP91pTrb6s35QfrN9nTE1BkVJnCSZeQ7ZmI/edit

表格通常屬于以下類別之一：

• 準(zhǔn)備分發(fā)。 這些表已經(jīng)包含 distribution key，并準(zhǔn)備好分發(fā)。
• 需要回填。 這些表可以按所選 key 進(jìn)行邏輯分布，但不包含直接引用它的列。稍后將修改這些表以添加該列。
• 參考表。 這些表通常很小，不包含 distribution key，通常由分布式表連接，和/或在租戶之間共享。這些表中的每一個(gè)的副本將在所有節(jié)點(diǎn)上維護(hù)。常見示例包括國(guó)家代碼查找、產(chǎn)品類別等。
• 本地表。 這些通常不連接到其他表，并且不包含 distribution key。它們僅在 coordinator 節(jié)點(diǎn)上維護(hù)。常見示例包括管理員用戶查找和其他實(shí)用程序表。

考慮一個(gè)類似于 Etsy 或 Shopify 的示例多租戶應(yīng)用程序，其中每個(gè)租戶都是商店。這是簡(jiǎn)化 schema 的一部分：

(帶下劃線的項(xiàng)目是主鍵，斜體項(xiàng)目是外鍵。)

在此示例中，商店是自然租戶。在這種情況下，租戶 ID 是 store_id。在集群中分布表之后，我們希望與同一存儲(chǔ)相關(guān)的行一起駐留在同一節(jié)點(diǎn)上。

為遷移準(zhǔn)備源表

一旦確定了所需數(shù)據(jù)庫更改的范圍，下一個(gè)主要步驟就是修改應(yīng)用程序現(xiàn)有數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)。首先，修改需要回填的表，為 distribution key 添加一列。

添加分布鍵

在我們的店面示例中，stores 和 products 表有一個(gè) store_id 并準(zhǔn)備好分布。規(guī)范化后，line_items 表缺少商店 ID。如果我們想通過 store_id 分布，表需要這個(gè)列。

-- denormalize line_items by including store_id

ALTER TABLE line_items ADD COLUMN store_id uuid;

請(qǐng)務(wù)必檢查所有表中的分布列是否具有相同的類型，例如：不要混合 int 和 bigint。列類型必須匹配以確保正確的數(shù)據(jù)托管。

回填新創(chuàng)建的列

更新 schema 后，在添加該列的表中回填 tenant_id 列的缺失值。在我們的示例中，line_items 需要 store_id 的值。

我們通過從帶有訂單的 join 查詢中獲取缺失值來回填表：

UPDATE line_items
   SET store_id = orders.store_id
  FROM line_items
 INNER JOIN orders
 WHERE line_items.order_id = orders.order_id;

一次執(zhí)行整個(gè)表可能會(huì)導(dǎo)致數(shù)據(jù)庫負(fù)載過大并中斷其他查詢。相反，回填可以更慢地完成。一種方法是創(chuàng)建一個(gè)一次回填小批量的函數(shù)，然后使用 pg_cron 重復(fù)調(diào)用該函數(shù)。

• https://github.com/citusdata/pg_cron

-- the function to backfill up to one
-- thousand rows from line_items

CREATE FUNCTION backfill_batch()
RETURNS void LANGUAGE sql AS $$
  WITH batch AS (
    SELECT line_items_id, order_id
      FROM line_items
     WHERE store_id IS NULL
     LIMIT 10000
       FOR UPDATE
      SKIP LOCKED
  )
  UPDATE line_items AS li
     SET store_id = orders.store_id
    FROM batch, orders
   WHERE batch.line_item_id = li.line_item_id
     AND batch.order_id = orders.order_id;
$$;

-- run the function every quarter hour
SELECT cron.schedule('*/15 * * * *', 'SELECT backfill_batch()');

-- ^^ note the return value of cron.schedule

回填完成后，可以禁用 cron job：

-- assuming 42 is the job id returned
-- from cron.schedule

SELECT cron.unschedule(42);

準(zhǔn)備申請(qǐng) Citus

建立開發(fā) Citus 集群

在修改應(yīng)用程序以使用 Citus 時(shí)，您需要一個(gè)數(shù)據(jù)庫來進(jìn)行測(cè)試。按照說明設(shè)置您選擇的單節(jié)點(diǎn) Citus。

• https://docs.citusdata.com/en/v10.2/installation/single_node.html#development

接下來從應(yīng)用程序的原始數(shù)據(jù)庫中轉(zhuǎn)儲(chǔ) schema 的副本，并在新的開發(fā)數(shù)據(jù)庫中恢復(fù) schema。

# get schema from source db

pg_dump \
   --format=plain \
   --no-owner \
   --schema-only \
   --file=schema.sql \
   --schema=target_schema \
   postgres://user:pass@host:5432/db

# load schema into test db

psql postgres://user:pass@testhost:5432/db -f schema.sql

該 schema 應(yīng)在您希望分發(fā)的所有表中包含一個(gè)分發(fā)鍵(tenant id)。在 pg_dumping schema 之前，請(qǐng)確保您已完成上一節(jié)中的準(zhǔn)備源表以進(jìn)行遷移的步驟。

在鍵中包含分布列

Citus 不能強(qiáng)制唯一性約束，除非唯一索引或主鍵包含分布列。因此，我們必須在示例中修改主鍵和外鍵以包含 store_id。

• https://docs.citusdata.com/en/v10.2/reference/common_errors.html#non-distribution-uniqueness

下一節(jié)中列出的一些庫能夠幫助遷移數(shù)據(jù)庫 schema 以將分布列包含在鍵中。然而，下面是一個(gè)底層 SQL 命令示例，用于在開發(fā)數(shù)據(jù)庫中組合簡(jiǎn)單鍵：

BEGIN;

-- drop simple primary keys (cascades to foreign keys)

ALTER TABLE products   DROP CONSTRAINT products_pkey CASCADE;
ALTER TABLE orders     DROP CONSTRAINT orders_pkey CASCADE;
ALTER TABLE line_items DROP CONSTRAINT line_items_pkey CASCADE;

-- recreate primary keys to include would-be distribution column

ALTER TABLE products   ADD PRIMARY KEY (store_id, product_id);
ALTER TABLE orders     ADD PRIMARY KEY (store_id, order_id);
ALTER TABLE line_items ADD PRIMARY KEY (store_id, line_item_id);

-- recreate foreign keys to include would-be distribution column

ALTER TABLE line_items ADD CONSTRAINT line_items_store_fkey
  FOREIGN KEY (store_id) REFERENCES stores (store_id);
ALTER TABLE line_items ADD CONSTRAINT line_items_product_fkey
  FOREIGN KEY (store_id, product_id) REFERENCES products (store_id, product_id);
ALTER TABLE line_items ADD CONSTRAINT line_items_order_fkey
  FOREIGN KEY (store_id, order_id) REFERENCES orders (store_id, order_id);

COMMIT;

至此完成，上一節(jié)中的 schema 將如下所示：

(帶下劃線的項(xiàng)目是主鍵，斜體項(xiàng)目是外鍵。)

請(qǐng)務(wù)必修改數(shù)據(jù)流以向傳入數(shù)據(jù)添加鍵。

向查詢添加分布鍵

一旦 distribution key 出現(xiàn)在所有適當(dāng)?shù)谋砩?，?yīng)用程序就需要將它包含在查詢中。以下步驟應(yīng)使用在開發(fā)環(huán)境中運(yùn)行的應(yīng)用程序副本完成，并針對(duì) Citus 后端進(jìn)行測(cè)試。在應(yīng)用程序與 Citus 一起工作后，我們將了解如何將生產(chǎn)數(shù)據(jù)從源數(shù)據(jù)庫遷移到真正的 Citus 集群中。

• 應(yīng)更新寫入表的應(yīng)用程序代碼和任何其他攝取進(jìn)程以包含新列。
• 在 Citus 上針對(duì)修改后的 schema 運(yùn)行應(yīng)用程序測(cè)試套件是確定哪些代碼區(qū)域需要修改的好方法。
• 啟用數(shù)據(jù)庫日志記錄是個(gè)好主意。這些日志可以幫助發(fā)現(xiàn)多租戶應(yīng)用程序中的雜散跨分片查詢，這些查詢應(yīng)轉(zhuǎn)換為每租戶查詢。

支持跨分片查詢，但在多租戶應(yīng)用程序中，大多數(shù)查詢應(yīng)針對(duì)單個(gè)節(jié)點(diǎn)。對(duì)于簡(jiǎn)單的 select、update 和 delete 查詢，這意味著 where 子句應(yīng)按 tenant id 進(jìn)行過濾。Citus 然后可以在單個(gè)節(jié)點(diǎn)上有效地運(yùn)行這些查詢。

許多流行的應(yīng)用程序框架都有一些幫助程序庫，可以很容易地在查詢中包含租戶 ID：

• Ruby on Rails

https://docs.citusdata.com/en/v10.2/develop/migration_mt_ror.html

• Django

https://docs.citusdata.com/en/v10.2/develop/migration_mt_django.html

• ASP.NET

https://docs.citusdata.com/en/v10.2/develop/migration_mt_asp.html

• Java Hibernate

https://www.citusdata.com/blog/2018/02/13/using-hibernate-and-spring-to-build-multitenant-java-apps/

可以先將庫用于數(shù)據(jù)庫寫入(包括數(shù)據(jù)攝取)，然后再用于讀取查詢。例如，activerecord-multi-tenant gem 有一個(gè)只修改寫查詢的只寫模式(write-only mode)。

• activerecord-multi-tenant

https://github.com/citusdata/activerecord-multi-tenant

• write-only mode

https://github.com/citusdata/activerecord-multi-tenant#rolling-out-activerecord-multi-tenant-for-your-application-write-only-mode

其他(SQL原則)

如果您使用與上述不同的 ORM，或者更直接地在 SQL 中執(zhí)行多租戶查詢，請(qǐng)遵循這些一般原則。我們將使用我們之前的電子商務(wù)應(yīng)用程序示例。

假設(shè)我們想要獲取訂單的詳細(xì)信息。過濾租戶 ID 的分布式查詢?cè)诙嘧鈶魬?yīng)用程序中運(yùn)行效率最高，因此下面的更改使查詢更快(而兩個(gè)查詢返回相同的結(jié)果)：

-- before
SELECT *
  FROM orders
 WHERE order_id = 123;

-- after
SELECT *
  FROM orders
 WHERE order_id = 123
   AND store_id = 42; -- <== added

租戶 id 列不僅對(duì)插入語句有益，而且至關(guān)重要。插入必須包含租戶 id 列的值，否則 Citus 將無法將數(shù)據(jù)路由到正確的分片并引發(fā)錯(cuò)誤。

最后，在 join 表時(shí)，請(qǐng)確保也按租戶 ID 進(jìn)行過濾。例如，這里是如何檢查給定商店已售出多少“很棒的羊毛褲”：

-- One way is to include store_id in the join and also
-- filter by it in one of the queries

SELECT sum(l.quantity)
  FROM line_items l
 INNER JOIN products p
    ON l.product_id = p.product_id
   AND l.store_id = p.store_id
 WHERE p.name='Awesome Wool Pants'
   AND l.store_id='8c69aa0d-3f13-4440-86ca-443566c1fc75'

-- Equivalently you omit store_id from the join condition
-- but filter both tables by it. This may be useful if
-- building the query in an ORM

SELECT sum(l.quantity)
  FROM line_items l
 INNER JOIN products p ON l.product_id = p.product_id
 WHERE p.name='Awesome Wool Pants'
   AND l.store_id='8c69aa0d-3f13-4440-86ca-443566c1fc75'
   AND p.store_id='8c69aa0d-3f13-4440-86ca-443566c1fc75'

啟用安全連接

客戶端應(yīng)使用 SSL 連接到 Citus 以保護(hù)信息并防止中間人攻擊。事實(shí)上，Citus Cloud 拒絕未加密的連接。要了解如何建立 SSL 連接，請(qǐng)參閱使用 SSL 連接。

• SSL 連接

https://docs.citusdata.com/en/v10.2/cloud/security.html#cloud-ssl

檢查跨節(jié)點(diǎn)流量

對(duì)于龐大而復(fù)雜的應(yīng)用程序代碼庫，應(yīng)用程序生成的某些查詢通常會(huì)被忽略，因此不會(huì)對(duì)它們使用 tenant_id 過濾器。Citus 的并行執(zhí)行器仍然會(huì)成功執(zhí)行這些查詢，因此，在測(cè)試期間，這些查詢?nèi)匀浑[藏，因?yàn)閼?yīng)用程序仍然可以正常工作。但是，如果查詢不包含 tenant_id 過濾器，Citus 的執(zhí)行程序?qū)⒉⑿性L問每個(gè)分片，但只有一個(gè)會(huì)返回?cái)?shù)據(jù)。這會(huì)不必要地消耗資源，并且只有在遷移到更高吞吐量的生產(chǎn)環(huán)境時(shí)才會(huì)出現(xiàn)問題。

為了防止在生產(chǎn)中啟動(dòng)后才遇到此類問題，可以設(shè)置一個(gè)配置值來記錄命中多個(gè)分片的查詢。在正確配置和遷移的多租戶應(yīng)用程序中，每個(gè)查詢一次只能命中一個(gè)分片。

在測(cè)試期間，可以配置以下內(nèi)容：

-- adjust for your own database's name of course

ALTER DATABASE citus SET citus.multi_task_query_log_level = 'error';

如果 Citus 遇到將命中多個(gè)分片的查詢，它將出錯(cuò)。測(cè)試期間出錯(cuò)允許應(yīng)用程序開發(fā)人員查找和遷移此類查詢。

在生產(chǎn)啟動(dòng)期間，可以配置相同的設(shè)置來記錄，而不是錯(cuò)誤輸出：

ALTER DATABASE citus SET citus.multi_task_query_log_level = 'log';

配置參數(shù)部分包含有關(guān)此設(shè)置支持的值的更多信息。

• 配置參數(shù)部分

https://docs.citusdata.com/en/v10.2/develop/api_guc.html#multi-task-logging

遷移生產(chǎn)數(shù)據(jù)

此時(shí)，已更新數(shù)據(jù)庫 schema 和應(yīng)用程序查詢以與 Citus 一起使用，您已準(zhǔn)備好進(jìn)行最后一步。是時(shí)候?qū)?shù)據(jù)遷移到 Citus 集群并將應(yīng)用程序切換到其新數(shù)據(jù)庫了。

數(shù)據(jù)遷移路徑取決于停機(jī)時(shí)間要求和數(shù)據(jù)大小，但通常屬于以下兩類之一。

• 小型數(shù)據(jù)庫遷移
• 大數(shù)據(jù)庫遷移

小型數(shù)據(jù)庫遷移

對(duì)于可以容忍一點(diǎn)停機(jī)時(shí)間的較小環(huán)境，請(qǐng)使用簡(jiǎn)單的 pg_dump/pg_restore 進(jìn)程。以下是步驟。

從您的開發(fā)數(shù)據(jù)庫中保存數(shù)據(jù)庫結(jié)構(gòu)：

pg_dump \
   --format=plain \
   --no-owner \
   --schema-only \
   --file=schema.sql \
   --schema=target_schema \
   postgres://user:pass@host:5432/db

使用 psql 連接到 Citus 集群并創(chuàng)建 schema：

\i schema.sql

運(yùn)行您的 create_distributed_table 和 create_reference_table 語句。如果您收到有關(guān)外鍵的錯(cuò)誤，通常是由于操作順序所致。在分發(fā)表之前刪除外鍵，然后重新添加它們。

將應(yīng)用程序置于維護(hù)模式，并禁用對(duì)舊數(shù)據(jù)庫的任何其他寫入。

使用 pg_dump 將原始生產(chǎn)數(shù)據(jù)庫中的數(shù)據(jù)保存到磁盤：

pg_dump \
   --format=custom \
   --no-owner \
   --data-only \
   --file=data.dump \
   --schema=target_schema \
   postgres://user:pass@host:5432/db

使用 pg_restore 導(dǎo)入 Citus：

# remember to use connection details for Citus,
# not the source database
pg_restore  \
   --host=host \
   --dbname=dbname \
   --username=username \
   data.dump

# it'll prompt you for the connection password

測(cè)試應(yīng)用。

運(yùn)行。

大數(shù)據(jù)庫遷移(Citus Cloud)

較大的環(huán)境可以使用 Citus Warp 進(jìn)行在線復(fù)制。Citus Warp 允許您在更改發(fā)生時(shí)將更改從 PostgreSQL 源數(shù)據(jù)庫流式傳輸?shù)? Citus Cloud 集群。就好像應(yīng)用程序自動(dòng)寫入兩個(gè)數(shù)據(jù)庫而不是一個(gè)，除非具有完美的事務(wù)邏輯。Citus Warp 可與啟用了 logical_decoding 插件的 Postgres 9.4 及更高版本一起使用(只要您使用的是 9.4 或更高版本，Amazon RDS 就支持此功能)。

對(duì)于此過程，我們強(qiáng)烈建議您通過開 ticket、聯(lián)系我們?cè)?Slack 上的解決方案工程師之一或任何適合您的方法來聯(lián)系我們。為了進(jìn)行 warp，我們通過 VPC 對(duì)等或 IP 白名單將 Citus 集群的 coordinator 節(jié)點(diǎn)連接到現(xiàn)有數(shù)據(jù)庫，并開始復(fù)制。

以下是開始 Citus Warp 流程之前需要執(zhí)行的步驟：

1. 在目標(biāo) Citus 集群上復(fù)制 schema 結(jié)構(gòu)
2. 在源數(shù)據(jù)庫中啟用邏輯復(fù)制
3. 允許從 Citus coordinator 節(jié)點(diǎn)到源的網(wǎng)絡(luò)連接
4. 聯(lián)系我們開始復(fù)制

重復(fù) schema

將數(shù)據(jù)遷移到 Citus 的第一步是確保 schema 完全匹配，至少對(duì)于您選擇遷移的表而言。一種方法是針對(duì)您的開發(fā)數(shù)據(jù)庫(用于本地測(cè)試應(yīng)用程序的 Citus 數(shù)據(jù)庫)運(yùn)行 pg_dump --schema-only。在 coordinator Citus 節(jié)點(diǎn)上重放輸出。另一種方法是針對(duì)目標(biāo)數(shù)據(jù)庫運(yùn)行應(yīng)用程序遷移腳本。

您希望遷移的所有表都必須具有主鍵。相應(yīng)的目標(biāo)表也必須具有主鍵，唯一的區(qū)別是這些鍵也允許組合以包含分布列，如識(shí)別分布策略中所述。

還要確保在開始復(fù)制之前在集群中分布表，這樣數(shù)據(jù)就不必單獨(dú)放在 coordinator 節(jié)點(diǎn)上。

啟用邏輯復(fù)制

某些托管數(shù)據(jù)庫(例如 Amazon RDS)需要通過更改服務(wù)器配置參數(shù)來啟用復(fù)制。在 RDS 上，您需要?jiǎng)?chuàng)建一個(gè)新參數(shù)組，在其中設(shè)置 rds.logical_replication = 1，然后將參數(shù)組設(shè)為活動(dòng)參數(shù)組。應(yīng)用更改需要重新啟動(dòng)數(shù)據(jù)庫服務(wù)器，這可以安排在下一個(gè)維護(hù)時(shí)段。

如果您正在管理自己的 PostgreSQL 安裝，請(qǐng)將這些設(shè)置添加到 postgresql.conf：

wal_level = logical
max_replication_slots = 5 # has to be > 0
max_wal_senders = 5       # has to be > 0

需要重新啟動(dòng)數(shù)據(jù)庫才能使更改生效。

開放訪問網(wǎng)絡(luò)連接

在 Cloud 控制臺(tái)中，確定主機(jī)名(以 db.citusdata.com 結(jié)尾)。Dig 主機(jī)名以找到其 IP 地址：

dig +short <hostname> A

如果您使用的是 RDS，請(qǐng)編輯入站數(shù)據(jù)庫安全組以添加自定義 TCP 規(guī)則：

Protocol

• TCP

Port Range

• 5432

Source

• /32

這會(huì)將 Citus coordinator 節(jié)點(diǎn)的 IP 地址列入白名單以進(jìn)行入站連接。連接兩者的另一種方法是在它們的 VPC 之間建立對(duì)等互連。如果需要，我們可以幫助進(jìn)行設(shè)置。

開始復(fù)制

通過在 Citus Cloud 控制臺(tái)中打開 support ticket 與我們聯(lián)系。云工程師將使用 Citus Warp 連接到您的數(shù)據(jù)庫，以執(zhí)行初始數(shù)據(jù)庫轉(zhuǎn)儲(chǔ)、打開復(fù)制槽并開始復(fù)制。我們可以在遷移中包含/排除您選擇的表。

在復(fù)制的第一階段，如果數(shù)據(jù)庫處于寫入負(fù)載下，Postgres 預(yù)寫日志 (WAL) 可能會(huì)大幅增長(zhǎng)。在開始此過程之前，請(qǐng)確保源數(shù)據(jù)庫上有足夠的磁盤空間。我們建議 100GB 可用空間或總磁盤空間的 20%，以較大者為準(zhǔn)。一旦初始 dump/restore 完成并開始復(fù)制，那么數(shù)據(jù)庫將能夠再次歸檔未使用的 WAL 文件。

隨著 Warp 的進(jìn)行，請(qǐng)注意源數(shù)據(jù)庫上的磁盤使用情況。如果源和目標(biāo)之間存在數(shù)據(jù)類型不匹配，或其他意外的 schema 更改，則復(fù)制可能會(huì)停止。在長(zhǎng)時(shí)間停頓期間，復(fù)制槽可以在源上無限增長(zhǎng)，從而導(dǎo)致潛在的崩潰。

由于復(fù)制停滯的可能性，我們強(qiáng)烈建議在進(jìn)行 Citus warp 時(shí)盡量減少 schema 更改。如果需要進(jìn)行侵入式 schema 更改，您將需要停止 warp 并重試。

進(jìn)行侵入式 schema 更改的步驟：

1. 請(qǐng)求 Citus Cloud 工程師停止 warp。
2. 更改源數(shù)據(jù)庫上的 schema。
3. 更改目標(biāo)數(shù)據(jù)庫上的 schema。
4. 再次開始 warp。

切換到 Citus 并停止與舊數(shù)據(jù)庫的所有連接

當(dāng)復(fù)制趕上源數(shù)據(jù)庫的當(dāng)前狀態(tài)時(shí)，還有一件事要做。由于復(fù)制過程的性質(zhì)，序列值不會(huì)在目標(biāo)數(shù)據(jù)庫上正確更新。為了獲得正確的序列值，例如 id 列，您需要在打開對(duì)目標(biāo)數(shù)據(jù)庫的寫入之前手動(dòng)調(diào)整序列值。

一旦這一切完成，應(yīng)用程序就可以連接到新數(shù)據(jù)庫了。我們不建議同時(shí)寫入源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫。

當(dāng)應(yīng)用程序切換到新數(shù)據(jù)庫并且源數(shù)據(jù)庫上沒有發(fā)生進(jìn)一步的更改時(shí)，請(qǐng)?jiān)俅温?lián)系我們以刪除復(fù)制槽。遷移完成。