tencent cloud

TencentDB for MySQL

Tutorial Pengguna
Pengenalan Produk
Ikhtisar
Keunggulan
Kasus Penggunaan
Database Architecture
Kebijakan Isolasi Sumber Daya
Database Instance
Ketersediaan Tinggi (Beberapa AZ)
Wilayah dan AZ
Panduan Pembelian
Ikhtisar Penagihan
Metode Pembelian
Pembayaran Jatuh Tempo
Pengembalian Dana
Biaya Penyesuaian Instans
Penagihan Ruang Cadangan
Memulai
Ikhtisar
Membuat Instans MySQL
Panduan Operasi
Batas Penggunaan
Ikhtisar Operasi
Manajemen dan Pemeliharaan Instans
Peningkatan Versi
Memperluas Instans
Proksi Database
Manajemen Akun
Konfigurasi Parameter
Pencadangan dan Pengembalian
Migrasi data
Jaringan dan Keamanan
Pemantauan dan Alarm
Pusat Log
Tag
Laporan Resmi
Laporan Resmi Keamanan
Service Agreement
Service Level Agreement
Terms of Service

Replikasi Instance Basis Data

PDF
Mode fokus
Ukuran font
Terakhir diperbarui: 2026-02-05 11:37:48
Replikasi instans database merujuk pada sinkronisasi data dengan mengonfigurasi satu atau lebih database cadangan untuk server, mendistribusikan data MySQL ke beberapa sistem. Artikel ini memperkenalkan metode replikasi data yang didukung oleh TencentDB for MySQL serta optimasi sinkronisasi data pada kernel TXSQL.
Catatan:
Primary merujuk pada instans database utama, Standby merujuk pada instans database cadangan.
MySQL versi 5.6, 5.7, dan 8.0 mendukung tiga metode replikasi: asinkron, semi-sinkron, dan sinkron kuat; versi 5.5 mendukung metode asinkron.

Metode replikasi data yang didukung oleh TencentDB for MySQL

1. Replikasi Asinkron

Aplikasi mengirimkan permintaan pembaruan data (termasuk operasi insert, update, delete). Setelah menyelesaikan operasi pembaruan, simpul utama segera mengembalikan respons ke aplikasi, kemudian menyalin data ke simpul cadangan.
Dalam proses pembaruan data, simpul utama tidak perlu menunggu respons dari simpul cadangan. Oleh karena itu, instans database dengan replikasi asinkron biasanya memiliki kinerja yang lebih tinggi, dan ketidaktersediaan simpul cadangan tidak memengaruhi layanan simpul utama. Namun, karena data tidak disinkronkan secara waktu nyata ke simpul cadangan, jika simpul utama mengalami kegagalan saat simpul cadangan tertinggal, terdapat kemungkinan kecil yang dapat menyebabkan ketidakkonsistenan data.
TencentDB for MySQL mengadopsi arsitektur satu utama dan satu cadangan untuk replikasi asinkron.

2. Replikasi Semi-Sinkron

Aplikasi mengirimkan permintaan pembaruan data (termasuk operasi insert, update, delete). Setelah menyelesaikan operasi pembaruan, simpul utama segera menyalin data ke simpul cadangan. Simpul cadangan menerima data dan menulisnya ke relay log (tanpa perlu eksekusi) sebelum mengembalikan informasi keberhasilan ke simpul utama. Simpul utama harus menerima konfirmasi keberhasilan dari simpul cadangan terlebih dahulu sebelum mengembalikan respons ke aplikasi.
Hanya ketika terjadi anomali dalam replikasi data (simpul cadangan tidak tersedia atau jaringan replikasi data mengalami gangguan), simpul utama akan menghentikan sementara respons ke aplikasi (sekitar 10 detik secara default di MySQL) dan menurunkan metode replikasi menjadi replikasi asinkron. Ketika replikasi data kembali normal, sistem akan kembali ke mode replikasi semi-sinkron.
TencentDB for MySQL mengadopsi arsitektur satu utama dan satu cadangan untuk replikasi semi-sinkron.

3. Replikasi sinkron kuat

Aplikasi mengirimkan permintaan pembaruan data (termasuk operasi insert, update, delete). Setelah menyelesaikan operasi pembaruan, simpul utama segera menyalin data ke simpul cadangan. Simpul cadangan menerima data dan menulisnya ke relay log (tanpa perlu eksekusi) sebelum mengembalikan informasi keberhasilan ke simpul utama. Simpul utama harus menerima konfirmasi keberhasilan dari simpul cadangan terlebih dahulu sebelum mengembalikan respons ke aplikasi.
Dalam kasus terjadi anomali dalam replikasi data (simpul cadangan tidak tersedia atau jaringan replikasi data mengalami gangguan), metode replikasi tidak akan mengalami downgrade. Untuk menjamin konsistensi data, simpul utama akan menghentikan sementara respons ke aplikasi hingga anomali berakhir.
TencentDB for MySQL mengadopsi arsitektur satu utama dan dua cadangan untuk replikasi sinkron kuat. Hanya perlu satu simpul cadangan yang berhasil mengeksekusi untuk mengembalikan respons, sehingga menghindari dampak ketidaktersediaan satu simpul cadangan pada operasi simpul utama, dan meningkatkan ketersediaan klaster replikasi sinkron kuat.

Optimisasi TXSQL kernel untuk sinkronisasi data

Masalah yang ada

Ketika simpul utama atau simpul cadangan tidak tersedia, replikasi asinkron, semi-sinkron, dan sinkron kuat dapat berpotensi menyebabkan ketidakkonsistenan data.
Database sebagai kemampuan inti penyimpanan dan layanan data sistem memiliki persyaratan ketersediaan yang sangat tinggi. Dalam sistem produksi, solusi ketersediaan tinggi biasanya diperlukan untuk memastikan operasi tanpa gangguan, sedangkan teknologi sinkronisasi data merupakan fondasi solusi ketersediaan tinggi database.

Optimasi Solusi

Solusi replikasi sinkron kuat dikembangkan sendiri oleh Tencent berdasarkan protokol MySQL dengan pendekatan multithread paralel. Hanya ketika data di simpul cadangan sepenuhnya tersinkronisasi (log), simpul utama baru memberikan respons transaksi ke aplikasi, sehingga menjamin keamanan dan kebenaran data.
Diagram skema prinsip sebagai berikut:

Aplikasi mengirimkan permintaan, dan simpul utama baru memberikan respons keberhasilan ke lapisan aplikasi setelah simpul cadangan mengembalikan informasi keberhasilan, guna memastikan data di simpul utama dan cadangan sepenuhnya konsisten.
Solusi sinkron kuat memiliki kinerja yang lebih baik daripada solusi sinkron utama lainnya, dengan karakteristik utama sebagai berikut:
Replikasi sinkron dengan konsistensi kuat memastikan konsistensi data yang kuat antar simpul.
Transparan sepenuhnya di tingkat bisnis, tidak perlu melakukan pemisahan baca/tulis atau penguatan sinkronisasi di tingkat bisnis.
Mengubah thread sinkron serial menjadi asinkron dan memperkenalkan kemampuan thread pool, sehingga meningkatkan kinerja secara signifikan.
Mendukung arsitektur edisi cloud disk.
Mendukung kontrol anggota otomatis, simpul yang gagal akan dikeluarkan secara otomatis dari klaster.
Mendukung bergabungnya simpul secara otomatis tanpa intervensi manual.
Setiap simpul memiliki replika data lengkap yang dapat beralih kapan saja.
Tidak perlu perangkat penyimpanan bersama.

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan