Bagikan melalui

Panduan Praktik Terbaik untuk pg_dump dan pg_restore pada server fleksibel di Azure Database for PostgreSQL

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel

Artikel ini mengulas opsi dan praktik terbaik untuk mempercepat pg_dump dan pg_restore. Ini juga menjelaskan konfigurasi server terbaik untuk melakukan pg_restore.

Praktik terbaik untuk pg_dump

Anda dapat menggunakan utilitas pg_dump untuk mengekstrak database server fleksibel Azure Database for PostgreSQL ke dalam file skrip atau file arsip. Beberapa opsi baris perintah yang dapat Anda gunakan untuk mengurangi waktu cadangan keseluruhan dengan menggunakan pg_dump tercantum di bagian berikut.

Format direktori(-Fd)

Opsi ini menghasilkan arsip format direktori yang dapat Anda masukkan ke pg_restore. Secara default, output dikompresi.

Pekerjaan paralel(-j)

Dengan pg_dump, Anda dapat menjalankan pekerjaan cadangan secara bersamaan dengan menggunakan opsi pekerjaan paralel. Opsi ini mengurangi total waktu cadangan tetapi meningkatkan beban pada server database. Sebaiknya Anda tiba di nilai pekerjaan paralel setelah memantau metrik server sumber dengan cermat, seperti penggunaan CPU, memori, dan IOPS (operasi input/output per detik).

Saat Anda menetapkan nilai untuk opsi pekerjaan paralel, pg_dump memerlukan hal berikut:

  • Jumlah koneksi harus sama dengan jumlah pekerjaan paralel +1, jadi pastikan untuk mengatur nilai yang max_connections sesuai.
  • Jumlah pekerjaan paralel harus kurang dari atau sama dengan jumlah vCPU yang dialokasikan untuk server database.

Kompresi(-Z0)

Opsi ini menentukan tingkat kompresi yang akan digunakan. Nol berarti tidak ada pemadatan. Pemadatan nol selama proses pg_dump dapat membantu peningkatan performa.

Tabel mengapung dan menyedot menyedot menyedot

Sebelum Anda memulai proses pg_dump, pertimbangkan apakah vakum tabel diperlukan. Kembung pada tabel secara signifikan meningkat pg_dump kali. Jalankan kueri berikut untuk mengidentifikasi blob tabel:

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

Kolom dead_pct dalam kueri ini adalah persentase tuple mati jika dibandingkan dengan tuple langsung. Nilai tinggi dead_pct untuk tabel mungkin menunjukkan bahwa tabel tidak dikosongkan dengan benar. Untuk informasi selengkapnya, lihat Penyetelan autovacuum di server fleksibel Azure Database for PostgreSQL.

Untuk setiap tabel yang Anda identifikasi, Anda dapat melakukan analisis vakum manual dengan menjalankan hal berikut:

vacuum(analyze, verbose) <table_name>

Menggunakan server PITR

Anda dapat melakukan pg_dump di server online atau langsung. Ini membuat cadangan yang konsisten bahkan jika database sedang digunakan. Ini tidak memblokir pengguna lain untuk menggunakan database. Pertimbangkan ukuran database dan kebutuhan bisnis atau pelanggan lainnya sebelum Anda memulai proses pg_dump. Database kecil mungkin kandidat yang baik untuk melakukan pg_dump di server produksi.

Untuk database besar, Anda dapat membuat server pemulihan titik waktu (PITR) dari server produksi dan melakukan proses pg_dump di server PITR. Menjalankan pg_dump pada PITR akan menjadi proses cold run. Trade-off untuk pendekatan ini adalah Anda tidak akan khawatir dengan pemanfaatan CPU, memori, dan IO tambahan yang dilengkapi dengan proses pg_dump yang berjalan di server produksi aktual. Anda dapat menjalankan pg_dump di server PITR lalu menjatuhkan server PITR setelah proses pg_dump selesai.

Sintaks untuk pg_dump

Gunakan sintaks berikut untuk pg_dump:

pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format

Praktik terbaik untuk pg_restore

Anda dapat menggunakan utilitas pg_restore untuk memulihkan database server fleksibel Azure Database for PostgreSQL dari arsip yang dibuat oleh pg_dump. Beberapa opsi baris perintah untuk mengurangi waktu pemulihan keseluruhan tercantum di bagian berikut.

Pemulihan paralel

Dengan menggunakan beberapa pekerjaan bersamaan, Anda dapat mengurangi waktu yang diperlukan untuk memulihkan database besar di server target multi-vCore. Jumlah pekerjaan dapat sama dengan atau kurang dari jumlah vCPU yang dialokasikan untuk server target.

Parameter server

Jika Anda memulihkan data ke server baru atau server nonproduksi, Anda dapat mengoptimalkan parameter server berikut sebelum menjalankan pg_restore:

work_mem = 32 MB
max_wal_size = 65536 (64 GB)
checkpoint_timeout = 3600 #60min
maintenance_work_mem = 2097151 (2 GB)
autovacuum = nonaktif
wal_compression = pada

Setelah pemulihan selesai, pastikan bahwa semua parameter ini diperbarui dengan tepat sesuai persyaratan beban kerja.

Catatan

Ikuti rekomendasi sebelumnya hanya jika ada cukup ruang memori dan disk. Jika Anda memiliki server kecil dengan 2, 4, atau 8 vCore, atur parameter yang sesuai.

Pertimbangan lain

  • Nonaktifkan ketersediaan tinggi (HA) sebelum menjalankan pg_restore.
  • Analisis semua tabel yang dimigrasikan setelah pemulihan selesai.

Sintaks untuk pg_restore

Gunakan sintaks berikut untuk pg_restore:

pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>

  • -Fd: Format direktori.
  • -j: Jumlah pekerjaan.
  • -C: Mulai output dengan perintah untuk membuat database itu sendiri lalu sambungkan kembali ke dalamnya.

Berikut adalah contoh bagaimana sintaks ini mungkin muncul:

pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format

Pertimbangan komputer virtual

Buat komputer virtual di wilayah dan zona ketersediaan yang sama, sebaiknya tempat Anda memiliki server target dan sumber Anda. Atau, minimal, buat komputer virtual lebih dekat ke server sumber atau server target. Kami menyarankan agar Anda menggunakan Azure Virtual Machines dengan SSD lokal berkinerja tinggi.

Untuk informasi selengkapnya tentang SKU, lihat:

Contoh

Berikut adalah beberapa contoh cara menggunakan pg_dump dan pg_restore dengan praktik terbaik yang dibahas di atas.

Menggunakan pg_dump dengan format direktori dan pekerjaan paralel

pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
  -Fd -j 4 -f /backups/mydb_dump_dir

Penjelasan:

  • -Fd: Cadangan dalam format direktori, yang diperlukan untuk pemulihan paralel.
  • -j 4: Menggunakan 4 pekerjaan paralel untuk mempercepat dump.
  • -f: Menentukan direktori keluaran.

Menggunakan pg_dump tanpa kompresi untuk performa

pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
  -F c -Z 0 -f /backups/mydb_nocompress.dump

Penjelasan:

  • -F c: Format kustom.
  • -Z 0: Menonaktifkan kompresi untuk meningkatkan performa.

Menggunakan pg_restore dengan observasi paralel

pg_restore -h <server>.postgres.database.azure.com -U <username> -d <target_database> \
  -Fd -j 4 /backups/mydb_dump_dir

Penjelasan:

  • -Fd: Cocok dengan format direktori yang digunakan dalam cadangan.
  • -j 4: Menggunakan 4 pekerjaan paralel untuk mempercepat pemulihan.

Konten terkait