Prestasi Pemulihan Sandaran MySQL dan PostgreSQL: Analisis Mendalam dan Strategi Optimum

Senario

Sebuah platform e-dagang menggunakan MySQL 8.0 dan PostgreSQL 13 dengan sandaran logik (mysqldump/pg_dump). Apabila pangkalan data berkembang ke 500GB, masa pemulihan meningkat dari 20 minit ke 2 jam, melebihi RTO 1 jam.

Gejala

• Penggunaan CPU 100% semasa pemulihan, masa menunggu I/O cakera >50%
• Jalur lebar rangkaian tepu semasa pemindahan fail sandaran
• Ralat konsistensi data (contoh: pelanggaran kekunci asing) selepas pemulihan

Diagnosis

1. Kaedah sandaran: Sandaran logik mengimbas baris demi baris; sandaran fizikal (Xtrabackup/pg_basebackup) adalah salinan blok dan lebih pantas. Periksa kaedah semasa dengan mysqldump --version atau pg_dump --version.
2. Bottleneck I/O: Gunakan iostat -x 1 untuk melihat avgqu-sz (>10) dan await (>30ms), menunjukkan storan perlahan.
3. Mampatan vs CPU: Sandaran menggunakan gzip/pigz; penyahmampatan menjadi CPU-bound semasa pemulihan. Masa setiap fasa dengan arahan time.
4. Parameter pangkalan data: Periksa jika MySQL innodb_buffer_pool_size atau PostgreSQL shared_buffers terlalu besar, menyebabkan persaingan memori.

Arahan

• MySQL:
• Batalkan pemulihan: KILL QUERY + ROLLBACK (peringkat pernyataan)
• Lumpuhkan log binari: SET SQL_LOG_BIN=0; (mengurangkan penulisan log)
• Pemulihan selari dengan mysqlpump: mysqlpump --parallel-schemas=4:dbname --default-parallelism=4
• PostgreSQL:
• Laraskan checkpoint_completion_target=0.9 untuk mengurangkan lonjakan IO
• Pemulihan selari: pg_restore -j 4 -d dbname backup.dump
• Lumpuhkan komit segerak: SET synchronous_commit=off;
• Sistem: nice -n19 tar czf - /backup | pv -b -t -e > /dev/null untuk mengurangkan keutamaan I/O

Kawalan Risiko

• Lakukan pemulihan semasa tetingkap penyelenggaraan dengan snapshot terkini tersedia
• Gunakan ionice -c2 -n7 untuk menetapkan keutamaan I/O proses sandaran kepada melahu (idle)
• Sahkan integriti sandaran: MySQL CHECKSUM TABLE; PostgreSQL pg_checksums
• Pantau beban sistem dengan sar -u -b 1

Undur (Rollback)

Jika pemulihan gagal atau melebihi masa: 1. Hentikan proses pemulihan (pkill pg_restore) 2. Tukar lalu lintas ke replika baca sahaja (contoh: standby yang disediakan) 3. Bina semula utama dari snapshot: tar tulis ganti fail fizikal (memerlukan penutupan pangkalan data) 4. Sahkan data: SELECT COUNT(*) FROM key_table;

Pengesahan

• Kiraan baris: SELECT COUNT(*) FROM key_table; pada sumber dan yang dipulihkan
• Checksum: MySQL pt-table-checksum; PostgreSQL pg_comparator
• Ujian aplikasi: Jalankan pertanyaan biasa dan periksa latensi
• Replikasi: SHOW SLAVE STATUS atau pg_replication_slots

Bila Menghantar Tiket OpsGlobal

• Masa pemulihan secara konsisten melebihi RTO perniagaan walaupun telah dioptimumkan
• Kekurangan kepakaran dalaman dalam penalaan prestasi pangkalan data atau storan
• Perlu pemulihan merentas rantau (contoh: dari pusat DR jauh)
• Keperluan pematuhan (contoh: GDPR) memerlukan audit pihak ketiga
• Apabila strategi sandaran (contoh: kekerapan sandaran penuh) memerlukan reka bentuk semula oleh pakar

Semasa menghantar, sertakan: versi pangkalan data, saiz ruang jadual, arahan sandaran, tempoh pemulihan, data pemantauan sumber (CPU/IO/rangkaian), dan langkah yang telah dicuba.