How To Set Up Continuous Archiving and Perform Point-In-Time-Recovery with PostgreSQL 12 on Ubuntu 20.04
Cara Mengatur Pengarsipan Berkelanjutan dan Melakukan Pemulihan Point-In-Time dengan PostgreSQL 12 di Ubuntu 20.04
Penulis memilih Diversity in Tech Fund untuk menerima donasi sebagai bagian dari program Write for DOnations .
Perkenalan
PostgreSQL adalah database relasional yang banyak digunakan yang mendukung transaksi ACID . Akronim ACID adalah singkatan dari atomisitas, konsistensi, isolasi, dan daya tahan. Ini adalah empat properti utama transaksi database yang didukung PostgreSQL untuk memastikan persistensi dan validitas data dalam database.
Salah satu metode yang digunakan PostgreSQL untuk mempertahankan properti ACID adalah Write-Ahead Logging (WAL) . PostgreSQL pertama-tama mencatat transaksi apa pun di database ke file log WAL sebelum menulis perubahan ke file data cluster database.
Dengan pengarsipan berkelanjutan, file WAL disalin ke penyimpanan sekunder, yang memiliki beberapa keuntungan. Misalnya, klaster database sekunder dapat menggunakan file WAL yang diarsipkan untuk tujuan replikasi, namun Anda juga dapat menggunakan file tersebut untuk melakukan pemulihan titik waktu (PITR). Artinya, Anda dapat menggunakan file tersebut untuk mengembalikan cluster database ke titik yang diinginkan jika terjadi kecelakaan.
Dalam tutorial ini, Anda akan mengatur pengarsipan berkelanjutan dengan cluster PostgreSQL 12 di Ubuntu 20.04 dan melakukan PITR pada cluster tersebut.
Prasyarat
Untuk menyelesaikan tutorial ini, Anda memerlukan yang berikut ini:
Sebuah mesin tunggal yang menjalankan Ubuntu 20.04. Panduan Pengaturan Server Awal akan memandu Anda dalam menyiapkan server termasuk pengguna non-root dengan izin yang sesuai.
PostgreSQL 12 berjalan di mesin. Langkah 1 dari tutorial Cara Menginstal dan Menggunakan PostgreSQL di Ubuntu 20.04 mencakup instalasi PostgreSQL 12 di Ubuntu 20.04.
Langkah 1 — Mengonfigurasi Pengarsipan Berkelanjutan pada Cluster Database
Pada langkah pertama ini, Anda perlu mengonfigurasi klaster PostgreSQL 12 untuk mengarsipkan file WAL klaster di direktori yang berbeda dari direktori data klaster. Untuk melakukan ini, Anda harus terlebih dahulu membuat direktori baru di suatu tempat untuk mengarsipkan file WAL.
Buat direktori baru sebagai berikut:
Anda sekarang perlu memberikan postgresizin kepada pengguna PostgreSQL default, untuk menulis ke direktori ini. Anda dapat melakukannya dengan mengubah kepemilikan direktori menggunakan chownperintah:
Sekarang Anda telah menyiapkan direktori untuk cluster untuk mengarsipkan file WAL, Anda harus mengaktifkan pengarsipan di postgresql.conffile konfigurasi, yang dapat Anda temukan di /etc/postgresql/12/main/direktori secara default.
Buka file konfigurasi dengan editor teks Anda:
Setelah Anda membuka file, Anda akan menghapus komentar pada baris dengan archive_modevariabel di dalamnya dengan menghapus #dari awal baris. Ubah juga nilainya archive_modemenjadi onseperti berikut:
. . .
archive_mode = on
. . .
Anda juga akan menentukan perintah yang digunakan klaster untuk mengarsipkan file. PostgreSQL menyediakan perintah arsip yang dapat digunakan untuk tutorial ini, yang dapat Anda baca di dokumen resmi PostgreSQL . Batalkan komentar pada archive_commandvariabel dan tambahkan perintah berikut:
. . .
archive_command = 'test ! -f /path/to/database_archive/%f && cp %p /path/to/database_archive/%f'
. . .
Perintah arsip di sini pertama-tama memeriksa apakah file WAL sudah ada di arsip, dan jika tidak, ia akan menyalin file WAL ke arsip.
Ganti /path/to/database_archivedengan jalur ke database_archivedirektori yang Anda buat sebelumnya. Misalnya, jika Anda membuat ini di direktori home Anda: ~/database_archive.
Terakhir, Anda perlu mengkonfigurasi wal_levelvariabel. wal_levelmenentukan berapa banyak informasi yang ditulis PostgreSQL ke log. Untuk pengarsipan berkelanjutan, ini harus diatur setidaknya ke replica:
. . .
#wal_level = replica
. . .
Ini sudah menjadi nilai default di PostgreSQL 12, jadi Anda tidak perlu mengubahnya, tetapi perlu diingat jika Anda ingin mengubah variabel ini.
Anda sekarang dapat menyimpan dan keluar dari file Anda.
Untuk menerapkan perubahan pada file konfigurasi klaster database, Anda perlu memulai ulang klaster sebagai berikut:
Jika PostgreSQL berhasil dimulai ulang, cluster akan mengarsipkan setiap file WAL setelah penuh. Secara default, setiap file WAL berukuran 16 MB.
Jika Anda perlu segera mengarsipkan transaksi, Anda dapat memaksa klaster database untuk mengubah dan mengarsipkan file WAL saat ini dengan menjalankan perintah berikut pada klaster:
Dengan klaster database berhasil menyalin file WAL ke arsip, Anda kini dapat melakukan pencadangan fisik file data klaster database.
Langkah 2 — Melakukan Pencadangan Fisik pada Cluster PostgreSQL
Penting untuk melakukan pencadangan database secara rutin untuk membantu mengurangi kehilangan data jika hal terburuk terjadi. PostgreSQL memungkinkan Anda mengambil cadangan logis dan fisik dari cluster database. Namun, untuk PITR, Anda perlu mengambil cadangan fisik dari cluster database. Artinya, Anda perlu membuat salinan semua file database di direktori data PostgreSQL. Secara default, direktori data PostgreSQL 12 adalah /var/lib/postgresql/12/main/.
Catatan: Anda juga dapat menemukan lokasi direktori data dengan menjalankan perintah berikut pada klaster:
Pada langkah sebelumnya, Anda membuat direktori,, database_archiveuntuk menyimpan semua file WAL yang diarsipkan. Pada langkah ini Anda perlu membuat direktori lain bernama database_backup, untuk menyimpan cadangan fisik yang akan Anda ambil.
Sekali lagi, buatlah direktori:
Sekarang pastikan bahwa postgrespengguna memiliki izin untuk menulis ke direktori dengan mengubah kepemilikan:
Sekarang Anda memiliki direktori untuk pencadangan, Anda perlu melakukan pencadangan fisik file data cluster database. Untungnya, PostgreSQL memiliki perintah bawaan pg_basebackupyang melakukan segalanya untuk Anda. Jalankan perintah sebagai postgrespengguna:
Ganti /path/to/dengan jalur ke direktori Anda.
Dengan pencadangan fisik klaster database ini, Anda kini dapat melakukan pemulihan point-in-time pada klaster tersebut.
Langkah 3 — Melakukan Pemulihan Point-In-Time pada Cluster Database
Sekarang Anda memiliki setidaknya satu cadangan fisik database dan Anda mengarsipkan file WAL, kini Anda dapat melakukan PITR, jika Anda perlu mengembalikan database ke keadaan sebelumnya.
Pertama, jika database masih berjalan, Anda harus mematikannya. Anda dapat melakukan ini dengan menjalankan systemctl stopperintah:
Setelah database tidak lagi berjalan, Anda perlu menghapus semua file di direktori data PostgreSQL. Namun pertama-tama, Anda perlu memindahkan pg_waldirektori ke tempat lain karena mungkin berisi file WAL yang belum diarsipkan dan penting untuk pemulihan. Gunakan mvperintah untuk memindahkan pg_waldirektori sebagai berikut:
Sekarang, Anda dapat menghapus /var/lib/postgresql/12/mainseluruh direktori dan membuatnya kembali seperti ini:
Diikuti oleh:
Sekarang, Anda perlu menyalin semua file dari cadangan fisik yang Anda buat pada langkah sebelumnya ke direktori data kosong yang baru. Anda dapat melakukannya dengan cp:
Anda juga perlu memastikan direktori data memiliki postgrespengguna sebagai pemilik dan izin yang sesuai. Jalankan perintah berikut untuk mengubah pemilik:
Dan perbarui izin:
File WAL di pg_waldirektori yang disalin dari cadangan fisik sudah usang dan tidak berguna. Anda perlu menggantinya dengan file WAL di pg_waldirektori yang Anda salin sebelum mengosongkan direktori data PostgreSQL karena beberapa file mungkin belum diarsipkan sebelum menghentikan server.
Hapus pg_walfile di /var/lib/postgresql/12/maindirektori sebagai berikut:
Sekarang salin file dari pg_waldirektori yang Anda simpan sebelum membersihkan direktori data:
Dengan direktori data dipulihkan dengan benar, Anda perlu mengkonfigurasi pengaturan pemulihan untuk memastikan server database memulihkan file WAL yang diarsipkan dengan benar. Pengaturan pemulihan ditemukan di postgresql.conffile konfigurasi di /etc/postgresql/12/main/direktori.
Buka file konfigurasi:
Setelah file terbuka, cari restore_commandvariabel dan hapus #karakter dari awal baris. Sama seperti yang Anda lakukan archive_commandpada langkah pertama, Anda perlu menentukan bagaimana PostgreSQL memulihkan file WAL. Karena archiveperintahnya hanya menyalin file ke arsip, restoreperintah tersebut akan menyalin file kembali. Variabelnya restore_commandakan serupa dengan berikut ini:
. . .
restore_command = 'cp /path/to/database_archive/%f %p'
. . .
Ingatlah untuk mengganti /path/to/database_archive/dengan jalur ke direktori arsip Anda.
Selanjutnya, Anda memiliki opsi untuk menentukan target pemulihan. Ini adalah titik di mana klaster database akan mencoba memulihkan sebelum keluar dari mode pemulihan. Target pemulihan dapat berupa stempel waktu, ID transaksi, nomor urut log, nama titik pemulihan yang dibuat dengan pg_create_restore_point()perintah, atau kapan pun database mencapai keadaan konsisten. Jika tidak ada target pemulihan yang ditentukan, cluster database akan membaca seluruh log file WAL dalam arsip.
Untuk daftar lengkap opsi variabel recovery_target, lihat dokumentasi resmi PostgreSQL .
Catatan: Target pemulihan harus merupakan titik waktu setelah cadangan fisik yang Anda gunakan diambil. Jika Anda perlu kembali ke titik sebelumnya, maka Anda perlu menggunakan cadangan database sebelumnya.
Setelah Anda mengatur restore_commanddan recovery_target, simpan dan keluar dari file.
Sebelum memulai ulang klaster database, Anda perlu memberi tahu PostgreSQL bahwa cluster tersebut harus dimulai dalam mode pemulihan. Anda dapat mencapai hal ini dengan membuat file kosong di direktori data cluster yang disebut recovery.signal. Untuk membuat file kosong di direktori, gunakan touchperintah:
Sekarang Anda dapat memulai ulang klaster database dengan menjalankan:
Jika database berhasil dimulai, maka akan masuk ke mode pemulihan. Setelah cluster database mencapai target pemulihan, recovery.signalfile tersebut akan dihapus.
Sekarang setelah Anda berhasil memulihkan klaster database ke kondisi yang diinginkan, Anda dapat memulai operasi database normal. Jika Anda ingin memulihkan ke titik waktu lain, Anda dapat mengulangi langkah ini.
Kesimpulan
Dalam tutorial ini, Anda menyiapkan klaster database PostgreSQL 12 untuk mengarsipkan file WAL dan kemudian Anda menggunakan file WAL yang diarsipkan untuk melakukan pemulihan titik waktu. Anda sekarang dapat mengembalikan klaster database ke keadaan yang diinginkan jika terjadi kecelakaan.
Untuk mempelajari lebih lanjut tentang pengarsipan berkelanjutan dan pemulihan tepat waktu, Anda dapat membaca dokumen .
==========================================================================================
The author selected the Diversity in Tech Fund to receive a donation as part of the Write for DOnations program.
Introduction
PostgreSQL is a widely used relational database that supports ACID transactions. The acronym ACID stands for atomicity, consistency, isolation, and durability. These are four key properties of database transactions that PostgreSQL supports to ensure the persistence and validity of data in the database.
One method PostgreSQL uses to maintain ACID properties is Write-Ahead Logging (WAL). PostgreSQL first records any transaction on the database to the WAL log files before it writes the changes to the database cluster’s data files.
With continuous archiving, the WAL files are copied to secondary storage, which has a couple of benefits. For example, a secondary database cluster can use the archived WAL file for replication purposes, but you can also use the files to perform point-in-time-recovery (PITR). That is, you can use the files to rollback a database cluster to a desirable point if an accident happens.
In this tutorial, you will set up continuous archiving with a PostgreSQL 12 cluster on Ubuntu 20.04 and perform PITR on the cluster.
Prerequisites
To complete this tutorial, you’ll need the following:
A single machine running Ubuntu 20.04. The Initial Server Setup Guide will walk you through setting up the server including non-root users with the appropriate permissions.
PostgreSQL 12 running on the machine. Step 1 of the How To Install and Use PostgreSQL on Ubuntu 20.04 tutorial covers the installation of PostgreSQL 12 on Ubuntu 20.04.
Step 1 — Configuring Continuous Archiving on the Database Cluster
In this first step, you need to configure your PostgreSQL 12 cluster to archive the cluster’s WAL files in a directory different from the cluster’s data directory. To do this, you must first create a new directory somewhere to archive the WAL files.
Create a new directory as follows:
You now need to give the default PostgreSQL user, postgres, permission to write to this directory. You can achieve this by changing the ownership of the directory using the chown command:
Now that you have a directory set up for the cluster to archive the WAL files into, you must enable archiving in the postgresql.conf configuration file, which you can find in the /etc/postgresql/12/main/ directory by default.
Open the configuration file with your text editor:
Once you have opened the file, you’ll uncomment the line with the archive_mode variable on it by removing the # from the start of the line. Also, change the value of archive_mode to on like the following:
. . .
archive_mode = on
. . .
You’ll also specify the command the cluster uses to archive the files. PostgreSQL provides an archive command that will work for this tutorial, which you can read about in the official PostgreSQL docs. Uncomment the archive_command variable and add the following command:
. . .
archive_command = 'test ! -f /path/to/database_archive/%f && cp %p /path/to/database_archive/%f'
. . .
The archive command here first checks to see if the WAL file already exists in the archive, and if it doesn’t, it copies the WAL file to the archive.
Replace the /path/to/database_archive with the path to the database_archive directory you created earlier. For example, if you created this in your home directory: ~/database_archive.
Lastly, you need to configure the wal_level variable. wal_level dictates how much information PostgreSQL writes to the log. For continuous archiving, this needs to be set to at least replica:
. . .
#wal_level = replica
. . .
This is already the default value in PostgreSQL 12, so you shouldn’t need to change it, but it is something to remember if you ever go to change this variable.
You can now save and exit your file.
To implement the changes to your database cluster configuration file, you need to restart the cluster as follows:
If PostgreSQL restarts successfully, the cluster will archive every WAL file once it is full. By default, each WAL file is 16MB.
In the case that you need to archive a transaction immediately, you can force the database cluster to change and archive the current WAL file by running the following command on the cluster:
With the database cluster successfully copying the WAL files to the archive, you can now perform a physical backup of the database cluster’s data files.
Step 2 — Performing a Physical Backup of the PostgreSQL Cluster
It is important to take regular backups of your database to help mitigate data loss should the worst happen. PostgreSQL allows you to take both logical and physical backups of the database cluster. However, for PITR, you need to take a physical backup of the database cluster. That is, you need to make a copy of all the database’s files in PostgreSQL’s data directory. By default, the PostgreSQL 12 data directory is /var/lib/postgresql/12/main/.
Note: You can also find the location of the data directory by running the following command on the cluster:
In the previous step, you made the directory, database_archive, to store all the archived WAL files. In this step you need to create another directory, called database_backup, to store the physical backup you will take.
Once again, make the directory:
Now ensure that the postgres user has permission to write to the directory by changing the ownership:
Now that you have a directory for the backup, you need to perform a physical backup of the database cluster’s data files. Fortunately, PostgreSQL has the built-in pg_basebackup command that performs everything for you. Run the command as the postgres user:
Replace /path/to/ with the path to your directory.
With this physical backup of the database cluster, you are now able to perform point-in-time-recovery on the cluster.
Step 3 — Performing Point-In-Time-Recovery on the Database Cluster
Now that you have at least one physical backup of the database and you’re archiving the WAL files, you can now perform PITR, if you need to rollback the database to a previous state.
First, if the database is still running, you’ll need to shut it down. You can do this by running the systemctl stop command:
Once the database is no longer running, you need to remove all the files in PostgreSQL’s data directory. But first, you need to move the pg_wal directory to a different place as this might contain unarchived WAL files that are important for recovery. Use the mv command to move the pg_wal directory as follows:
Now, you can remove the /var/lib/postgresql/12/main directory entirely and recreate it as such:
Followed by:
Now, you need to copy all the files from the physical backup you made in the previous step to the new empty data directory. You can do this with cp:
You also need to ensure the data directory has the postgres user as the owner and the appropriate permissions. Run the following command to change the owner:
And update the permissions:
The WAL files in the pg_wal directory copied from the physical backup are outdated and not useful. You need to replace them with the WAL files in the pg_wal directory that you copied before you emptied out the PostgreSQL’s data directory as some of the files might not have been archived before stopping the server.
Remove the pg_wal file in the /var/lib/postgresql/12/main directory as follows:
Now copy the files from the pg_wal directory you saved before clearing out the data directory:
With the data directory restored correctly, you need to configure the recovery settings to ensure the database server recovers the archived WAL files correctly. The recovery settings are found in the postgresql.conf configuration file in the /etc/postgresql/12/main/ directory.
Open the configuration file:
Once you have the file open, locate the restore_command variable and remove the # character from the start of the line. Just like you did with archive_command in the first step, you need to specify how PostgreSQL should recover the WAL files. Since the archive command just copies the files to the archive, the restore command will copy the files back. The restore_command variable will be similar to the following:
. . .
restore_command = 'cp /path/to/database_archive/%f %p'
. . .
Remember to replace /path/to/database_archive/ with the path to your archive directory.
Next, you have the option to specify a recovery target. This is the point that the database cluster will try to recover to before leaving recovery mode. The recovery target can be a timestamp, transaction ID, log sequence number, the name of a restore point created with the pg_create_restore_point() command, or whenever the database reaches a consistent state. If no recovery target is specified, the database cluster will read through the entire log of WAL files in the archive.
For a complete list of options for the recovery_target variable, consult the official PostgreSQL documentation.
Note: The recovery target must be a point in time after the physical backup you are using was taken. If you need to return to an earlier point, then you need to use an earlier backup of the database.
Once you have set restore_command and recovery_target, save and exit the file.
Before restarting the database cluster, you need to inform PostgreSQL that it should start in recovery mode. You can achieve this by creating an empty file in the cluster’s data directory called recovery.signal. To create an empty file in the directory, use the touch command:
Now you can restart the database cluster by running:
If the database started successfully, it will enter recovery mode. Once the database cluster reaches the recovery target, it will remove the recovery.signal file.
Now that you have successfully recovered your database cluster to the desired state, you can begin your normal database operations. If you want to recover to a different point in time, you can repeat this step.
Tidak ada komentar:
Posting Komentar