Senario

Bayangkan anda seorang SRE on-call untuk platform e-dagang yang menggunakan campuran pangkalan data MySQL dan PostgreSQL. Pada pukul 2 pagi, satu pekerjaan yang salah konfigurasi memadam jadual penting. Anda tergesa-gesa untuk memulihkan daripada sandaran terkini, hanya untuk mendapati bahawa sandaran diambil 12 jam yang lalu, dan proses pemulihan berjalan perlahan. Pangkalan data penuh ialah 500 GB, dan alat sandaran semasa mengambil masa 6 jam untuk disimpan dan 4 jam untuk dipulihkan. RTO anda ialah 2 jam. Ini adalah kegagalan prestasi sandaran/pemulihan klasik.

Dalam artikel ini, kami akan membincangkan cara mendiagnosis dan menghapuskan ketidakseimbangan prestasi sandaran dan pemulihan untuk MySQL dan PostgreSQL, menggunakan arahan konkrit dan perubahan seni bina. Kami juga akan mentakrifkan sempadan apa yang boleh anda lakukan sendiri dengan selamat, dan bila untuk menyerahkan kepada OpsGlobal.

Gejala

Gejala biasa yang menunjukkan isu prestasi sandaran/pemulihan:

• Pekerjaan sandaran selalu melebihi tetingkap penyelenggaraan.
• Pemulihan mengambil masa berjam-jam, melebihi RTO.
• Penggunaan CPU dan I/O meningkat semasa sandaran, memberi kesan kepada pengeluaran.
• Lebar jalur rangkaian tepu semasa sandaran dialirkan ke storan jauh.
• Pemulihan gagal disebabkan fail sandaran rosak atau tidak konsisten.
• Saiz sandaran terlalu besar kerana mampatan tidak dioptimumkan.

Diagnosis

Sebelum menambah perkakasan, kenal pasti kesesakan yang tepat.

1. Pemilihan alat: Tentukan sama ada anda menggunakan sandaran logik atau fizikal. Sandaran logik (mysqldump, pg_dump) lebih perlahan dan menjana snapshot tidak konsisten melainkan dikendalikan dengan betul. Sandaran fizikal (Percona XtraBackup, pg_basebackup) lebih pantas dan menyalin fail data secara langsung.
2. Konfigurasi: Periksa mampatan, keselarian, dan saiz buffer. Lalai selalunya konservatif.
3. Subsistem I/O: Ukur throughput cakera dengan iostat, iotop, dan rangkaian dengan iftop semasa sandaran ujian.
4. Kunci pangkalan data: Periksa transaksi lama yang menyekat kunci kongsi yang diperlukan untuk sandaran logik konsisten.
5. Integriti sandaran: Sahkan bahawa sandaran boleh dipulihkan. Ramai pasukan melangkau ini sehingga bencana berlaku.

Arahan

Kami akan memberikan arahan konkrit untuk mempercepat sandaran dan pemulihan untuk kedua-dua MySQL dan PostgreSQL.

MySQL

Optimumkan sandaran logik (mysqldump)

• Gunakan transaksi tunggal dengan --single-transaction untuk konsistensi InnoDB tanpa menyekat tulis.
• Tambah --quick untuk mengelakkan penimbalan set hasil yang besar.
• Mampatkan dengan gzip untuk mengurangkan I/O dan masa pemindahan, tetapi perlu diingat ia menambahkan kos CPU.
• Gunakan --routines dan --triggers untuk mengelakkan kehilangan objek.

Contoh:

mysqldump --single-transaction --quick --routines --triggers --compress --database mydb | gzip > /backup/mybackup.sql.gz

Gunakan sandaran fizikal (Percona XtraBackup)

Untuk pangkalan data besar, sandaran fizikal adalah satu-satunya pilihan praktikal.

Arahan sandaran dengan mampatan selari:

xtrabackup --backup --parallel=4 --compress --compress-threads=4 --stream=xbstream --target-dir=/backup

Pulihkan dan sediakan:

xtrabackup --prepare --parallel=4 --target-dir=/restore

Untuk aliran lebih pantas, tambah --socket dan --no-version-check.

Menala MySQL untuk pemulihan lebih pantas

• Semasa pemulihan, tingkatkan innodb_buffer_pool_size jika RAM mencukupi.
• Gunakan innodb_parallel_read (tersedia dalam 8.0) untuk selari membaca.
• Tetapkan innodb_flush_log_at_trx_commit=2 sementara semasa beban (risiko kehilangan transaksi terkini jika OS ranap).

PostgreSQL

Sandaran logik (pg_dump)

• Gunakan dump selari: pg_dump -j 8 -Fd -Z 9 -f /backup/dump mydb
• Gunakan format direktori -Fd untuk membolehkan pemulihan selari dengan pg_restore -j.
• Gunakan -Z untuk mampatan.

Sandaran fizikal (pg_basebackup)

• Untuk pemulihan titik masa, gunakan arkib WAL. pg_basebackup pantas dan menangkap fail mentah.

Contoh:

pg_basebackup -D /backup/base -X stream -P -z -Z 5

Pemulihan dengan sokongan kerja selari

pg_restore -j 4 -d mydb /backup/dump

Penalaan konfigurasi PostgreSQL

• shared_buffers hendaklah ditetapkan kepada 25% RAM untuk prestasi pemulihan yang lebih baik.
• Tingkatkan checkpoint_completion_target kepada 0.9 untuk mengagihkan tulis.
• Gunakan max_wal_size dan min_wal_size dengan sesuai untuk mengelakkan checkpoint berlebihan.

Kawalan Risiko

• Sentiasa uji pemulihan: Jadualkan latihan pemulihan bulanan untuk memastikan integriti sandaran.
• Gunakan PITR (Pemulihan Titik Masa): Untuk MySQL, dayakan binlog; untuk PostgreSQL, gunakan arkib WAL. Ini membolehkan anda kembali ke masa tertentu selepas sandaran penuh terakhir.
• Selari tanpa kehabisan sumber: Hadkan bilangan thread selari untuk mengelakkan CPU/disk tepu dan menjejaskan pengeluaran.
• Pantau dan amaran pada tempoh sandaran: Sediakan alat seperti Prometheus/Grafana atau yang serupa untuk menjejak masa dan saiz sandaran.
• Had laju rangkaian: Jika mengalirkan sandaran, gunakan alat seperti pv atau pembentukan trafik peringkat OS untuk elak tepu lebar jalur.

Rollback

Jika pemulihan gagal atau menghasilkan data tidak konsisten, anda memerlukan prosedur rollback:

• Simpan sandaran baik yang terakhir di lokasi berasingan.
• Untuk MySQL, gunakan log binari untuk memohon transaksi sejak masa sandaran. Jika log binari terjejas, anda mungkin perlu menerima kehilangan data.
• Untuk PostgreSQL, gunakan arkib WAL untuk memainkan semula transaksi. Pastikan arkib lengkap dan boleh diakses.
• Jika penyediaan sandaran fizikal gagal, pulihkan ke sandaran yang diambil sebelum percubaan gagal, kemudian gunakan perubahan tambahan.

Pengesahan

Selepas pemulihan, lakukan pemeriksaan berikut:

• Untuk MySQL: mysqlcheck -a -c untuk mengesahkan integriti jadual.
• Untuk PostgreSQL: pg_amcheck untuk memeriksa kerosakan.
• Tanya jadual kritikal dan bandingkan kiraan baris dengan sumber (jika ada).
• Sahkan kefungsian aplikasi dengan ujian asap.
• Pastikan pangkalan data berada dalam keadaan yang dijangkakan (contohnya, transaksi terkini wujud).

Bila Perlu Menghantar Tiket OpsGlobal

Anda harus mempertimbangkan untuk menghubungi OpsGlobal apabila:

• RTO anda tidak dapat dicapai dengan proses sandaran dan pemulihan semasa, walaupun selepas penalaan.
• Anda perlu mereka bentuk semula seni bina sandaran untuk persekitaran pelbagai pangkalan data atau penggunaan Kubernetes.
• Anda tidak pasti cara menyediakan PITR atau arkib WAL yang selamat dan boleh dipercayai untuk pangkalan data anda.
• Anda memerlukan bantuan hands-on dengan ujian prestasi, penandaarasan, dan automasi sandaran/pemulihan.
• Anda memerlukan sokongan sandaran semasa migrasi kritikal atau latihan pemulihan bencana.

SRE kami sedia 24/7 untuk membantu anda melaksanakan strategi sandaran yang teguh, menala prestasi, dan memastikan data anda selamat dan boleh dipulihkan.