Halo, kami telah menemukan akar penyebab dari insiden ini. Berikut adalah jawaban poin demi poin:
1. Apakah ada pemeliharaan/drain node antara 13:52–14:01? Mengapa restart terjadi di luar waktu yang dijadwalkan?
Ya. Pada hari itu, antara 13:38–13:52 (UTC), klaster ap-east-2 (AWS) melakukan rotasi node: beberapa node dasar dihentikan (catatan acara menunjukkan "node tidak lagi ada di penyedia cloud"), dan node baru segera dimulai untuk mengambil alih. Aplikasi dan Pod PostgreSQL Anda dijadwalkan ulang ke node baru yang baru bergabung karena node asli dihapus. Jadi, restart ini tidak ada hubungannya dengan restart terjadwal pukul 06:00 Anda; ini adalah penjadwalan ulang yang tidak terduga akibat rotasi node platform.
2. Mengapa DB butuh waktu sekitar 68 menit untuk pulih? Apakah ini terkait dengan kegagalan alokasi IP aws-cni?
Ya, ada dua penyebab utama, dan keduanya saling terkait:
- Saat node baru bergabung, aws-cni belum menyiapkan jaringan (pool ENI/IP), dan pada saat yang sama ada banyak Pod yang dijadwalkan ulang masuk secara bersamaan (puluhan layanan di seluruh klaster mengalami "failed to assign an IP address" pada waktu yang sama), yang menyebabkan kemacetan alokasi IP dan membuat Pod terjebak tanpa jaringan.
- Node baru adalah "cold node" tanpa cache image, sehingga perlu menarik ulang image. Image PostgreSQL (postgres:18) Anda tercatat membutuhkan waktu sekitar 1 jam 7 menit untuk ditarik (termasuk waktu tunggu), dan image aplikasi sekitar 24 menit (termasuk waktu tunggu). Dua periode tunggu inilah penyebab utama gangguan berlangsung hingga sekitar 68 menit.
Dengan kata lain, ini bukan masalah pada DB itu sendiri (CPU/memori yang Anda berikan juga membuktikan tidak ada OOM), melainkan proses pemulihan yang terlalu lama akibat "penjadwalan ulang + alokasi jaringan + penarikan ulang image".
3. Apakah PostgreSQL memiliki jadwal restart dari sisi platform atau kesalahan konfigurasi?
Tidak. Restart DB kali ini adalah penjadwalan ulang Pod yang disebabkan oleh rotasi node di atas (nama Pod berubah, image ditarik ulang), bukan restart terjadwal in-place. Layanan Anda tidak memiliki pengaturan restart terjadwal dari sisi platform, jadi tidak perlu ada yang dimatikan.
4. Apakah ke depannya ada pemberitahuan sebelumnya atau halaman status yang bisa dilanggan untuk pemeliharaan seperti ini?
Acara platform dapat dilihat di halaman status https://status.zeabur.com. Saat ini kami menyediakan langganan RSS (https://status.zeabur.com/feed, yang dapat ditambahkan ke pembaca RSS atau alat notifikasi otomatis). Selain itu, kami telah melaporkan masalah kemacetan alokasi IP aws-cni selama rotasi node dan waktu pemulihan yang lama akibat penarikan ulang image pada cold node kepada tim infrastruktur. Kami akan meningkatkan proses drain dan pemanasan IP selama rotasi node untuk mengurangi waktu henti dalam situasi serupa di masa mendatang.
Saran tambahan:
Akar penyebab gangguan ini adalah node di "klaster bersama" akan berotasi seiring dengan pemeliharaan platform, sehingga Pod Anda terpaksa dijadwalkan ulang ke node baru yang baru menyala. Jika layanan Anda memerlukan stabilitas koneksi yang tinggi, Anda dapat mempertimbangkan untuk beralih ke Dedicated Server: Dedicated server adalah node independen penyewa tunggal yang tidak disertakan dalam rotasi node klaster bersama secara keseluruhan, yang secara signifikan mengurangi dampak penjadwalan ulang yang tidak terduga dan waktu pemulihan yang lama; selain itu, karena sudah ada cache image di node, pemulihan setelah restart juga jauh lebih cepat. Jika Anda tertarik, saya dapat membantu Anda mengevaluasi spesifikasi yang sesuai.
