PolarDB:Failover with hot replica

Teknologi inti berikut digunakan untuk menerapkan fitur failover dengan replika panas di PolarDB:

• New high availability module: VDS

  Setelah fitur failover dengan replika panas diaktifkan, PolarDB mengaktifkan VDS. Dengan arsitektur disk bersama PolarDB, VDS menyediakan manajemen otonom, deteksi gangguan, dan pemilihan node primary untuk node kluster. Rincian arsitektur VDS:

  • Setiap node komputasi dalam VDS memiliki thread independen. Thread VDS diklasifikasikan menjadi tiga kategori: Leader, Follower, dan Observer. Di kluster PolarDB, thread Leader berjalan di node primary, thread Follower berjalan di node replika panas, dan thread Observer berjalan di node read-only. Kluster PolarDB dapat berisi satu thread leader, satu thread follower, dan beberapa thread observer.

  • VDS membuat dua modul data di PolarStore: Compare-and-Swap (CAS) Block dan Polar Cluster Registry (PCR).

    • CAS Block adalah blok data atomik yang mendukung operasi CAS yang disediakan oleh PolarStore. CAS memungkinkan penggunaan kunci terdistribusi berbasis lease di VDS dan mencatat metadata seperti pemegang kunci dan durasi lease. Node primary dan node replika panas kluster PolarDB menggunakan semantik pemerolehan dan perpanjangan kunci untuk mendeteksi gangguan dan memilih node primary.

    • PCR menyimpan informasi manajemen node PolarDB, seperti status topologi kluster. Thread Leader memiliki izin untuk menulis data ke PCR, sedangkan thread Follower dan Observer hanya memiliki izin membaca data dari PCR. Ketika thread Follower ditunjuk sebagai thread Leader, thread Leader asli berubah menjadi thread Follower. Hanya thread Leader terbaru yang memiliki izin menulis data ke PCR. PCR juga membangun ulang topologi.

  

  Secara umum, node primary menyediakan layanan baca dan tulis, dan thread Leader terkait secara berkala memperpanjang lease-nya di VDS. Ketika node primary menjadi tidak tersedia, node replika panas mengambil alih. Prosesnya dijelaskan pada bagian berikut:

  1. Setelah lease node primary berakhir, thread Follower mengunci dan dipilih sebagai thread Leader. Pada titik ini, node replika panas menjadi node primary.

  2. Ketika node primary asli pulih, ia gagal memperoleh kunci. Kemudian, node primary asli diturunkan menjadi node replika panas.

  3. Ketika proses pemilihan node primary selesai, PCR menyiarkan informasi topologi baru ke semua thread Observer. Dengan cara ini, node read-only dapat secara otomatis terhubung ke node primary baru dan memulihkan tautan sinkronisasi untuk nomor urutan log (LSN) dan log biner.

• Global prefetching system

  Dibandingkan dengan node read-only biasa, node hot standby adalah jenis khusus node read-only yang menyisihkan sebagian kecil sumber daya CPU dan memori untuk mengoptimalkan kecepatan alih bencana. Sistem pra-pemuatan global adalah modul terpenting dalam failover dengan replika panas. Sistem ini menyinkronkan metadata node primary secara real time dan melakukan pra-ambil data kritis ke memori untuk meningkatkan kecepatan failover. Sistem pra-pemuatan global terdiri dari empat modul: Buffer Pool, Undo, Redo, dan Binlog.

  • Buffer Pool

    Modul Buffer Pool memantau daftar berantai yang digunakan untuk menerapkan algoritma Least Recently Used (LRU) di kolam buffer untuk node primary secara real time dan mengirimkan data terkait ke node replika panas. Node replika panas memilih halaman yang sering diakses dan melakukan pra-ambil ke memori untuk menghindari degradasi performa akibat penurunan signifikan tingkat hit kolam buffer ketika node read-only dipilih sebagai node primary.

  • Undo

    Modul Undo melakukan pra-ambil data dalam sistem transaksi. Selama failover, PolarDB menemukan transaksi yang tertunda dari halaman undo dan melakukan rollback transaksi tersebut. Node read-only hanya memproses permintaan kueri analitis skala besar dan tidak mengakses transaksi yang belum dikomit dari node primary. Hal ini menyebabkan waktu tunggu I/O yang lama untuk halaman undo. Fitur failover dengan replika panas melakukan pra-ambil halaman undo dan memainkannya kembali ke versi terbaru menggunakan Runtime Apply untuk mengurangi waktu pemulihan sistem transaksi.

  • Redo

    Modul Redo menyimpan cache log redo dari node replika panas dan node read-only di tabel hash redo di memori secara real time.

  • Binlog

    Setelah log biner diaktifkan, transaksi InnoDB dalam status Prepare menentukan apakah akan meng-commit atau melakukan rollback berdasarkan log biner. Ketika sejumlah besar transaksi dieksekusi, sistem mungkin memerlukan beberapa detik atau menit untuk membaca dan mengurai semua log biner. Node replika panas menggunakan thread latar belakang untuk menyimpan cache log biner terbaru secara asinkron di cache I/O dan menguraikannya terlebih dahulu guna meningkatkan kecepatan failover.

  PolarDB mendukung konversi dinamis antara node replika panas dan node standby biasa. Dalam skenario aktual, Anda dapat mengaktifkan satu node replika panas dalam jangka panjang, atau hanya mengaktifkan fitur replika panas untuk waktu singkat selama perubahan konfigurasi atau peningkatan. PolarDB memungkinkan Anda mengonfigurasi node primary dan node read-only dengan spesifikasi berbeda. Namun, setidaknya satu node read-only harus menggunakan spesifikasi yang sama dengan node primary untuk pemulihan bencana. Kami merekomendasikan agar Anda mengonfigurasi node ini sebagai node replika panas.

• Persistent connections and transaction status preservation

  Namun, failover atau hot upgrade dapat memengaruhi layanan Anda dan menyebabkan isu seperti koneksi terputus sementara, kegagalan koneksi, dan rollback transaksi yang sedang berjalan. Hal ini meningkatkan kompleksitas dan risiko pengembangan aplikasi.

  PolarDB mendukung fitur Persistent connections. Koneksi persisten diimplementasikan dengan cara PolarProxy bertindak sebagai jembatan penghubung antara aplikasi Anda dan PolarDB. Ketika database melakukan failover primary/secondary, PolarProxy menghubungkan node database ke aplikasi Anda dan memulihkan sesi sebelumnya, termasuk variabel sistem, variabel pengguna, encoding set karakter, dan informasi lainnya.

  Fitur koneksi persisten hanya dapat diterapkan pada koneksi idle. Jika sesi saat ini memiliki transaksi yang sedang dieksekusi pada saat node dialihkan, PolarProxy tidak dapat mengambil konteks transaksi asli dari PolarDB. Node primary baru akan melakukan rollback transaksi yang belum dikomit dan melepaskan kunci baris yang dipegang oleh transaksi tersebut. Dalam kasus ini, koneksi persisten tidak dapat dipertahankan. Untuk mengatasi masalah ini, PolarDB menyediakan fitur pelestarian status transaksi. Pelestarian status transaksi, bersama dengan fitur koneksi persisten, memungkinkan failover cepat untuk memberikan ketersediaan tinggi tanpa mengganggu layanan Anda.

  Berbeda dengan replikasi logis berbasis log biner, arsitektur replikasi fisik memungkinkan PolarDB membangun kembali transaksi yang sama di node replika panas seperti di node primary.

  Sebagai contoh, proses commit transaksi dalam aplikasi adalah BEGIN > INSERT > UPDATE > COMMIT dan fitur pelestarian status transaksi diaktifkan. Setelah transaksi mulai dieksekusi, PolarProxy menyimpan cache pernyataan SQL yang paling baru dieksekusi sambil meneruskan pernyataan SQL tersebut ke node primary. Setelah pernyataan INSERT dieksekusi di node primary, PolarDB secara otomatis menyimpan titik simpan pernyataan terbaru sebagai bagian dari informasi transaksi. Pelacak sesi mengembalikan informasi sesi dan transaksi saat ini ke PolarProxy. Kemudian, PolarProxy menyimpan sementara data tersebut ke cache internal. Informasi sesi, seperti set karakter dan variabel pengguna, digunakan untuk mempertahankan koneksi. Informasi transaksi, seperti trx_id dan undo_no, digunakan untuk pelestarian status transaksi. Selain itu, informasi transaksi terus-menerus disinkronkan ke replika panas melalui tautan RDMA terpisah. Jika log biner diaktifkan untuk database backend, cache log biner lokal yang sesuai dengan setiap transaksi disinkronkan ke node replika panas.

  

  Sebagai contoh, node primary tidak tersedia ketika pernyataan UPDATE dieksekusi di PolarDB. PolarProxy tidak langsung meneruskan error dari lapisan bawah ke koneksi aplikasi, tetapi menahan permintaan tersebut untuk sementara waktu. Setelah failover, node primary baru dapat membangun semua transaksi yang belum dikomit berdasarkan log redo dan menunggu secara asinkron transaksi yang belum dikomit tanpa melakukan rollback. Ketika PolarProxy mendeteksi pesan failover yang berhasil, ia akan menggunakan informasi sesi dan transaksi yang di-cache untuk membangun kembali transaksi dengan memanggil API Attach Trx PolarDB. PolarDB menentukan apakah informasi transaksi tersebut valid berdasarkan informasi dari PolarProxy. Jika informasi transaksi valid, informasi tersebut akan diikat ke koneksi dan di-rollback ke titik simpan undo_no yang sesuai dengan pernyataan terakhir (pernyataan UPDATE).

  Setelah transaksi dibangun kembali, PolarProxy dapat mengirim ulang pernyataan UPDATE terbaru yang gagal dieksekusi ke node primary baru dari cache pernyataan SQL. Selama proses failover, tidak ada error koneksi atau transaksi yang dilaporkan di aplikasi Anda. Satu-satunya perbedaan adalah bahwa pernyataan UPDATE mungkin lebih lambat dari biasanya.