Dokumentasi / Tahan satu VM mati

Aplikasi + database tetap jalan walau satu VM mati

Banyak aplikasi berjalan di satu VM: web dan PostgreSQL bersebelahan. Praktis, tetapi bila VM itu mati, pelanggan ikut berhenti. Panduan ini memindahkan aplikasi seperti itu ke dua VM yang saling menggantikan, tanpa mengubah kode aplikasi.

Hasil uji

Uji 30 September 2026 dengan aplikasi kasir (POS) sederhana yang menulis satu transaksi per detik ke PostgreSQL 18, mode tanpa kehilangan data. VM utama berisi web dan database utama, lalu dimatikan paksa (cabut listrik) saat transaksi berjalan:

Kejadian	Hasil
VM A dimatikan paksa	VM B melayani transaksi lagi setelah ±21 detik (database pindah ke B dan pengunjung diarahkan ke B, otomatis).
Transaksi yang sudah tersimpan	0 hilang. Nomor urut total transaksi bersambung tanpa lompatan.
VM A dinyalakan lagi	A bergabung sendiri sebagai cadangan database, pengunjung kembali ke A. Satu permintaan sempat lambat, tidak ada data hilang.

Selama ±21 detik itu kasir melihat galat dan perlu mengulang transaksi. Transaksi yang sudah dinyatakan berhasil tidak pernah hilang.

Susunan: 2 VM + 1 saksi kecil

VM	Isi	Ukuran
A	Aplikasi web + PostgreSQL (utama)	Seperti VM sekarang
B	Salinan aplikasi web + PostgreSQL (cadangan yang selalu tersalin)	Sama dengan A
C (saksi)	Tanpa data. Hanya ikut memilih siapa utama, agar tidak pernah ada dua utama.	Kecil (1 vCPU, 1 GB)

Letakkan A dan B di lokasi atau penyedia berbeda, agar gangguan satu pusat data tidak mematikan keduanya. C sebaiknya di lokasi ketiga.
A dan B saling bertukar peran otomatis. Saat A kembali, ia menyusul datanya sendiri; tidak perlu menyalin apa pun.
Satu VM hanya bisa ikut satu klaster, termasuk sebagai saksi. Jadi setiap pelanggan yang dipisah per VM butuh saksinya sendiri (boleh VM terkecil).
VM lama yang sekarang dipakai bisa dijadikan saksi C: database lamanya tetap dipakai sebagai sumber salinan (langkah 3), lalu aplikasinya dimatikan setelah pindah.

Langkah

1. Sambungkan VM ke Saka

Siapkan VM A dan B (dan C bila tidak memakai VM lama), lalu pasang agent Saka di tiap VM, termasuk VM lama. Lihat Mulai. Setiap VM butuh IP publik dan port UDP 51871 terbuka antar VM (Saka membukanya sendiri bila firewall dikelola Saka).

2. Buat klaster PostgreSQL

Buka Database, tekan + Buat klaster database, pilih PostgreSQL.
Server data: A dan B. Saksi: C.
Mode: Tanpa kehilangan data (sinkron). Wajib untuk transaksi uang.
Versi: samakan atau lebih baru dari PostgreSQL yang dipakai sekarang (bawaan 18).

Klaster biasanya siap dalam 1 sampai 5 menit; Anda dikabari lewat Telegram.

3. Pindahkan database lama

Hentikan aplikasi lama agar tidak ada transaksi baru selama penyalinan (mis. saat toko tutup).
Di halaman klaster, kartu Pindahkan database lama ke klaster: pilih VM lama, tempel alamat database lama seperti di konfigurasi aplikasinya, mis. postgresql://kasir:[email protected]:5432/kasir, lalu tekan Salin ke klaster.
Saka menyalin semuanya (tabel, indeks, view, urutan nomor, ekstensi) dalam satu transaksi, lalu membandingkan jumlah baris setiap tabel. Hasil uji: 200.500 baris dalam 3 detik, jumlah sama persis.

Bila gagal di tengah jalan, klaster tidak berubah dan database lama tidak pernah disentuh. Pesan galat menyebut penyebabnya (sandi salah, database lama tidak menjawab, pg_hba.conf, versi, ekstensi).
Sandi database lama hanya diteruskan ke VM lama untuk menyalin, tidak disimpan Saka.
Lewat API: POST /api/v1/database/<id>/impor {"server_id", "sumber", "database"}. Lewat agent AI: database_pindahkan_lama.

4. Pasang aplikasi di A

Buka Situs, Buat situs, Aplikasi dari Git, pilih server A. Repo dengan Dockerfile dipakai apa adanya; lihat Aplikasi dari Git.
Di halaman klaster, kartu Sambungkan server aplikasi: pasang proxy di A. Proxy ini selalu menuju database utama, di VM mana pun ia berada.
Isi variabel aplikasi DATABASE_URL dengan alamat proxy untuk kontainer, mis. postgresql://postgres:[email protected]:15432/kasir?sslmode=require (port tampil di kartu; tekan Tampilkan sandi untuk sandinya).
Deploy, lalu buka aplikasinya dan pastikan data lama tampil.

Aplikasi harus menyambung ulang ke database bila koneksinya putus (hampir semua framework melakukannya: Rails, Laravel, Django, Prisma, node-postgres dengan pool). Tanpa itu aplikasi terus galat setelah database pindah sampai dimulai ulang.

5. Tambah lokasi kedua di B

Di halaman aplikasi, kartu Dua lokasi, tekan Tambah lokasi kedua dan pilih B. B membangun commit yang sama dengan variabel yang sama; proxy database di B dipasang otomatis dengan port yang sama.
Ubah DNS domain aplikasi menjadi CNAME ke alamat load balancer yang tampil di kartu (mis. lbxxxx.lb.saka.work). Domain tanpa awalan (mis. toko.com) butuh penyedia DNS yang mendukung CNAME flattening, mis. Cloudflare; atau pakai app.toko.com.
HTTPS dibuat di kedua VM. Setiap deploy, rollback, dan perubahan variabel di A ikut diterapkan di B.

6. Uji sendiri (disarankan)

Di luar jam ramai, matikan VM A dari panel penyedia cloud. Dalam ±30 detik aplikasi terbuka lagi dari B dengan data lengkap. Nyalakan A kembali; A bergabung sendiri. Anda dikabari lewat Telegram di setiap langkah.

Yang perlu diketahui

Berkas unggahan (foto produk, lampiran) di disk VM tidak ikut tersalin untuk aplikasi Git. Simpan di penyimpanan S3 (mis. Cloudflare R2, DigitalOcean Spaces) atau di database.
Worker dan cron hanya jalan di A agar tidak berjalan dua kali. Selama A mati, job latar belakang menunggu sampai A hidup; transaksi web tetap jalan di B.
Pengunjung yang DNS-nya masih tersimpan (±30 detik) bisa sempat diarahkan ke A yang mati sebelum pindah ke B.
Mode sinkron menambah sekitar satu kali jeda jaringan antara A dan B pada setiap tulisan (beberapa milidetik di kota yang sama, puluhan milidetik antar negara).
Database MySQL/MariaDB belum bisa dipindah dengan tombol ini; klaster MariaDB tidak mendukung web dan database di VM yang sama.

Rincian teknis: Database terkelola dan Situs di dua lokasi.

Dasar

Fitur

Developer & AI

Kepercayaan