Arsitektur tiga pusat data di dua wilayah mendistribusikan instans PolarDB-X ke dua pusat data utama dalam satu wilayah dan satu pusat data sekunder di wilayah kedua. Topologi ini menyediakan high availability lintas wilayah dengan Recovery Point Objective (RPO) nol, memenuhi persyaratan pemulihan bencana Level 4 hingga Level 6 di industri keuangan.
Topik ini menjelaskan cara kerja arsitektur tersebut, mekanisme yang mendasarinya, serta operasi yang perlu Anda kelola.
Versi yang didukung
Arsitektur ini memerlukan Apsara Stack DBStack V1.2.1 atau yang lebih baru.
Tingkat pemulihan bencana
| Level | Recovery time objective (RTO) | RPO | Persyaratan penyebaran |
|---|---|---|---|
| Level 4 | ≤ 30 menit | 0 | Zone-disaster recovery atau geo-disaster recovery |
| Level 5 | ≤ 15 menit | 0 | Geo-disaster recovery, setidaknya satu replika di wilayah remote |
| Level 6 | ≤ 1 menit | 0 | Geo-disaster recovery, setidaknya dua replika di wilayah remote |
PolarDB-X menggunakan lima replika berdasarkan protokol konsensus mayoritas Paxos untuk mencapai RPO = 0 lintas wilayah. Ketika pusat data utama mengalami kegagalan total, instans sekunder remote memulihkan layanan dalam batasan RTO yang ditentukan.
Cara kerja
Instans PolarDB-X dalam topologi ini menjalankan lima replika: empat replika tersebar di dua pusat data utama dalam satu wilayah, dan satu replika di pusat data sekunder di wilayah lain. Sinkronisasi mayoritas memerlukan respons dari minimal tiga replika.
Di dalam pusat data utama, keempat replika berkomunikasi melalui jaringan lokal berlatensi rendah—sinkronisasi mayoritas biasanya selesai dalam sekitar 1 milidetik. Latensi jaringan antara pusat data utama dan sekunder sekitar 30 milidetik, yang merupakan nilai khas untuk koneksi cross-region di industri seperti jasa keuangan.
Empat mekanisme membuat arsitektur ini bekerja secara andal:
Mekanisme pemilihan berbobot: Menjaga pemilihan leader tetap lokal untuk menghindari latensi cross-region yang tidak perlu.
Penyesuaian replika dinamis: Memulihkan sinkronisasi mayoritas berlatensi rendah setelah terjadi kegagalan pusat data.
Pemaksaan mode replika tunggal: Memungkinkan pusat data sekunder melayani permintaan ketika kedua pusat data utama gagal.
Instans sekunder remote: Menyediakan geo-disaster recovery untuk memenuhi persyaratan RTO.
Skenario kegagalan dan respons
| Skenario kegagalan | Lingkup | Respons |
|---|---|---|
| Kegagalan replika leader | Pusat data utama | Pemicu pemilihan ulang leader. Follower di pusat data yang sama diprioritaskan untuk meminimalkan pengalihan lalu lintas. |
| Kegagalan replika follower | Pusat data utama | Tidak diperlukan tindakan. |
| Kegagalan replika follower | Pusat data sekunder | Tidak diperlukan tindakan. |
| Kegagalan pusat data utama | Salah satu dari dua pusat data utama | Lima replika secara dinamis diturunkan menjadi tiga replika. Sinkronisasi cross-region mungkin terjadi. |
| Kegagalan pusat data sekunder | — | Empat replika tetap berada di pusat data utama. Kinerja protokol Paxos tidak terpengaruh. |
| Kedua pusat data utama gagal | Kegagalan regional | Satu replika tersisa di pusat data sekunder. Jalankan force_single_mode untuk menjalankan replika tersebut dalam mode replika tunggal. Alihkan traffic bisnis ke instans sekunder remote. |
| Pusat data sekunder gagal | Kegagalan regional | Tidak diperlukan tindakan. |
Mekanisme utama
Mekanisme pemilihan berbobot
PolarDB-X menerapkan mekanisme pemilihan berbobot sehingga pemilihan ulang leader lebih memilih replika di pusat data yang sama, menghindari latensi cross-region yang tidak perlu.
Bobot pemilihan replika:
| Pusat data | Peran replika | Bobot pemilihan |
|---|---|---|
| Pusat Data Utama 1 | Leader | 9 |
| Pusat Data Utama 1 | Follower | 7 |
| Pusat Data Utama 2 | Follower | 5 |
| Pusat Data Utama 2 | Follower | 3 |
| Pusat Data Sekunder | Follower | 1 |
Mekanisme ini terdiri dari dua bagian:
Pemilihan berbobot optimistik: Setiap node menunggu jeda yang dihitung sebelum memulai pemilihan leader. Jeda tersebut berbanding terbalik dengan bobot node, sehingga node dengan bobot lebih tinggi memulai pemilihan terlebih dahulu.
Pemilihan berbobot wajib: Ketika leader baru mengetahui bahwa ia tidak memiliki bobot tertinggi di antara semua node, ia memasuki fase abdikasi alih-alih langsung menerima write. Selama fase ini, node mengirim sinyal heartbeat (misalnya, setiap 1 hingga 2 detik). Jika node dengan bobot lebih tinggi merespons sebelum fase abdikasi berakhir, kepemimpinan dialihkan ke node tersebut.
Sebagai contoh, jika leader di Pusat Data Utama 1 gagal, follower di pusat data yang sama (bobot 7) diprioritaskan dibanding yang lain, sehingga traffic tetap lokal.
Penyesuaian jumlah replika secara dinamis
Ketika pusat data utama gagal dan hanya tersisa tiga replika, sinkronisasi mayoritas harus melibatkan replika di pusat data sekunder, menambahkan latensi cross-region sekitar 30 milidetik. Sesuaikan jumlah replika menggunakan perintah berikut untuk mengelola tradeoff ini:
| Transisi | Perintah | Catatan |
|---|---|---|
| Lima replika menjadi tiga replika | downgrade_follower | Mengonversi dua follower menjadi learner |
| Tiga replika menjadi lima replika | upgrade_learner | Mengonversi dua learner kembali menjadi follower; pastikan log replikasi mutakhir sebelum upgrade |
| Satu replika menjadi tiga replika | add_follower | Menambahkan replika baru sebagai learner; mereka secara otomatis dipromosikan menjadi follower begitu log-nya mutakhir |
Mulai Paksa Replika Tunggal
Ketika kedua pusat data utama gagal, satu-satunya replika yang tersisa di pusat data sekunder tidak dapat memenuhi persyaratan konsensus mayoritas sendirian. Jalankan force_single_mode untuk memaksa sistem masuk ke mode replika tunggal, menonaktifkan semua replika follower sehingga replika yang tersisa dapat melayani permintaan.
Begitu pusat data utama pulih, PolarDB-X membangun kembali sistem terdistribusi secara bertahap:
Tambahkan replika dari satu menjadi tiga: jalankan
add_follower.Tambahkan replika dari tiga menjadi lima: jalankan
upgrade_learner.
Instans sekunder remote
Dalam sistem database terdistribusi, progres replikasi dapat berbeda di berbagai grup Paxos selama transaksi terdistribusi. Tanpa koordinasi, data dari transaksi yang hanya sebagian direplikasi dapat muncul di instans sekunder, menyebabkan inkonsistensi transaksi.
PolarDB-X mengatasi hal ini menggunakan node log Change Data Capture (CDC) yang ditempatkan di wilayah remote. Node-node ini mengurutkan dan mengatur ulang transaksi terdistribusi untuk menjamin replikasi atomik—tidak ada transaksi yang dikomit secara parsial saat data berpindah dari instans utama ke instans sekunder. Jaminan ini berlaku baik selama latihan pemulihan bencana rutin maupun failover sesungguhnya.
Dua prinsip desain mengatur cara replikasi dan failover bekerja:
Replikasi instans utama: Instans utama menggunakan protokol Paxos cross-region, yang memerlukan respons dari minimal tiga replika. Karena empat replika berada di pusat data utama, sinkronisasi mayoritas biasanya selesai secara lokal. Replika remote di pusat data sekunder merespons secara asinkron, sehingga latensi cross-region tidak memengaruhi kinerja write instans utama.
Replikasi instans sekunder: Instans sekunder berada di wilayah remote. Node log CDC mereplikasi data hampir secara real time lintas wilayah. Latensi replikasi mungkin terjadi, tetapi replikasi transaksi atomik menjamin bahwa instans sekunder tidak pernah mencerminkan transaksi yang hanya sebagian dikomit.
Operasi dan maintenance (O&M) umum
Referensi cepat: skenario ke perintah
| Skenario | Aksi |
|---|---|
| Salah satu pusat data utama gagal | Jalankan downgrade_follower untuk mengurangi lima replika menjadi tiga |
| Pusat data utama pulih | Jalankan upgrade_learner untuk mengembalikan lima replika |
| Kedua pusat data utama gagal | Jalankan force_single_mode untuk memulai mode replika tunggal; alihkan traffic ke instans sekunder |
| Pusat data sekunder pulih setelah kegagalan regional | Jalankan add_follower untuk menambahkan replika, lalu upgrade_learner |
Buat instans dengan topologi ini
Saat membuat instans PolarDB-X, atur parameter Topology menjadi Three Data Centers Across Two Regions.
Lihat topologi instans
Di halaman Basic Information instans, temukan bagian Topology Information untuk melihat detail zona semua sumber daya.
Lakukan failover
Sebelum memulai
Jadwalkan failover pada periode traffic rendah untuk mengurangi dampak terhadap kinerja write.
Di halaman Basic Information, verifikasi topologi saat ini dan pastikan pusat data mana yang ingin Anda tetapkan sebagai zona utama.
Langkah-langkah
Masuk ke Konsol PolarDB for Xscale.
Di bilah navigasi atas, pilih wilayah tempat instans target berada.
Di halaman Instances, klik tab PolarDB-X 2.0.
Temukan instans target dan klik ID-nya.
Di halaman Basic Information, klik Specify Primary Zone di pojok kanan atas bagian Topology Information.
Di kotak dialog Specify Primary Zone, atur parameter Data Center, Primary Zone, dan Switch Mode.
Klik OK.
Setelah failover
Verifikasi bahwa bagian Topology Information mencerminkan zona utama baru sebelum melanjutkan traffic write normal.