Pengenalan Pangkalan Data Tencent Cloud TDSQL: Sandaran dan Pemulihan Senibina Peringkat Perusahaan

Rakan-rakan yang telah bermain dengan pelayan awan dan MySQL sumber terbuka harus tahu bahawa pangkalan data yang berdiri sendiri biasanya sangat bagus untuk berlatih, tetapi ketika datang ke senario perniagaan e-dagang, kewangan atau perniagaan yang sangat serentak, seni bina yang berdiri sendiri akan hancur. Apa yang benar-benar diperlukan oleh perusahaan adalah pangkalan data yang diedarkan dengan pelbagai aktiviti, konsistensi yang kuat, dan pemulihan bencana automatik.

Tencent Cloud

TDSQL

Yang keluar melakukan ini. Ini adalah pangkalan data diedarkan peringkat perusahaan yang dikembangkan sendiri oleh Tencent, yang tidak hanya sesuai dengan prestasi MySQL, tetapi juga memiliki seni bina yang diedarkan di lapisan bawah. Hari ini kita tidak akan membincangkan teori PPT yang tidak jelas itu, tetapi secara langsung memotong titik sakit inti, dan membawa anda untuk mempraktikkan garis hidup pangkalan data peringkat perusahaan --

Sandaran dan pemulihan

。

Tahap pertama: Maut ke bawah, fahami seni bina tiga peringkat perusahaan TDSQL

Sebelum menjalani pembedahan (sandaran dan pemulihan), anda mesti terlebih dahulu memahami struktur tubuh manusia TDSQL, jika tidak, anda akan buta di mana fail sandaran disimpan dan bagaimana ia dipulihkan. Senibina diedarkan TDSQL terdiri daripada tiga komponen teras:

Proxy (lapisan gerbang): Ia adalah pintu gerbang. Apabila pelanggan dan Aplikasi disambungkan ke pangkalan data, semuanya disambungkan ke Proxy. Proksi bertanggungjawab untuk mengedarkan permintaan, resolusi SQL dan penghalaan. Ini membuat anda merasa bahawa anda masih menggunakan MySQL yang berdiri sendiri.

Shard/DB (lapisan penyimpanan): Di sinilah data benar-benar berfungsi dan disimpan. TDSQL peringkat perusahaan biasanya menggunakan seni bina yang sangat tersedia "satu master dan dua sandaran". Node utama (Master) digantung, Multi-Sync akan memastikan bahawa data tidak hilang sama sekali, dan Slave secara automatik akan naik dalam beberapa saat.

ZooKeeper/Scheduler (lapisan penjadualan pengurusan): ia adalah otak. Bertanggungjawab memantau status semua nod, menyebarkan konfigurasi, dan memulakan arahan sandaran.

"Sandaran" yang kita bicarakan hari ini adalah proses di mana pihak pengurusan memberikan arahan kepada lapisan penyimpanan, mengemas data, dan memuntahkannya dengan selamat ke penyimpanan luar talian (biasanya penyimpanan objek Tencent Cloud COS).

Tahap kedua: pertempuran sebenar sandaran penuh dan tambahan peringkat perusahaan

Dalam persekitaran pengeluaran perusahaan, strategi sandaran umumnya:

Sandaran log fizikal masa nyata (Binlog) secara berkala

。

Sandaran penuh: Biasanya semasa tempoh puncak perniagaan rendah (seperti 2:00-4:00 pagi), data fizikal dieksport sepenuhnya.

Sandaran tambahan: Binlog sandaran tanpa gangguan 24 jam. Dengan gabungan keduanya, anda dapat mengembalikan pangkalan data ke keadaan kedua dalam 30 hari terakhir (PITR, pemulihan berdasarkan masa).

1. Strategi automasi konfigurasi konsol (aliran bebas bimbang)

Log masuk ke Tencent Cloud Console, cari dan masukkan "TDSQL Pangkalan Data Teragih".

Klik ID contoh anda dalam senarai contoh, dan cari "Pemulihan Sandaran"-> "Tetapan Sandaran" di menu kiri.

Spesifikasi konfigurasi dasar: kitaran sandaran penuh: persekitaran pengeluaran perusahaan disyorkan sekurang-kurangnya dua kali seminggu (seperti hari Isnin,

Pagi Khamis), perniagaan teras dengan perubahan data yang besar disarankan sekali sehari. Hari penyimpanan sandaran: Secara amnya ditetapkan pada 30 hari, dan syarat pematuhan kewangan biasanya memerlukan 180 hari atau lebih. Tetingkap masa sandaran automatik: Anda mesti mengejutkan puncak perniagaan dan memilih awal pagi.

2. Baris arahan secara manual mencetuskan sandaran penuh (aliran kecemasan)

Kadang-kadang untuk melepaskan ciri-ciri baru utama pada jam 3 petang, struktur jadual pangkalan data (DDL) perlu diubah suai. Untuk mengelakkan rollover, anda mesti membuat sandaran secara manual sekali sebelum dibebaskan.

Pada nod pengurusan TDSQL (jadual pengurusan Red Rabbit atau melalui API/CLI), anda boleh melakukan logik sandaran manual berikut:

Bash

# Contoh: Memanggil arahan komponen sandaran melalui alat tdsql

Tdsql_backup-instance_id = tdsql-abc12345-backup_method = snapshot-type = full

Pada masa ini, komponen sandaran (Backup) di latar belakang secara langsung akan pergi ke nod sandaran (untuk mengelakkan mempengaruhi prestasi nod utama) untuk mengambil gambar fizikal dan memuat naiknya secara tidak segerak ke storan sejuk Tencent Cloud.

Tahap ketiga: pertempuran pemulihan yang mendebarkan (dua senario bencana)

Tidak kira seberapa baik sandaran dilakukan, ia akan menjadi sifar jika tidak dapat dipulihkan. Kami secara langsung mensimulasikan dua senario bencana yang menjadikan operasi dan penyelenggaraan serta perkembangan tekanan darah melambung tinggi.

Senario 1: Menderita ransomware atau kerosakan pada keseluruhan perkakasan perpustakaan (keseluruhan fail perpustakaan)

Pada masa ini, gudang pengeluaran anda telah dihapuskan sepenuhnya, dan anda perlu mencari versi sejarah yang lengkap untuk "menghidupkan kembali".

Langkah praktikal:

Potong sumber air: Segera blok semua permintaan penulisan aplikasi luaran dalam kumpulan keselamatan atau lapisan Proxy untuk mengelakkan pencemaran sekunder.

Mulakan proses retracement: Pada konsol TDSQL, klik "Sandaran dan Pulihkan"-> "Retracement Contoh". Pilih "Fail Contoh Baru" (Jangan terus menimpa contoh pengeluaran asal! Amalan standard perusahaan adalah mengembalikan fail ke "contoh baru sementara" terlebih dahulu, dan kemudian memotong lalu lintas setelah mengesahkan bahawa ia betul). Pilih titik waktu pengembalian: tepat pada saat anda ingin pulih (contohnya: 2026-05-29 14:00:00).

Logik operasi latar belakang: Pada masa ini, penjadual TDSQL akan pergi ke COS untuk memuat turun sandaran penuh pada awal pagi yang paling dekat dengan jam 14:00, unzip dan pulihkan ke mesin baru, dan kemudian memainkan semula semua kenaikan Binlog dari awal pagi hingga 14:00.

Mengesahkan dan memotong aliran: Selepas beberapa minit hingga berpuluh-puluh minit, contoh baru sudah siap. Pembangun masuk untuk memeriksa data, dan setelah mengesahkan bahawa ia betul, ubah sambungan pangkalan data (alamat VIP/Proksi) dalam konfigurasi aplikasi, arahkan ke contoh baru, dan laman web dibuka semula untuk perniagaan.

Adegan 2: Rakan sepasukan babi berjabat tangan

Jadual DELETE FROM;

Tanpa keadaan di mana (sebahagian daripada jadual berkelip kembali)

Adegan ini adalah yang paling menyusahkan. 99% data dari keseluruhan pangkalan data betul, hanya jadual teras ini yang dihapus secara tidak sengaja. Sekiranya anda melakukan keseluruhan fail perpustakaan, ini bermakna hari ini

Semua pesanan baru yang dihasilkan oleh pelanggan lain akan dihapus.

Rancangan pertempuran terbaik: kaedah pengekstrakan tahap jadual

TDSQL itu sendiri tidak mengesyorkan agar anda melakukan liputan separa secara langsung dalam contoh pengeluaran. Proses operasi standard yang selamat adalah seperti berikut:

Kembali ke perpustakaan sementara: Menurut kaedah Senario 1, pangkalan data dikembalikan ke keadaan "1 minit sebelum salah operasi" untuk menghasilkan contoh sementara.

Eksport satu jadual: Gunakan alat mysqldump untuk menyambung contoh sementara ini, dan secara berasingan mengeksport jadual yang telah dihapus secara tidak sengaja: Perpustakaan sementara Bashmysqldump -h IP -u admin -p-tables my_database damaged_table > /root/recovered_table.sql

Import perpustakaan pengeluaran: periksa fail recovered_table.sql untuk memastikan data bersih. Sair ke pangkalan data persekitaran pengeluaran sebenar, tuangkan fail SQL ini, dan capai pembaikan titik tetap yang tepat: Perpustakaan pengeluaran Bashmyql-h IP -u admin -p my_database < /root/recovered_table.sql

Operasi "mencuri balok dan mengganti tiang" ini bukan sahaja menyelamatkan data yang dihapus, tetapi juga memastikan bahawa perniagaan dalam talian yang lain tidak terganggu.

Tahap keempat: sejarah keselamatan pangkalan data peringkat perusahaan

Sama sekali, jangan sekali-kali membuat sandaran logik pada nod utama (seperti mysqldump). Dengan konkurensi yang tinggi, ini akan menyebabkan jadual kunci perpustakaan utama atau lonjakan CPU, yang secara langsung akan menyebabkan kemalangan dalam talian. Sandaran automatik TDSQL dilakukan di nod sandaran secara lalai. Sekiranya anda ingin menata data secara manual, sila kenali IP nod yang disiapkan.

Lakukan "latihan pemulihan bencana" secara berkala: Fail sandaran banyak syarikat terletak di awan, dan nampaknya dihasilkan setiap hari. Akibatnya, fail sandaran didapati rosak ketika fail dikembalikan. Syarikat memerlukan setiap suku tahun atau setengah tahun, fail sandaran mesti dikeluarkan, dan latihan pemulihan sebenar harus dilakukan di persekitaran ujian untuk memastikan data dapat berjalan setiap saat.

Gunakan konsistensi yang kuat dengan baik: Semasa membeli contoh TDSQL, pastikan untuk memeriksa sama ada "penyegerakan konsistensi yang kuat" dihidupkan. Hanya di bawah konsistensi yang kuat, pertukaran utama dan sandaran sandaran dapat mencapai RPO = 0 sebenar (kehilangan data sifar).

Ringkasan

Dalam menghadapi keselamatan data peringkat perusahaan, setiap kebetulan adalah menggali lubang untuk diri sendiri. Struktur tiga lapisan Tencent Cloud TDSQL dan mekanisme pengembalian automatik telah merangkumi logik diedarkan kompleks yang mendasari. Sebagai arkitek atau operasi dan penyelenggaraan, yang perlu anda lakukan adalah

Menetapkan strategi sandaran, memegang log inti, dan melaksanakan proses garis merah dengan ketat "kembali ke perpustakaan sementara dan pengesahan semula"

。 Sekiranya anda mempunyai makanan di tangan anda, jangan panik di hati anda. Walaupun anda menghadapi bencana data yang melampau, anda dapat menghidupkan semula sistem dalam setengah jam bercakap dan ketawa.