Senario

Pangkalan data pengeluaran sering menghadapi kemerosotan prestasi semasa operasi sandaran dan pemulihan, terutamanya apabila berjalan di Kubernetes di mana penyimpanan, rangkaian, dan had sumber menambah kerumitan. Tetingkap sandaran mungkin memanjang, dan masa pemulihan boleh melebihi SLA.

Gejala

• Tempoh sandaran secara konsisten melebihi tetingkap yang dibenarkan (mis., >4 jam untuk 500GB).
• Operasi pemulihan sangat perlahan; sandaran 500GB mungkin mengambil masa lebih 6 jam.
• I/O wait tinggi, penggunaan CPU rendah, dan latensi cakera tinggi diperhatikan dalam alat pemantauan.
• Alat sandaran (pg_dump, XtraBackup) tamat masa atau gagal dengan ralat yang sukar difahami.

Diagnosis

1. Periksa kekangan sumber: bash kubectl top pods -n database Sahkan had CPU dan memori mencukupi.
2. Analisis prestasi I/O: bash iostat -x 1 Cari nilai %util dan await yang tinggi.
3. Dalaman pangkalan data: - MySQL: sql SHOW ENGINE INNODB STATUS\G; - PostgreSQL: sql SELECT * FROM pg_stat_activity WHERE state = 'active';
4. Semak log alat sandaran: - XtraBackup: Periksa xtrabackup_log. - pg_dump: Gunakan --verbose.

Arahan

Pengoptimuman Sandaran MySQL

• Sandaran selari: bash xtrabackup --backup --parallel=4 --target-dir=/backup
• Sandaran mampat: bash xtrabackup --backup --compress --compress-threads=4 --target-dir=/backup
• Had laju: bash xtrabackup --backup --throttle=100 --target-dir=/backup

Pengoptimuman Sandaran PostgreSQL

• Format direktori untuk selari: bash pg_dump -Fd -j 4 -f /backup mydb
• Format tersuai mampat: bash pg_dump -Fc -Z 9 -f /backup/dump.gz mydb

Pengoptimuman Pemulihan

• MySQL: Gunakan --apply-log dengan memori tambahan: bash xtrabackup --prepare --use-memory=4G --target-dir=/backup
• PostgreSQL: Tingkatkan maintenance_work_mem: sql SET maintenance_work_mem = '1GB';

Kawalan Risiko

• Jadual sandaran semasa trafik rendah.
• Gunakan had laju I/O.
• Simpan sandaran pada volum kekal berasingan.
• Uji prestasi pemulihan dalam persekitaran pementasan.

Pengembalian

• Jika sandaran gagal akibat perubahan parameter, kembali ke lalai.
• Jika pemulihan menghasilkan data rosak, hentikan serta-merta dan pulihkan daripada sandaran penuh yang diketahui baik.

Pengesahan

• Selepas pemulihan, jalankan pemeriksaan ketekalan:
• MySQL: checksum table atau pt-table-checksum.
• PostgreSQL: pg_checksums atau ANALYZE.
• Sahkan pertanyaan perniagaan kembali betul.

Bila Hantar Tiket OpsGlobal

• Masa sandaran/pemulihan secara konsisten melebihi SLA (mis., >4 jam).
• Berlaku kerosakan data atau kegagalan pemulihan.
• Anda memerlukan cadangan seni bina (mis., kelas penyimpanan, talaan parameter pangkalan data).
• Anda tidak pasti tentang konfigurasi kawalan risiko.

Mengikuti langkah-langkah ini, kebanyakan isu prestasi boleh diselesaikan. Jika masalah berterusan, pasukan SRE OpsGlobal boleh memberikan analisis dan pengoptimuman mendalam.