零停機遷移

在19頁應用狀態的章節指出你可以對短暫狀態在應用程式外部儲存狀態資料達成零停機。從一個關連式資料庫觀點,在藍綠發布零停機,需要新舊架構版本同時連續工作。

架構版本必須在一連串的發行中完全的相容。意即我們不能建立破壞的資料庫遷移。破壞在這意味我們不能遺失任何資料我們不能引發任何可能潛在造成資料遺失的狀態。

假如在我們的資料架構中需要改一個列名字,傳統的方式我們會發行一個如下的DDL描述

ALTER TABLE customers RENAME COLUMN wrong TO correct;

在零停機遷移概念,不允許這描述有以下三個原因

  • 他是破壞性:你遺失了目前存在舊列的資料
  • 他是不與現行版本相容只有新版本知道如何操作它
  • 他可能花長時間執行:ㄧ些資料管理系統必須鎖住整個表格去執行這個描述,導致應用停機

取代只發行單個描述去達成一個單列改名。我們將會習慣去分割這個大改變至多告小改變。我們再次使用這個寶寶步驟概念去增加我們軟體開發管線品質。

這前述DDL描述可以重構為下列小步驟,每個被執行於多重循序軟體版本:

ALTER TABLE customers ADD COLUMN correct VARCHAR(20);

UPDATE customers SET correct=wrong

WHERE id BETWEEN 1 AND 100;

UPDATE customers SET correct=wrong

WHERE id BETWEEN 101 AND 200;

ALTER TABLE customers DELETE COLUMN wrong;

這第一個印象你正有很多工作即使最簡單資料庫重構一部分,也許多但這是有可能自動化的。幸運的我們有軟體可以幫忙處理,可以在我們的軟體開發管線執行所有的自動化機制。

你總是可以退至前一版因為我們從未產生任何破壞描述。你可以檢查應用狀態在執行資料庫遷移後。你總是可以保留現在版本替代新版本,如果任何資料對你而言不對。

results matching ""

    No results matching ""