Sign in Subscribe

Zero downtime database migrasi di KMK

Apa itu zero downtime deploys ?

Di KMK, kita menerapkan “zero downtime deploys”. Maksudnya adalah ketika aplikasi di upgrade, user masih dapat mengakses situs kita seperti biasa, karena ketika proses upgrade kita membuat aplikasi versi lama dan versi baru untuk berfungsi pada waktu yang sama.

ZERO DOWNTIME DATABASE MIGRASI

Beberapa hal yang harus dipastikan ketika menjalankan migrasi database:

Database yang dipakai di KMK untuk semua aplikasi adalah PostgreSQL. Dengan menerapkan aturan berikut, kedua poin diatas dapat dicapai.

0. KALAU PAKAI RAILS — DISABLE PREPARED STATEMENTS

Oleh karena bug Rails ini, semua perubahan di database (walaupun hanya penambahan column) akan menyebabkan error. Karena itu, kita selalu set prepared_statement: false di database.yml untuk Rails apps.

1. MENAMBAH COLUMN KEPADA TABLE YANG SUDAH ADA

Jika kolom tidak memiliki “default value” Ini cukup gampang — dan bisa ditambahkan seperti biasa. Kalau ada “default value”, maka harus ditambahkan dalam migrasi seterusnya, hanya setelah kolom ditambahkan.

2. MENAMBAH INDEKS KEPADA TABLE YANG SUDAH ADA

a. INDEKS B-TREE BIASA Ini harus dilakukan dengan memakai feature “concurrently” Postgres supaya ia tidak lock table dan memperlambat query lain. b. INDEKS UNIQUE Indeks UNIQUE harus ditambah menggunakan feature concurrently seperti di atas. Setelah indeks ditambah, selanjutnya tambahkan CONSTRAINT. Sebagai contoh: CREATE UNIQUE INDEX CONCURRENTLY ktp_unique ON table_gede(ktp); ALTER TABLE table_gede ADD CONSTRAINT ktp UNIQUE USING INDEXktp_unique;

3. MENDELETE COLUMN PADA TABLE YANG SUDAH ADA

Ini harus dilakukan dalam 2 deploy yang berbeda. a. Pastikan kolom tidak dipakai di kode lagi. Jika memakai Rails (atau framework lain yang mungkin cache column) pastikan kolom tersebut tidak lagi di cache oleh ORM. Di Rails, hal ini bisa dibuat seperti berikut:

#!ruby
class Orang
  def self.columns
    super.reject { |c| c.name == "tgl_lahir" }
  end
end

b. Setelah kode di atas di deploy, pada deploy seterusnya hanya kolom itu yang dihapus melewati migrasi.

4. MENUKAR COLUMN, SAMA ADA RENAME ATAU TUKAR TIPE

Jangan mengubah kolom asal menggunakan “ ALTER TABLE… “. Akan tetapi tambahkan kolom baru yang akan menggantikan kolom lama. Ini harus dilakukan dalam 3 deploy yang berbeda. a. Dalam deploy pertama

  • Tambahkan migrasi untuk menambah kolom baru, seperti menggunakan nama baru atau tipe baru.
  • Modify kode aplikasi untuk mengupdate kedua kolom lama dan baru.
  • Setelah deploy lengkap, copy semua value dari kolom lama ke kolom baru, seperti menggunakan task atau melewati sql manual. Pastikan proses ini tidak berdampak besar sehingga database jadi lemot.

b. Dalam deploy kedua, pastikan kode aplikasi tidak lagi menggunakan kolom lama. Ikuti aturan 3(a) di atas untuk memastikan kolom tersebut tidak di cache ORM lagi. c. Dalam deploy ketiga, masukkan kode untuk migrasi yang akan menghapus kolom lama.

KESIMPULAN

Zero downtime migrations memerlukan perencanaan dari engineer untuk memastikan semuanya berjalan lancar. Dengan mengikuti aturan di atas, diharapkan proses ini menjadi lebih gampang.

Reference:

Read next