Menguasai Prestasi Pemulihan Sandaran dalam MySQL dan PostgreSQL: Panduan Praktikal untuk SRE

Senario

Pangkalan data produksi anda (MySQL atau PostgreSQL) mengalami masa sandaran dan pemulihan yang perlahan, menjejaskan Perjanjian Tahap Perkhidmatan (SLA).

Gejala

Tugas sandaran mengambil masa lebih lama daripada yang dijangkakan; Objektif Masa Pemulihan (RTO) dilanggar; I/O menunggu tinggi semasa sandaran; proses pulih yang perlahan.

Diagnosis

1. Analisis kaedah sandaran: Logik (mysqldump/pg_dump) vs fizikal (XtraBackup/pg_basebackup). Sandaran fizikal biasanya lebih cepat tetapi lebih besar.
2. Periksa sumber perkakasan: Gunakan iostat, vmstat untuk memantau I/O cakera dan beban CPU. I/O tinggi semasa sandaran mungkin bertepatan dengan perlambatan pangkalan data.
3. Penanda aras masa pemulihan: Pulihkan sandaran dalam persekitaran ujian dan ambil masa. Bandingkan tahap mampatan (contohnya gzip vs lz4).
4. Semak parameter konfigurasi: innodb_io_capacity dan innodb_flush_log_at_trx_commit MySQL mempengaruhi penulisan; wal_compression dan checkpoint_completion_target PostgreSQL mempengaruhi kelajuan sandaran.

Arahan

MySQL

• Masa mysqldump: time mysqldump -u root -p database > dump.sql
• Periksa status InnoDB: mysql> SHOW ENGINE INNODB STATUS\G untuk melihat jika utas latar belakang disekat oleh sandaran.
• Analisis pertanyaan perlahan semasa sandaran dengan Percona Toolkit: pt-query-digest /var/log/mysql/slow.log

PostgreSQL

• Masa pg_dump: time pg_dump -U postgres database > dump.sql
• Pantau pertanyaan aktif: SELECT * FROM pg_stat_activity WHERE state = 'active'; Cari pertanyaan berjalan lama yang dicetuskan oleh sandaran.
• Periksa tetapan vakum: SHOW autovacuum_vacuum_threshold; Vakum terlalu kerap boleh meningkatkan I/O.

Kawalan Risiko

• Sentiasa uji sandaran dan pemulihan pada persekitaran pementasan sebelum menggunakan perubahan ke produksi.
• Gunakan sandaran tambahan (contohnya mysqlbinlog atau pengarkiban WAL PostgreSQL) untuk mengurangkan kekerapan sandaran penuh.
• Pantau penggunaan sumber: tetapkan amaran apabila penggunaan I/O melebihi 80%.
• Tetapkan tamat masa kunci yang munasabah: lock_wait_timeout MySQL, statement_timeout PostgreSQL.
• Gunakan mampatan dengan berhati-hati: mampatan tinggi (contohnya gzip -9) menggunakan CPU dan boleh memperlahankan pangkalan data.

Pengembalian Semula

Jika prestasi sandaran merosot selepas perubahan, kembalikan parameter secara berperingkat atau tukar kembali ke kaedah sandaran sebelumnya. Sentiasa simpan konfigurasi strategi sandaran yang terakhir diketahui baik.

Pengesahan

• Sahkan integriti sandaran dengan checksum: mysqldump ... | md5sum dan bandingkan dengan sandaran sebelumnya.
• Pulihkan sandaran dalam persekitaran terpencil dan sahkan kiraan baris: SELECT COUNT(*) FROM table;
• Lakukan penulisan ujian untuk memastikan pangkalan data boleh ditulis.

Bila Menghantar Tiket OpsGlobal

• RTO secara konsisten melebihi ambang yang ditetapkan (contohnya 4 jam) dan tidak boleh diperbaiki dengan pelarasan dalaman.
• Kadar kegagalan sandaran >1% dengan punca tidak diketahui.
• Perkakasan disyaki sebagai masalah (contohnya masa tindak balas cakera >20ms) tetapi tiada keupayaan untuk menaik taraf.
• Memerlukan penilaian profesional strategi sandaran (contohnya pengarkiban awan hibrid).

Pasukan SRE OpsGlobal boleh menyediakan audit mendalam, integrasi alat, dan sokongan pemantauan 24/7.