Panduan Praktikal Pengoptimuman Prestasi Sandaran dan Pemulihan MySQL dan PostgreSQL

Senario

Pangkalan data teras perusahaan (MySQL 8.0 / PostgreSQL 14) mengalami masa sandaran yang panjang (>6 jam) dan kegagalan pemulihan (RTO tidak tercapai) semasa waktu sibuk. Pasukan operasi perlu meningkatkan kecekapan sandaran/pemulihan tanpa gangguan perkhidmatan.

Gejala

• Tugas sandaran kerap tamat masa, pemantauan menunjukkan lonjakan CPU/IO.\n- Ujian pemulihan gagal kerana ketidakselarasan data, menghalang permulaan perkhidmatan.\n- MySQL: SHOW PROCESSLIST menunjukkan banyak pernyataan ALTER TABLE menyekat thread sandaran.\n- PostgreSQL: pg_stat_activity mempunyai VACUUM atau ANALYZE yang berjalan lama.

Diagnosis

1. Strategi Sandaran: Tentukan sama ada menggunakan sandaran logik (mysqldump/pg_dump) atau fizikal (xtrabackup/pg_basebackup). Sandaran logik berprestasi rendah dengan jumlah data yang besar.\n2. Storan dan I/O: Gunakan iostat -x 1 untuk memeriksa masa menunggu I/O cakera (%util>90% menunjukkan kesesakan). Pantau rangkaian jika sandaran ke storan jauh.\n3. Aktiviti Pangkalan Data: Periksa transaksi panjang atau kunci meja. MySQL: SELECT * FROM information_schema.innodb_trx; PostgreSQL: SELECT * FROM pg_stat_activity WHERE state <> 'idle'.\n4. Konfigurasi: Semak MySQL max_allowed_packet, net_buffer_length; PostgreSQL max_wal_size, checkpoint_completion_target.

Arahan dan Pengoptimuman

Pengoptimuman MySQL

• Gunakan Sandaran Fizikal: xtrabackup --backup --parallel=4 --compress --compress-threads=4 (mampatan selari).\n- Laras mysqldump: mysqldump --single-transaction --quick --max_allowed_packet=512M --net_buffer_length=16384.\n- Laras Kolam Penimbal InnoDB: SET GLOBAL innodb_buffer_pool_size=16G; (laraskan berdasarkan memori).\n- Lumpuhkan Log Binari Sementara: Hentikan tulis aplikasi sebelum sandaran atau gunakan --master-data=2.

Pengoptimuman PostgreSQL

• Gunakan pg_basebackup: pg_basebackup -h localhost -U replica -D /backup -X stream -P --compress=9 --format=tar (mampatan dan strim).\n- Laras max_wal_size: ALTER SYSTEM SET max_wal_size = '16GB'; kemudian SELECT pg_reload_conf();.\n- Pemulihan Selari: pg_restore -j 4 -d dbname backup.dump.\n- Dayakan I/O Asinkron: Tetapkan effective_io_concurrency secara munasabah (cth., 200).

Kawalan Risiko

• Periksa ruang cakera sebelum sandaran: df -h.\n- Gunakan pengguna sandaran dengan hak minimum (beri hanya hak istimewa yang perlu seperti SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT).\n- Uji dalam persekitaran ujian sebelum pengeluaran.\n- Gunakan had sumber (cth., nice -n 19 untuk mengurangkan keutamaan).

Pelan Rollback

Jika pengoptimuman gagal atau menyebabkan masalah:\n1. Pulihkan konfigurasi asal (dari fail konfigurasi sandaran atau ALTER SYSTEM RESET).\n2. Kembali ke skrip sandaran lama.\n3. Untuk alat sandaran fizikal, nyahpasang dan pasang semula versi asal.

Pengesahan

• Integriti Sandaran: MySQL mysqlcheck --check-upgrade; PostgreSQL pg_checksums -c -f.\n- Masa Pemulihan: Catat tempoh sebenar, bandingkan dengan RTO.\n- Keselarasan Data: Query sampel jadual dan bandingkan dengan sumber.\n- Kesan Prestasi: Pantau QPS dan latency semasa sandaran.

Bila Hantar Tiket OpsGlobal

• Masa sandaran/pemulihan secara konsisten melebihi RTO/RPO (cth., >4 jam).\n- Kadar kegagalan sandaran >1%.\n- Kesesakan storan atau rangkaian memerlukan perubahan infrastruktur.\n- Kerosakan data atau kegagalan pengesahan keselarasan memerlukan campur tangan pemulihan manual.