PolarDB：Failover dengan replika panas

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 titik kegagalan, dan pemilihan node primer dari node kluster. Detail arsitektur VDS:

  • Setiap node komputasi di VDS memiliki thread independen. Thread VDS diklasifikasikan menjadi tiga kategori: Leader, Follower, dan Observer. Di kluster PolarDB, thread Leader berjalan di node primer, thread Follower berjalan di node replika panas, dan thread Observer berjalan di node hanya-baca. 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 kunci terdistribusi berbasis sewa di VDS dan mencatat metadata seperti pemegang kunci dan waktu sewa. Node primer dan node replika panas dari kluster PolarDB menggunakan semantik akuisisi kunci dan pembaruan kunci untuk mendeteksi titik kegagalan dan memilih node primer.

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

  

  Secara umum, node primer menyediakan layanan baca dan tulis, dan thread Leader yang sesuai secara berkala memperbarui kuncinya di VDS. Ketika node primer tidak tersedia, node replika panas mengambil alih. Prosesnya dijelaskan berikut ini:

  1. Setelah masa sewa node primer berakhir, thread Follower dikunci dan dipilih sebagai thread Leader. Pada saat ini, node replika panas menjadi node primer.

  2. Ketika node primer asli pulih, ia gagal mendapatkan kunci. Kemudian, node primer asli diturunkan menjadi node replika panas.

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

• Global prefetching system

  Dibandingkan dengan node hanya-baca biasa, node hot standby adalah jenis node hanya-baca khusus yang menyisihkan sebagian kecil sumber daya CPU dan memori untuk mengoptimalkan kecepatan switch-over. Sistem pra-pemuatan global adalah modul terpenting dalam failover dengan replika panas. Ini menyinkronkan metadata node primer secara real-time dan mempramuat data kunci 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 tertaut yang digunakan untuk mengimplementasikan algoritma Least Recently Used (LRU) di buffer pool untuk node primer secara real-time dan mengirimkan data relevan ke node replika panas. Node replika panas memilih halaman yang sering diakses dan mempramuatnya ke memori untuk menghindari penurunan kinerja yang disebabkan oleh penurunan signifikan pada tingkat hit buffer pool ketika node hanya-baca dipilih sebagai node primer.

  • Undo

    Modul Undo mempramuat data di sistem transaksi. Selama failover, PolarDB menemukan transaksi yang tertunda dari halaman undo dan membatalkan transaksi tersebut. Node hanya-baca hanya memproses permintaan kueri analitik skala besar dan tidak mengakses transaksi yang belum dikomit dari node primer. Ini mengarah pada waktu tunggu I/O yang lama untuk halaman undo. Fitur failover dengan replika panas mempramuat 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 hanya-baca di tabel hash redo memori secara real-time.

  • Binlog

    Setelah log biner diaktifkan, transaksi InnoDB dalam status Prepare memutuskan apakah akan melakukan commit atau rollback transaksi 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 menyinkronkan log biner terbaru secara asinkron ke cache I/O dan mengurainya terlebih dahulu untuk meningkatkan kecepatan failover.

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

• Persistent connections and transaction status preservation

  Namun, failover atau peningkatan panas dapat memengaruhi layanan Anda dan menyebabkan masalah seperti koneksi sementara, kegagalan koneksi, dan rollback transaksi yang ada. Ini meningkatkan kompleksitas dan risiko pengembangan aplikasi.

  PolarDB mendukung fitur Koneksi Persisten. Koneksi persisten diimplementasikan dengan cara PolarProxy berfungsi sebagai jembatan penghubung antara aplikasi Anda dan PolarDB. Ketika database melakukan failover primer/sekunder, PolarProxy menghubungkan node database ke aplikasi Anda dan memulihkan sesi sebelumnya, termasuk variabel sistem asli, variabel pengguna, pengkodean set karakter, dan informasi lainnya.

  Fitur koneksi persisten dapat diterapkan hanya pada koneksi idle. Jika sesi saat ini memiliki transaksi yang sedang dieksekusi pada saat node beralih, PolarProxy tidak dapat mengambil konteks transaksi asli dari PolarDB. Node primer baru akan membatalkan transaksi yang belum dikomit dan melepaskan kunci baris yang dipegang oleh transaksi tersebut. Dalam hal ini, koneksi persisten tidak dapat dipertahankan. Untuk menyelesaikan 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 primer.

  Sebagai contoh, proses melakukan commit transaksi dalam aplikasi adalah BEGIN > INSERT > UPDATE > COMMIT dan fitur pelestarian status transaksi diaktifkan. Setelah transaksi mulai dieksekusi, PolarProxy menyimpan pernyataan SQL yang paling baru dieksekusi sambil meneruskan pernyataan SQL ke node primer. Setelah pernyataan INSERT dieksekusi di node primer, PolarDB secara otomatis menyimpan savepoint dari pernyataan terbaru sebagai bagian dari informasi transaksi. Pelacak sesi mengembalikan sesi dan informasi transaksi saat ini ke PolarProxy. Kemudian, PolarProxy menyimpan data tersebut sementara 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 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 primer tidak tersedia ketika pernyataan UPDATE dieksekusi di PolarDB. PolarProxy tidak segera mentransmisikan kesalahan dari lapisan bawah ke koneksi aplikasi, tetapi menahan permintaan selama periode waktu tertentu. Setelah failover, node primer baru dapat membangun semua transaksi yang belum dikomit berdasarkan log redo dan menunggu secara asinkron transaksi yang belum dikomit tanpa membatalkan transaksi. Ketika PolarProxy mendeteksi pesan failover berhasil, ia akan menggunakan informasi sesi dan transaksi yang disimpan di cache oleh dirinya sendiri untuk membangun kembali transaksi dengan memanggil API Attach Trx dari PolarDB. PolarDB menentukan apakah informasi transaksi valid berdasarkan informasi PolarProxy. Jika informasi transaksi valid, itu akan diikat ke koneksi dan dibatalkan ke savepoint 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 primer baru dari cache pernyataan SQL. Selama proses failover, tidak ada kesalahan koneksi atau transaksi yang dilaporkan di aplikasi Anda. Satu-satunya perbedaan adalah bahwa pernyataan UPDATE mungkin lebih lambat dari biasanya.