PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Cara Menggunakan pgBackRest untuk Mencadangkan PostgreSQL dan TimescaleDB

Data Anda mungkin adalah aset paling berharga di perusahaan, jadi Anda harus memiliki Disaster Recovery Plan (DRP) untuk mencegah kehilangan data jika terjadi kecelakaan atau kegagalan perangkat keras. Cadangan adalah bentuk DR yang paling sederhana. Ini mungkin tidak selalu cukup untuk menjamin Recovery Point Objective (RPO) yang dapat diterima tetapi merupakan pendekatan pertama yang baik. Juga, Anda harus menentukan Recovery Time Objective (RTO) sesuai dengan kebutuhan perusahaan Anda. Ada banyak cara untuk mencapai nilai RTO, itu tergantung pada tujuan perusahaan.

Di blog ini, kita akan melihat cara menggunakan pgBackRest untuk mencadangkan PostgreSQL dan TimescaleDB dan cara menggunakan salah satu fitur terpenting dari alat pencadangan ini, kombinasi pencadangan Penuh, Inkremental, dan Diferensial, untuk meminimalkan waktu henti.

Apa itu pgBackRest?

Ada berbagai jenis cadangan untuk basis data:

  • Logis:Cadangan disimpan dalam format yang dapat dibaca manusia seperti SQL.
  • Fisik:Cadangan berisi data biner.
  • Penuh/Penambahan/Diferensial:Definisi ketiga jenis cadangan ini tersirat dalam namanya. Cadangan lengkap adalah salinan lengkap dari semua data Anda. Incremental backup hanya mem-backup data yang telah berubah sejak backup sebelumnya dan differential backup hanya berisi data yang telah berubah sejak full backup terakhir dijalankan. Pencadangan inkremental dan diferensial diperkenalkan sebagai cara untuk mengurangi jumlah waktu dan penggunaan ruang disk yang diperlukan untuk melakukan pencadangan penuh.

pgBackRest adalah alat pencadangan sumber terbuka yang membuat pencadangan fisik dengan beberapa peningkatan dibandingkan dengan alat pg_basebackup klasik. Kita dapat menggunakan pgBackRest untuk melakukan salinan database awal untuk Replikasi Streaming dengan menggunakan cadangan yang ada, atau kita dapat menggunakan opsi delta untuk membangun kembali server siaga yang lama.

Beberapa fitur pgBackRest yang paling penting adalah:

  • Pencadangan &Pemulihan Paralel
  • Operasi Lokal atau Jarak Jauh
  • Pencadangan Penuh, Tambahan, dan Diferensial
  • Rotasi Cadangan dan Kedaluwarsa Arsip
  • Pemeriksaan Integritas Cadangan
  • Cadangan Lanjutkan
  • Pemulihan Delta
  • Enkripsi

Sekarang, mari kita lihat bagaimana kita dapat menggunakan pgBackRest untuk mem-backup database PostgreSQL dan TimescaleDB kita.

Cara Menggunakan pgBackRest

Untuk pengujian ini, kami akan menggunakan CentOS 7 sebagai OS dan PostgreSQL 11 sebagai server database. Kami akan menganggap Anda telah menginstal database, jika tidak, Anda dapat mengikuti tautan ini untuk menerapkan PostgreSQL atau TimescaleDB dengan cara yang mudah menggunakan ClusterControl.

Pertama, kita perlu menginstal paket pgbackrest.

$ yum install pgbackrest

pgBackRest dapat digunakan dari baris perintah, atau dari file konfigurasi yang terletak secara default di /etc/pgbackrest.conf pada CentOS7. File ini berisi baris berikut:

[global]
repo1-path=/var/lib/pgbackrest
#[main]
#pg1-path=/var/lib/pgsql/10/data

Anda dapat memeriksa tautan ini untuk melihat parameter mana yang dapat kami tambahkan dalam file konfigurasi ini.

Kami akan menambahkan baris berikut:

[testing]
pg1-path=/var/lib/pgsql/11/data

Pastikan Anda memiliki konfigurasi berikut yang ditambahkan di file postgresql.conf (perubahan ini memerlukan restart layanan).

archive_mode = on
archive_command = 'pgbackrest --stanza=testing archive-push %p'
max_wal_senders = 3
wal_level = logical

Sekarang, mari kita lakukan pencadangan dasar. Pertama, kita perlu membuat “stanza”, yang mendefinisikan konfigurasi cadangan untuk cluster database PostgreSQL atau TimescaleDB tertentu. Bagian bait harus menentukan jalur cluster database dan host/pengguna jika cluster database jauh.

$ pgbackrest --stanza=testing --log-level-console=info stanza-create
2019-04-29 21:46:36.922 P00   INFO: stanza-create command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:46:37.475 P00   INFO: stanza-create command end: completed successfully (554ms)

Kemudian, kita dapat menjalankan perintah check untuk memvalidasi konfigurasi.

$ pgbackrest --stanza=testing --log-level-console=info check
2019-04-29 21:51:09.893 P00   INFO: check command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:51:12.090 P00   INFO: WAL segment 000000010000000000000001 successfully stored in the archive at '/var/lib/pgbackrest/archive/testing/11-1/0000000100000000/000000010000000000000001-f29875cffe780f9e9d9debeb0b44d945a5165409.gz'
2019-04-29 21:51:12.090 P00   INFO: check command end: completed successfully (2197ms)

Untuk mengambil cadangan, jalankan perintah berikut:

$ pgbackrest --stanza=testing --type=full --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=full
WARN: option repo1-retention-full is not set, the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 15:43:21": backup begins after the next regular checkpoint completes
INFO: backup start archive = 000000010000000000000006, lsn = 0/6000028
WARN: aborted backup 20190429-215508F of same type exists, will be cleaned to remove invalid files and resumed
INFO: backup file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: full backup size = 31.8MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 000000010000000000000006, lsn = 0/6000130
INFO: new backup label = 20190429-215508F
INFO: backup command end: completed successfully (12810ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (10ms)

Sekarang, kami memiliki cadangan yang selesai dengan output "selesai dengan sukses", jadi, mari kita kembalikan. Kami akan menghentikan layanan postgresql-11.

$ service postgresql-11 stop
Redirecting to /bin/systemctl stop postgresql-11.service

Dan biarkan datadir kosong.

$ rm -rf /var/lib/pgsql/11/data/*

Sekarang, jalankan perintah berikut:

$ pgbackrest --stanza=testing --log-level-stderr=info restore
INFO: restore command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
INFO: restore backup set 20190429-215508F
INFO: restore file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: write /var/lib/pgsql/11/data/recovery.conf
INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
INFO: restore command end: completed successfully (10819ms)

Kemudian, mulai layanan postgresql-11.

$ service postgresql-11 stop

Dan sekarang kami memiliki database kami dan berjalan.

$ psql -U app_user world
world=> select * from city limit 5;
 id |      name      | countrycode |   district    | population
----+----------------+-------------+---------------+------------
  1 | Kabul          | AFG         | Kabol         |    1780000
  2 | Qandahar       | AFG         | Qandahar      |     237500
  3 | Herat          | AFG         | Herat         |     186800
  4 | Mazar-e-Sharif | AFG         | Balkh         |     127800
  5 | Amsterdam      | NLD         | Noord-Holland |     731200
(5 rows)

Sekarang, mari kita lihat bagaimana kita dapat mengambil cadangan diferensial.

$ pgbackrest --stanza=testing --type=diff --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=diff
WARN: option repo1-retention-full is not set, the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: last backup label = 20190429-215508F, version = 2.13
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 21:22:58": backup begins after the next regular checkpoint completes
INFO: backup start archive = 00000002000000000000000B, lsn = 0/B000028
WARN: a timeline switch has occurred since the last backup, enabling delta checksum
INFO: backup file /var/lib/pgsql/11/data/base/16429/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/16429/2608 (448KB, 8%) checksum 53bd7995dc4d29226b1ad645995405e0a96a4a7b
. . .
INFO: diff backup size = 40.1MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 00000002000000000000000B, lsn = 0/B000130
INFO: new backup label = 20190429-215508F_20190430-212258D
INFO: backup command end: completed successfully (23982ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (14ms)

Untuk pencadangan yang lebih kompleks, Anda dapat mengikuti panduan pengguna pgBackRest.

Seperti yang kami sebutkan sebelumnya, Anda dapat menggunakan baris perintah atau file konfigurasi untuk mengelola cadangan Anda.

Cara Menggunakan pgBackRest di ClusterControl

Sejak versi 1.7.2, ClusterControl menambahkan dukungan untuk pgBackRest untuk mencadangkan database PostgreSQL dan TimescaleDB, jadi mari kita lihat bagaimana kita dapat menggunakannya dari ClusterControl.

Membuat Cadangan

Untuk tugas ini, buka ClusterControl -> Pilih Cluster -> Backup -> Create Backup.

Kami dapat membuat cadangan baru atau mengonfigurasi yang dijadwalkan. Sebagai contoh, kami akan membuat satu cadangan secara instan.

Kita harus memilih satu metode, server dari mana cadangan akan diambil, dan di mana kita ingin menyimpan cadangan. Kami juga dapat mengunggah cadangan kami ke cloud (AWS, Google, atau Azure) dengan mengaktifkan tombol yang sesuai.

Dalam hal ini, kami akan memilih metode pgbackrestfull untuk mengambil full backup awal. Saat memilih opsi ini, kita akan melihat catatan merah berikut:

“Selama upaya pertama membuat cadangan pgBackRest, ClusterControl akan mengonfigurasi ulang node (menyebarkan dan mengonfigurasi pgBackRest) dan setelah itu node db perlu di-restart terlebih dahulu.”

Jadi, harap pertimbangkan untuk upaya pencadangan pertama.

Kemudian kita tentukan penggunaan kompresi dan level kompresi untuk backup kita.

Pada bagian backup, kita dapat melihat progres backup, dan informasi seperti metode, ukuran, lokasi, dan lainnya.

Langkah-langkahnya sama untuk membuat diferensial cadangan inkremental. Kita hanya perlu memilih metode yang diinginkan selama pembuatan backup.

Memulihkan Cadangan

Setelah backup selesai, kita dapat mengembalikannya dengan menggunakan ClusterControl. Untuk itu, pada bagian backup kita (ClusterControl -> Select Cluster -> Backup), kita bisa memilih "Restore Backup", atau langsung "Restore" pada backup yang ingin kita restore.

Kami memiliki tiga opsi untuk memulihkan cadangan. Kami dapat memulihkan cadangan di node database yang ada, memulihkan dan memverifikasi cadangan pada host mandiri atau membuat cluster baru dari cadangan.

Jika kita memilih opsi Restore on Node, kita harus menentukan node Master, karena itu adalah satu-satunya yang dapat ditulis dalam cluster.

Kami dapat memantau kemajuan pemulihan kami dari bagian Aktivitas di ClusterControl kami.

Verifikasi Pencadangan Otomatis

Cadangan bukan cadangan jika tidak dapat dipulihkan. Memverifikasi cadangan adalah sesuatu yang biasanya diabaikan oleh banyak orang. Mari kita lihat bagaimana ClusterControl dapat mengotomatiskan verifikasi cadangan PostgreSQL dan TimescaleDB dan membantu menghindari kejutan apa pun.

Di ClusterControl, pilih cluster Anda dan buka bagian "Cadangan", lalu pilih "Buat Cadangan".

Fitur verifikasi cadangan otomatis tersedia untuk pencadangan terjadwal. Jadi, mari kita pilih opsi “Jadwalkan Pencadangan”.

Saat menjadwalkan pencadangan, selain memilih opsi umum seperti metode atau penyimpanan, kami juga perlu menentukan jadwal/frekuensi.

Pada langkah selanjutnya, kita dapat mengompres cadangan dan mengaktifkan fitur “Verifikasi Cadangan”.

Untuk menggunakan fitur ini, kami memerlukan host (atau VM) khusus yang bukan bagian dari cluster.

ClusterControl akan menginstal perangkat lunak dan akan memulihkan cadangan di host ini. Setelah restore, kita bisa melihat icon verifikasi di bagian ClusterControl Backup.

Rekomendasi

Ada juga beberapa tips yang dapat kami pertimbangkan saat membuat cadangan kami:

  • Menyimpan cadangan di lokasi yang jauh:Kami tidak boleh menyimpan cadangan di server database. Jika terjadi kegagalan server, kami dapat kehilangan database dan cadangan secara bersamaan.
  • Simpan salinan cadangan terbaru di server database:Ini dapat berguna untuk pemulihan yang lebih cepat.
  • Gunakan pencadangan inkremental/diferensial:Untuk mengurangi waktu pemulihan pencadangan dan penggunaan ruang disk.
  • Cadangkan WAL:Jika kami perlu memulihkan database dari cadangan terakhir, jika Anda hanya memulihkannya, Anda akan kehilangan perubahan sejak pencadangan dilakukan hingga waktu pemulihan, tetapi jika kami memiliki WAL, kami dapat menerapkannya perubahan dan kita dapat menggunakan PITR.
  • Gunakan pencadangan Logis dan Fisik:Keduanya diperlukan untuk alasan yang berbeda, misalnya, jika kita ingin memulihkan hanya satu database/tabel, kita tidak memerlukan pencadangan fisik, kita hanya perlu pencadangan logis dan itu akan menjadi lebih cepat daripada memulihkan seluruh server.
  • Ambil cadangan dari node siaga (jika memungkinkan):Untuk menghindari beban tambahan pada node utama, sebaiknya ambil cadangan dari server siaga.
  • Uji pencadangan Anda:Konfirmasi bahwa pencadangan telah selesai tidak cukup untuk memastikan pencadangan berfungsi. Kita harus memulihkannya di server mandiri dan mengujinya untuk menghindari kejutan jika terjadi kegagalan.

Kesimpulan

Seperti yang bisa kita lihat, pgBackRest adalah pilihan yang baik untuk meningkatkan strategi pencadangan kami. Ini membantu Anda melindungi data Anda dan mungkin berguna untuk mencapai RTO dengan mengurangi waktu henti jika terjadi kegagalan. Pencadangan tambahan dapat membantu mengurangi jumlah waktu dan ruang penyimpanan yang digunakan untuk proses pencadangan. ClusterControl dapat membantu mengotomatiskan proses pencadangan untuk database PostgreSQL dan TimescaleDB Anda dan, jika terjadi kegagalan, pulihkan dengan beberapa klik.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Bagaimana saya bisa menggunakan UUID di SQLAlchemy?

  2. Catatan yang dikembalikan dari fungsi memiliki kolom yang digabungkan

  3. Bagaimana cara mengubah database_url di heroku?

  4. Postgres Cloud9

  5. Buat PERAN PostgreSQL (pengguna) jika tidak ada