Topik 12
Kegagalan pada Sistem Basis Data Terdistribusi
Jenis kegagalan, pengaruhnya terhadap pemulihan, dan protokol komitmen dua fase.
Kemampuan akhir yang diharapkan. Memahami kejadian kegagalan di lingkungan pemrosesan data terdistribusi.
Jenis kegagalan
| Jenis | Ada di sistem terpusat? | Dampak khas pada DDBMS |
|---|---|---|
| Kegagalan transaksi | Ya | Rollback lokal; subtransaksi lain harus ikut dibatalkan |
| Sistem crash | Ya | Log dipakai untuk redo/undo saat situs pulih |
| Kesalahan media | Ya | Pemulihan dari backup dan arsip log |
| Kehilangan pesan | Tidak | Koordinator timeout dan menganggapnya suara abort |
| Kegagalan jalur komunikasi | Tidak | Situs tidak terjangkau meski hidup |
| Kegagalan situs | Tidak | Subtransaksi menggantung di situs itu |
| Partisi jaringan | Tidak | Sistem terbelah menjadi dua kelompok yang saling tak terlihat |
Protokol komitmen dua fase
| Fase | Koordinator | Peserta |
|---|---|---|
| 1 — Voting | Tulis begin_commit, kirim PREPARE ke semua peserta | Tulis catatan ready, balas VOTE-COMMIT atau VOTE-ABORT |
| 2 — Decision | Tulis keputusan, kirim GLOBAL-COMMIT / GLOBAL-ABORT | Terapkan keputusan, kirim ACK, tulis end_of_transaction |
Begitu peserta menulis catatan ready, ia menyerahkan hak memutuskan kepada koordinator. Jika koordinator jatuh tepat setelah itu, peserta tidak boleh commit maupun abort sendiri — ia terblokir, dan kunci yang dipegangnya ikut menahan transaksi lain.
Protokol terminasi kooperatif
Peserta yang menggantung boleh bertanya ke peserta lain. Bila ada peserta yang sudah tahu keputusan, keputusan itu disalin. Bila semua peserta sama-sama berada di keadaan READY, tidak ada informasi baru dan semuanya tetap terblokir — inilah batas kemampuan 2PC.
Yang terjadi di Oracle
Oracle menjalankan 2PC secara otomatis begitu satu transaksi menyentuh lebih dari satu basis data lewat database link. Tidak ada perintah khusus — cukup COMMIT. Transaksi yang menggantung muncul di DBA_2PC_PENDING dengan STATE bernilai prepared.
SELECT local_tran_id, global_tran_id, state, mixed, host
FROM dba_2pc_pending
ORDER BY fail_time;
-- Hanya setelah keputusan koordinator dipastikan:
COMMIT FORCE '1.15.1234';
-- atau ROLLBACK FORCE '1.15.1234';
EXEC DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.15.1234');Memaksa keputusan yang berbeda dari keputusan koordinator menghasilkan mixed outcome — kolom MIXED bernilai yes, sebagian situs commit dan sebagian rollback. Basis data kehilangan konsistensi global dan harus diperbaiki manual.
Coba di terminal
Kueri di bawah memperagakan konsep topik ini pada data sungguhan. Tekan ▶ Jalankan untuk membukanya di Terminal SQL, lalu ubah sesuka hati — sesi terminal adalah salinan pribadi di peramban Anda.
Two-phase commit sukses
Dua situs ditulis, COMMIT memicu PREPARE → VOTE → GLOBAL-COMMIT. terdistribusi
UPDATE pasien@jakarta SET no_hp = '081200000001' WHERE id_pasien = 1;
UPDATE pasien@bandung SET no_hp = '081200000003' WHERE id_pasien = 3;
COMMIT;Satu situs VOTE-ABORT
Kegagalan satu peserta membatalkan transaksi di semua situs. terdistribusi galat disengaja: ORA-02091
\gagal bandung
UPDATE pasien@jakarta SET penyakit = 'X' WHERE id_pasien = 1;
UPDATE pasien@bandung SET penyakit = 'X' WHERE id_pasien = 3;
COMMIT;DBA_2PC_PENDING dan COMMIT FORCE
Transaksi ragu-ragu diselesaikan manual oleh DBA, persis seperti di Oracle. terdistribusi galat disengaja: ORA-02054
\gagal koordinator
DELETE FROM daftar@jakarta WHERE id_daftar = 1;
DELETE FROM daftar@surabaya WHERE id_daftar = 9;
COMMIT;
SELECT local_tran_id, state FROM dba_2pc_pending;Jalankan sendiri
Simulator 2PC & 3PC
Injeksi kegagalan koordinator, peserta, dan partisi jaringan — lalu lihat siapa yang terblokir.
Studi Kasus Kependudukan
Skripsi Oracle XE + MySQL lewat ODBC: NIK ganda yang lolos UNIQUE lokal, dan mengapa gateway tidak bisa 2PC.
Sumber: Modul 1 (RPS pekan 12); Modul 6 bagian Transparansi Kegagalan