Kasus penemuan race condition di Aurora RDS

• Kasus ketika bug race condition yang terjadi di AWS Aurora RDS diverifikasi secara eksperimental dan penyebabnya dikonfirmasi oleh AWS
• Saat Hightouch memperluas sistem pemrosesan event, mereka menemukan gejala kegagalan perpindahan instance penulis selama proses failover Aurora
• Hasil analisis log menunjukkan bahwa dua instance melakukan operasi tulis secara bersamaan, yang menyebabkan konflik pada lapisan penyimpanan dan penghentian proses
• AWS secara resmi mengonfirmasi bahwa penyebabnya adalah promosi writer baru sebelum penurunan peran writer lama selesai akibat masalah pemrosesan sinyal internal
• Kasus ini menekankan pentingnya kontrol konkurensi pada sistem terdistribusi berskala besar dan perlunya prosedur penghentian penulisan saat failover

---

Latar belakang

• Pada 20 Oktober 2025, terjadi gangguan di region AWS us-east-1 akibat bug race condition pada sistem manajemen DNS
• Karena hal ini, backlog pemrosesan event di Hightouch meningkat tajam hingga mencapai batas sistem
• Untuk mengamankan throughput, pada 23 Oktober dilakukan upgrade instance Aurora RDS, dan dalam proses ini ditemukan bug race condition baru

Arsitektur sistem event Hightouch

• Sistem yang bertanggung jawab untuk pengumpulan dan pengiriman event terdiri dari Kubernetes, Kafka, dan Postgres (Aurora)
• Postgres digunakan sebagai antrean metadata batch, memproses 500 ribu event per detik dalam waktu kurang dari 1 detik
• Aurora PostgreSQL terdiri dari instance khusus tulis (primary), instance khusus baca (replica), dan lapisan penyimpanan bersama

Rencana upgrade

• Menambahkan instance baca → meng-upgrade reader yang ada dan memberinya prioritas failover → menjalankan failover → meng-upgrade writer lama → menghapus reader sementara
• Prosedur ini adalah metode yang dijelaskan dalam dokumentasi AWS, dan merupakan prosedur yang telah diverifikasi melalui uji beban di lingkungan staging

Percobaan upgrade dan munculnya masalah

• Pada 23 Oktober pukul 16:39 EDT, setelah failover dijalankan, muncul gejala writer lama kembali menjadi primary
• Pada dua percobaan, hasilnya sama, dan pada sebagian layanan muncul error tidak bisa menulis (DatabaseError: cannot execute UPDATE in a read-only transaction)
• Hasil analisis log mengonfirmasi adanya log bahwa dua instance melakukan operasi tulis secara bersamaan lalu berhenti karena konflik penyimpanan

Penyebab race condition

• Selama proses failover Aurora, race condition terjadi di antara langkah 3 (penurunan peran writer lama) dan langkah 4 (promosi writer baru)
• Akibatnya, dua instance secara bersamaan memiliki hak tulis dan saling bertabrakan
• Ketika dicoba lagi dalam kondisi trafik tulis dihentikan, failover selesai dengan normal sehingga hipotesis race condition terbukti

Konfirmasi dan respons AWS

• Setelah peninjauan internal, AWS mengonfirmasi bahwa penyebabnya adalah kesalahan pemrosesan sinyal penurunan writer, dan tidak terkait dengan konfigurasi atau pola trafik Hightouch
• Perbaikan telah dimasukkan ke dalam roadmap, dan sebagai langkah sementara AWS merekomendasikan menghentikan penulisan selama failover

Tindakan akhir

• Hightouch menyelesaikan upgrade klaster, dan
  • menambahkan prosedur penghentian penulisan sebelum failover yang disengaja
  • memperkuat pemantauan perubahan peran writer
  • memperbarui manual operasional (playbook)

Pelajaran utama

1. Perlu kesiapan pemulihan untuk menghadapi transisi status tak terduga selama migrasi
2. Menjamin observability adalah kunci untuk mendeteksi masalah
3. Pentingnya desain yang meminimalkan dampak antar komponen sistem terdistribusi
4. Perlu menyadari perbedaan antara lingkungan pengujian dan lingkungan produksi nyata

Tidak ada informasi tambahan di sumber asli

[GN⁺]

Komentar Hacker News

• Dari tulisan ini, terlihat seolah-olah selama failover manual, aplikasi akan selalu gagal jika mencoba mempertahankan trafik tulis seperti biasa
  Namun ini memunculkan beberapa pertanyaan. Mengapa pengguna Aurora lain tidak selalu mengalami masalah ini, apakah mungkin AWS tidak mengetahuinya, dan jika mereka tahu, mengapa ini tidak ditangani sebagai isu darurat tingkat P0
  Mungkin ada kondisi halus seperti status transaksi yang sedang berjalan atau timeout yang ikut berperan

  • Berdasarkan pengalaman menangani masalah serupa di Azure, banyak orang mengalaminya tetapi karena selesai setelah restart, mereka sering membiarkannya begitu saja. Menemukan akar masalahnya sulit, dan proses analisis bersama vendor terlalu menyakitkan sehingga kebanyakan orang menyerah
  • Kami juga mengonfirmasi masalah yang sama saat bekerja sama dengan AWS. Pola trafiknya tidak istimewa, dan masalah ini tidak bisa direproduksi di region lain. Ini kemungkinan besar adalah cacat mendasar pada mekanisme failover Aurora
  • Dulu saya pernah mengalami bug pada kombinasi Python + MySQL di mana SELECT ... FOR UPDATE gagal secara diam-diam dan transaksi beralih ke mode autocommit. Tidak ada yang peduli jadi saya seperti bicara sendiri, lalu beberapa bulan kemudian orang lain menghubungi saya karena mengalami masalah yang sama. Akhirnya memang diperbaiki, tetapi saat itu saya sudah tidak mengikuti lagi
    Tautan terkait: pertanyaan Stack Overflow
  • AWS hampir tidak pernah membuka informasi internal. Karena mereka tidak memberi tahu detail di atas level API, rasanya mereka menganggap masalah seperti ini sebagai kasus langka lalu melanjutkan saja
  • Sebagian masalahnya mungkin disebabkan oleh cara aplikasi merespons failover yang dibalik (reverted failover). Cache tampaknya rusak sehingga terus mencoba menulis ke primary yang salah. Bahkan jika kegagalan seperti ini sering terjadi, karena berhasil setelah retry, pengguna mungkin tidak melaporkannya ke AWS sehingga AWS tidak menyadarinya

• Saya sudah beberapa kali melihat perilaku tak terduga di Aurora PostgreSQL
  Terutama selama Zero Downtime Patching (ZDP), status sesi dipertahankan secara keliru sehingga bahkan query sederhana pun dibatalkan jauh lebih cepat daripada statement_timeout
  Dugaan saya, saat klien tersambung ulang, Aurora mewarisi status timer lama dari sesi sebelumnya sehingga query langsung dibatalkan

• Kami juga rutin melakukan failover di lingkungan dengan trafik tulis yang sangat tinggi, tetapi kami mengoperasikannya dengan stabil melalui proses otomatis menggunakan AWS JDBC wrapper

  • Dalam praktiknya, lapisan penyimpanan Aurora mencegah pelanggaran ACID, jadi integritas data tetap terjaga

• Orang membayar dan memakai Aurora dengan keyakinan bahwa layanan ini akan menjaga invarians dasar seperti ini, jadi mengejutkan melihat masalah semacam ini terjadi

  • Namun lapisan penyimpanannya sendiri bekerja dengan benar dengan memblokir penulisan bersamaan

• Dari log dan penjelasan AWS, hipotesis penulis asli tampaknya keliru
  Tampaknya setelah promosi gagal, proses pemantauan eksternal mendeteksi ketidaksesuaian status cluster dan memaksa penghentian (kill -9). Pesan terkait subsistem penyimpanan muncul setelah itu

• Saya ingin bertanya soal perbandingan performa antara Aurora dan RDS Postgres.
  Jika tidak membutuhkan multi-AZ atau failover cepat, apakah mungkin mendapatkan performa lebih baik di RDS dengan konfigurasi gp3 64k IOPS? Aurora tampaknya terutama lambat untuk insert dan mahal. Benchmark juga sulit dipercaya karena sering tidak menjelaskan konfigurasi RDS dengan jelas

  • Kami mendapatkan performa yang lebih baik dan biaya lebih rendah di Aurora PG 14 dengan konfigurasi 1 writer + 1~2 reader. Aurora diuntungkan karena biaya storage dihitung di level cluster, bukan per instance.
    Selain itu, tidak perlu melakukan provisioning IOPS secara langsung dan mendapatkan sekitar 80k IOPS.
    Ada juga dua model biaya IO, yaitu pay-per-IO untuk beban rendah dan mode tarif tetap yang lebih cocok untuk workload dengan IO tinggi.
    Sebagai catatan, Serverless hampir selalu tidak ekonomis. Hanya berguna jika ada waktu puncak yang singkat
  • Tim kami mengalami lonjakan biaya I/O di Aurora Postgres RDS. Hanya dengan beberapa fuzzy query, tagihan bulanan melampaui $3.000, padahal seharusnya di bawah $100
  • Kami kecewa dengan biaya, performa, dan latensi Aurora, dan akhirnya pindah ke PostgreSQL on-premise
  • Berdasarkan Aurora MySQL, untuk menyamai IOPS yang sama di RDS diperlukan biaya yang jauh lebih mahal
  • Aurora tidak menggunakan EBS, dan tipe storage maupun latensinya tidak bisa dipilih. Anda hanya bisa memilih model penagihan IO

• Ini menunjukkan dengan jelas “model balok Lego” yang sering dibicarakan para engineer AWS
  Lapisan penyimpanan dirancang benar-benar independen, sehingga meskipun layanan di atasnya gagal, konsistensi data tetap terjamin. Menurut saya ini contoh bagus dari engineering AWS

• Katanya AWS merekomendasikan “hentikan penulisan selama failover”, jadi saya penasaran apakah nomor kasus terkait bisa dibagikan

  • Kami juga menggunakan Aurora MySQL, jadi saya ingin memastikan apakah rekomendasi ini juga berlaku untuk MySQL

• Syukurlah saya jadi tahu bahwa bukan cuma saya yang mengalami masalah seperti ini

  • AWS Support awalnya membantah dengan mengatakan ini karena replication lag, tetapi mereka menilai berdasarkan metrik lama dari 24 jam sebelumnya. Saya benar-benar ingin tahu kegagalan apa yang terjadi, dan mengapa ini tidak bisa direproduksi di region lain

• Arsitektur pemisahan compute-storage Aurora menarik
  Hyperscale milik MSSQL juga memiliki struktur serupa, dan itu adalah hampir satu-satunya produk Azure yang menurut saya benar-benar layak dipakai