PolarDB:Tiga pusat data di dua wilayah

Pemilihan berbobot

PolarDB-X memperkenalkan bobot pemilihan dalam desain tiga pusat data di dua wilayah. Prinsip kerjanya sebagai berikut:

• Pemilihan berbobot optimistik: Dalam protokol konsensus mayoritas Paxos, node yang lebih mungkin memulai pemilihan cenderung menjadi leader. Untuk mengoptimalkannya, konsep bobot diperkenalkan untuk menetapkan penundaan acak bagi node berbeda sebelum memulai pemilihan leader, sehingga node dengan bobot lebih tinggi memulai pemilihan terlebih dahulu.

• Pemilihan berbobot wajib: Saat leader yang baru terpilih mengetahui bahwa ia tidak memiliki bobot tertinggi di antara semua node (pengecekan ini dilewati jika semua bobot sama), ia tidak langsung menerima operasi write. Sebaliknya, ia memasuki fase abdikasi dan menunggu selama satu timeout pemilihan. Selama fase ini, node tersebut mengirim probe heartbeat ke node lain secara berkala (misalnya, setiap 1 hingga 2 detik). Jika ada node dengan bobot lebih tinggi yang merespons, kepemimpinan dialihkan ke node yang merespons dengan bobot tertinggi.

PolarDB-X Tabel berikut menunjukkan bobot pemilihan replika dalam tiga pusat data di dua wilayah:

Misalnya, jika replika leader di Pusat Data Utama 1 gagal, replika follower di pusat data yang sama (bobot 7) diprioritaskan menjadi leader baru, sehingga lalu lintas tetap lokal.

Penyesuaian dinamis jumlah replika

Dalam arsitektur tiga pusat data di dua wilayah, grup mayoritas lima replika memerlukan respons sinkronisasi dari minimal tiga replika. Secara default, empat replika di pusat data utama menyelesaikan sinkronisasi mayoritas secara lokal melalui jaringan berlatensi rendah, dengan latensi khas sekitar 1 milidetik. Ketika terjadi kegagalan tingkat pusat data sehingga hanya tersisa tiga replika, sinkronisasi harus mencakup replika di pusat data sekunder, sehingga meningkatkan latensi protokol mayoritas sekitar 30 milidetik (latensi lintas wilayah khas di industri seperti layanan keuangan).

Skema penyesuaian replika umum:

• Menurunkan dari lima replika menjadi tiga replika: gunakan perintah downgrade_follower untuk menurunkan dua follower menjadi learner.

• Meningkatkan dari tiga replika menjadi lima replika: gunakan perintah upgrade_learner untuk mempromosikan dua learner kembali menjadi follower. Pastikan log replikasi mutakhir sebelum melakukan peningkatan.

• Meningkatkan dari satu replika menjadi tiga replika: gunakan perintah add_follower untuk menambahkan replika secara dinamis. Replika baru dimulai sebagai learner dan secara otomatis dipromosikan menjadi follower setelah log-nya mutakhir.

Start paksa replika tunggal

Ketika seluruh wilayah utama gagal, satu-satunya replika yang tersisa di pusat data sekunder tidak dapat memenuhi persyaratan konsensus mayoritas, sehingga tidak dapat melayani data secara mandiri.

PolarDB-X mendukung start paksa replika tunggal. Gunakan perintah force_single_mode untuk memaksa sistem masuk ke mode single-replica dan menonaktifkan semua follower. Setelah pusat data utama pulih, gunakan kemampuan penyesuaian replika dinamis untuk memulihkan sistem dari satu replika menjadi tiga, lalu lima replika.

Instans secondary remote

Standar pemulihan bencana industri keuangan menetapkan persyaratan RPO dan RTO detail halus untuk geo-disaster recovery, seperti ditunjukkan pada tabel berikut:

PolarDB-X Untuk memenuhi persyaratan RTO dalam geo-disaster recovery, arsitektur ini menyediakan instans secondary remote berdasarkan lima replika ditambah pasangan kluster primary-secondary. Ketika wilayah utama gagal sepenuhnya, lalu lintas bisnis dapat dengan cepat dialihkan ke instans secondary remote untuk pemulihan bencana.

Poin desain utama arsitektur kluster primary-secondary:

• PolarDB-X instans primary menggunakan protokol replikasi Paxos lintas wilayah dan memerlukan respons sinkronisasi dari minimal tiga replika. Secara default, empat replika di pusat data utama menyelesaikan sinkronisasi mayoritas secara lokal, sedangkan replika remote merespons secara asinkron. Latensi lintas wilayah tidak memengaruhi kinerja instans primary.

• PolarDB-X instans secondary ditempatkan di wilayah remote dan menggunakan node log CDC PolarDB-X untuk membangun replikasi primary-secondary antar kluster yang hampir real-time. Meskipun instans secondary remote mungkin memiliki latensi replikasi tertentu, replikasi transaksi atomik tetap dijamin untuk menghindari inkonsistensi transaksi.

• Replikasi antar kluster dalam skenario tiga pusat data di dua wilayah memerlukan node log CDC yang ditempatkan di wilayah remote untuk mengurutkan dan mengatur ulang transaksi terdistribusi. Hal ini menyediakan replikasi transaksi atomik dan memastikan tidak ada transaksi yang sebagian dikomit selama replikasi antar kluster. Replikasi transaksi atomik menjamin integritas data baik dalam latihan pemulihan bencana rutin maupun saat failover sesungguhnya ketika lalu lintas dialihkan ke instans secondary remote.

Membuat instans

Saat membuat instans PolarDB-X, atur mode penyebaran ke Three Data Centers Across Two Regions.

Lihat topologi instans

Pada halaman Basic Information, temukan bagian Topology Information untuk melihat informasi zona sumber daya terkait.

Lakukan failover

1. Masuk ke Konsol PolarDB Distributed Edition.

2. Di bilah navigasi atas, pilih wilayah tempat instans ditempatkan.

3. Pada halaman Instances, klik tab PolarDB-X 2.0.

4. Temukan instans tersebut dan klik Instance ID untuk membuka halaman detail instans.

5. Pada halaman Basic Information, temukan bagian Topology Information, lalu klik Specify Primary Zone.

6. Pada kotak dialog Specify Primary Zone, atur parameter Data Center, Primary Zone, dan Switch Mode.

7. Klik OK.