Optimum Prestasi Sandaran dan Pemulihan untuk MySQL dan PostgreSQL

Senario

Sebuah platform e-dagang menggunakan MySQL (500GB) dan PostgreSQL (300GB). Sandaran penuh mengambil masa 6 jam, pemulihan 8 jam, melebihi SLA (RTO<4j, RPO<1j).

Gejala

• CPU 100%, I/O menunggu >50% semasa sandaran.
• Tulis MySQL terhalang akibat kunci jadual.
• pg_dump PostgreSQL perlahan, arkib WAL tertangguh.
• Pemulihan mengambil 70% masa pada main semula log redo.

Diagnosis

MySQL

• SHOW GLOBAL STATUS LIKE 'Innodb_rows_inserted'; periksa kesan tulis.
• iostat -x 1 pantau latensi cakera.
• Kaji arahan sandaran: lebih suka --single-transaction --compress --quick.

PostgreSQL

• pg_stat_activity kenal pasti sesi menunggu.
• pg_statio_user_tables periksa kecekapan cache.
• pg_waldump analisis pertumbuhan WAL.

Arahan Pengoptimuman

MySQL

• Sandaran fizikal: xtrabackup --backup --parallel=4 --compress --compress-threads=4 --target-dir=/backup.
• Tingkatkan innodb_buffer_pool_size kepada 70% RAM.

PostgreSQL

• Sandaran strim: pg_basebackup -D /backup -X stream -P -v -z -Z 9 --wal-method=stream.
• Laraskan max_wal_senders dan wal_keep_segments.

Kawalan Risiko

• Gunakan --single-transaction untuk konsistensi InnoDB tanpa kunci.
• Untuk MySQL, nyahaktif --lock-tables jika sudah menggunakan transaksi.
• Uji pemulihan bulanan dalam persekitaran kotak pasir.

Rollback

• Sandaran inkremental: xtrabackup --incremental-basedir; PostgreSQL pg_basebackup dengan slot replikasi.
• Sediakan skrip PITR: mysqlbinlog untuk MySQL; pg_restore --time untuk PostgreSQL.

Pengesahan

• Selepas pemulihan, jalankan pt-table-checksum (MySQL) atau pg_verify_checksums (PostgreSQL).
• Ukur RTO sebenar dengan simulasi kegagalan.

Bila Hantar Tiket OpsGlobal

• Sandaran secara konsisten melebihi SLA walaupun telah ditala.
• Latihan pemulihan gagal; perlukan bantuan pakar.
• Isu rantaian sandaran inkremental yang kompleks.