Alat cadangan PostgreSQL. Andrey Salnikov (Data Egret)

Saya menyarankan Anda membaca dekripsi laporan oleh Andrey Salnikov dari Data Egret "Alat pembuatan cadangan PostgreSQL" . Pada akhirnya, tabel ringkasan alat yang diperbarui


Pembicaraan ini adalah tentang alat cadangan PostgreSQL yang tersedia. Cadangan logis, cadangan biner, alat cadangan internal, dan alat pihak ketiga. Apakah cadangan tambahan diperlukan saat mereka benar-benar dapat membantu. Mari kita lihat kapan dan alat mana yang lebih tepat untuk digunakan. Apa cara terbaik untuk mengotomatiskan proses pencadangan dan memverifikasi integritas pencadangan? Lihatlah alat-alat seperti pg_dump , pg_basebackup , barman , wal-e , wal-g , pgbackrest , BART, dan pg_probackup .



Nama saya Andrey Salnikov, saya adalah karyawan Data Egret dan laporan ini akan dikhususkan untuk alat untuk membuat cadangan di PostgreSQL.



Pertama tentang siapa kita, perusahaan saya. Aktivitas utama kami: kami bekerja sebagai administrator jarak jauh dan kami memiliki sejumlah besar klien. Ada basis besar, ada banyak basis kecil, ada semua jenis campuran ketika satu basis besar atau sekelompok kecil. Kami juga menyediakan layanan konsultasi dan audit - ini adalah kasus jika orang tidak membutuhkan dukungan terus-menerus, tetapi beberapa jenis keahlian diperlukan.
Karena PostgreSQL adalah produk sumber terbuka, kami secara alami akan berpartisipasi dalam semua jenis konferensi dalam hal berbagi pengalaman kami dan membantu PostgreSQL dengan segala cara yang mungkin. Karena database PostgreSQL sangat bagus. Dan ternyata kami melihat cukup banyak profil beban: beban DWH, dan beban WEB, serta campuran campuran. Dan basisnya jatuh dengan cara yang berbeda. Banyak pengalaman.



Ini adalah bagian paling menarik dari laporan ini. Mengapa cadangan diperlukan? Bahkan, mereka dibutuhkan agar kita bisa beristirahat dengan tenang, sehingga kita bisa tidur dengan tenang, sehingga kita bisa nongkrong di konser dengan tenang. Sekarang, ini adalah tujuan utama dari sudut pandang pangkalan mengapa cadangan diperlukan. Sehingga semuanya tenang dalam hidup kita. Karena jika ada cadangan yang diverifikasi, maka kita bisa melakukan semua ini. Tapi apa yang terjadi dengan pangkalan itu adalah yang kesepuluh.



Apa kisaran alat untuk membuat cadangan di dunia PostgreSQL? Ini adalah alat pemulihan pg_dump, pg_dumpall, atau pg_restore bawaan. Ini adalah satu-satunya alat yang memungkinkan Anda untuk melakukan pencadangan logis. Artinya, ia bisa pg_dump Anda, baik dalam SQL to dump, dan dalam format biner kecil untuk membuang data. Dan itu keluar dari kotak dengan PostgreSQL.
Alat berikutnya (pg_basebackup) untuk membuat cadangan, yang juga keluar dari kotak dan selanjutnya dimulai dengan alat ini, dan selanjutnya mereka semua akan menjadi alat untuk membuat cadangan basis data biner. Pg_basebackup juga merupakan alat yang keluar dari kotak, yang memungkinkan kita untuk mengunggah repositori postgreSQL dan mengambil salinan biner dari database, menembak database yang persisten dan, jika kita ingin dapat mengarsipkan waktu, kita dapat mengonfigurasi PostgreSQL untuk membuangnya ke beberapa jenis disk. Ini adalah alat dasar. Mereka baik, mereka melakukan, mereka melakukan fungsi mereka di 5, tetapi mereka tidak nyaman dalam hal manajemen dan semacam massa. Ketika Anda memiliki 20 database, Anda harus melakukan ini sendiri skrip.
Dua alat berikutnya adalah spesifik, alat cloud murni - wal-e dan wal-g. Orang yang sama mengembangkannya, tetapi pengembangan wal-e telah berakhir, dan mereka beralih ke wal-g. Alat-alat ini diarahkan terutama untuk AWS dan untuk penyimpanan di S3. Wal-e masih dapat bekerja dengan Google Cloud, dengan Azure dan dengan sistem disk, Anda cukup menentukan beberapa jenis drive jarak jauh. Wal-g hanya bekerja dengan AWS, hanya dengan S3. Nah, atau antarmuka serupa lainnya dengan S3. Kami menggunakannya, hal-hal baik. Saya selanjutnya akan membongkar setiap alat secara rinci.



Dan pada bundel alat berikutnya, ini adalah alat yang bergantung pada pg_basebackup atau menggunakannya secara langsung, atau entah bagaimana mengimplementasikan fungsinya. Mereka semua ditulis oleh pengembang yang berkomitmen pada PostgreSQL utama dan memiliki komersial garpu sendiri, yang mempromosikan dalam lingkaran pengaruh mereka.
Alat pelayan bar paling populer, yang kami gunakan cukup luas di negara ini. Ini pada dasarnya adalah pembungkus Python di sekitar pg_basebackup. Itu juga dapat bekerja pada protokol ssh. Alat pgbackrest yang sangat menarik dan sangat menjanjikan. PostgreSQL terlibat dalam pengembangan dan secara aktif berkomitmen untuk itu. Awalnya ditulis dengan Python. Sekarang versi yang digunakan - ditulis dalam C untuk mempercepat dan kemungkinan penghapusan cadangan secara paralel.
Pg_probackup adalah utilitas dari kolega Rusia kami di PostgreSQL Professional yang memungkinkan Anda untuk membuat cadangan tambahan, yang ukurannya cukup kecil.
Dan utilitas terbaru adalah cadangan dan memulihkan alat (BART) dari EnterpriseDB. Dia tidak begitu populer dengan kita. Ini terutama untuk CentOS dan Red Hat. Untuk Ubuntu, dengan dia, menurut saya, sulit. Dan karena rendahnya popularitas BART dengan kami, itu (BART) hampir tidak ditemukan di mana pun di instalasi.



Saya akan mencoba memecah alat-alat ini menjadi beberapa hal yang penting.


  • Pertama, penting bagi kami bagaimana kami akan menyimpannya, di drive mana dan pada layanan apa. Dan ada daftar karakteristik yang akan kita lalui.


  • Pemisahan data berikut, di sini saya membagi apa yang kami bisa, ketika menghapus cadangan atau memulihkan cadangan, untuk memotong beberapa bagian dari seluruh server basis data (server) dan bekerja dengannya sebagai basis data integral dan tidak terpisahkan.


  • Seberapa banyak mereka mendukung berbagai versi database.


  • Mode operasi apa yang mereka miliki dalam hal paralelisme, dalam hal semacam otomatisasi dan sejenisnya.


  • Dan kemudahan servis adalah seberapa banyak kita dapat memisahkan mereka ke dalam layanan terpisah, yang dengan sendirinya akan melalui database dan menghapus cadangan sesuai dengan beberapa jadwal.


  • Validasi - Saya ingin cadangan diperiksa dalam rangka memastikan bahwa kami dapat memulihkannya dan kami akan memiliki basis yang normal dan tidak terputus.


    Dan sekarang, mari kita melihat enam poin besar ini secara lebih rinci. Dan saya akan menandai di sana instrumen apa yang akan memberi kita.




Dengan penyimpanan, mereka dapat menyimpan semua yang ada di sistem file, yaitu, kita dapat memasang kembali disk kita ke OS dan menyalin cadangan di sana. Semua alat memungkinkan Anda melakukan ini. Drive jaringan yang terpasang pada dasarnya sama, karena diperoleh di sistem file lokal kami.
Dalam AWS (S3), tiga alat dapat bekerja untuk kita - wal-g, wal-e, pgbackrest. Karena di antara utilitas tersebut: bartender dan sebagainya, itu adalah satu-satunya yang dapat bekerja dengan AWS (S3).
Dengan Azure, hanya wal-e. Google Cloud hanya wal-e.



  • Hanya pg_dump, pg_dumpall memberi kami salinan data yang logis. Perbedaan di antara mereka adalah bahwa pg_dumpall memproses seluruh instance database (server), di pg_dump Anda dapat menentukan database tertentu pada instance dan bekerja dengannya.
  • Salinan biner adalah sisanya.
  • Faktor penting selama penyimpanan adalah bahwa jika kita dibatasi dalam beberapa cara oleh sumber daya disk, maka situasi sering muncul ketika kita membagi database menjadi ruang tabel yang berbeda. Ini juga berlaku untuk server besi, karena Anda tidak ingin menderita RAID. Ini berlaku untuk cloud, karena karena ada batasan tertentu, terutama ketika Anda membawa mobil dengan disk NVME dan berapa banyak yang terhubung, begitu banyak yang terhubung. Mesin virtual AWS meluas, tetapi dengan drive EBS. Dan ketika mengembalikan data, penting bagi kami bahwa kami dapat mendistribusikan kembali ruang tabel ini, menetapkannya di sepanjang jalur baru dan ke disk baru. Dan sekarang properti bagus ini hadir di wal-e. Di wal-g mereka masih belum tahu bagaimana cara menggunakannya. Pg_probackup dapat bekerja dengannya. Energik, basebackup, pgbackrest. Hal ini cukup penting, terutama ketika Anda memiliki basis data 8-10 TB. Di antara klien produksi kami, hampir semua database ini diciutkan menjadi ruang tabel.


Sekarang tentang ukuran apa yang bisa kita miliki cadangan. Ini semua akan terjadi dalam konteks cadangan biner. Jelaslah bahwa cadangan biner adalah seberapa besar bobot database dengan kami, begitu banyak yang kami salin. Beratnya 8 TB, kami menyalin 8 TB. 1 MB beratnya 1 MB, disalin. Bagaimana cara menghemat ruang saat kita menginginkan rantai cadangan yang panjang? Untuk melakukan ini, datang dengan beberapa alat. Yaitu, database menyimpan data dalam file-nya. Jika kami memiliki basis data arsip yang panjang, maka biasanya kami mengubah sebagian kecil dari file-file ini. Dan untuk ini, mereka datang dengan cadangan diferensial.


Cadangan diferensial apa itu? Kami melihat file apa yang telah berubah dan hanya menyalin ke penyimpanan, tempat menyimpan cadangan. Dan kami akan menautkan semua file lain dengan hardlink ke database ini. Ternyata dengan demikian kami menghemat ruang. Dan pada saat yang sama, kita dapat dengan aman menghapus backup database lama tanpa mengacaukan yang lebih baru.


Hal ini bagus, tetapi kami memutuskan untuk terus maju dan membuat cadangan tambahan. Cadangan tambahan terdiri dari dua jenis.


Yang pertama adalah di tingkat file. Ini berbeda dari cadangan diferensial hanya dalam cadangan diferensial berfokus pada cadangan penuh dari database Anda, dan dalam kaitannya dengan cadangan lengkap itu menyalin file dan salinan berbeda. Cadangan tambahan dapat fokus pada cadangan diferensial, hanya menyalin file yang diubah yang telah berubah dibandingkan dengan cadangan diferensial. Untuk tambahan, Anda akan membutuhkan seluruh rantai cadangan. Yaitu, cadangan utama -> cadangan inkremental pertama (akan selalu berbeda) -> lalu semua cadangan inkremental. Cadangan diferensial selalu berfokus pada basis data cadangan lengkap. Inkremental dapat fokus pada jenis cadangan lainnya.
Pg_probackup dan BART menggunakan cara membuat cadangan inkremental demi blok. Karena kita tidak bisa mengubah seluruh file, tetapi blok data. Dan utilitas ini berjalan melalui file wal dan memilih blok yang benar-benar telah berubah dari Anda. Blok cadangan ini disalin ke cadangan. Untuk memulihkan dengan cadangan tambahan seperti itu, Anda juga akan memerlukan salinan lengkap dari database dan ditambah lagi Anda masih perlu menyimpan potongan-potongan tambahan yang diketik dari wal. Ini membebankan beberapa batasan utilitas, karena mereka harus dijalankan melalui file wal. PostgreSQL Professional juga memiliki lapisan di atas struktur file database. Karena itu, mereka cukup cepat mencari blok ini. Cadangan tambahan seperti itu sangat kecil. Jika Anda memiliki% perubahan basis data kecil dan karena fakta bahwa cukup banyak informasi teknis ditulis ke file wal, utilitas ini membuat cadangan puluhan kilobyte data selama 1 wal.



Berbagi data lebih lanjut. Ini menyiratkan bahwa jika kita perlu membuat cadangan bukan segalanya. Atau mengembalikan tidak semuanya. Ini hanya mungkin dengan cadangan logis, dan ini memungkinkan kami untuk melakukan hanya pg_dump. Utilitas menyediakan fungsionalitas yang cukup luas. Pg_dump dapat memungkinkan Anda untuk membuang struktur database jika Anda perlu. Anda dapat secara khusus membuang satu tabel atau Anda dapat mengecualikan satu tabel dari dump atau membuang daftar tabel, mengecualikan daftar. Fungsionalitasnya cukup luas dalam hal ini. Yang minus untuk ini adalah ketika memulihkan dari dump seperti itu, jika Anda memiliki database besar, Anda harus menghabiskan banyak waktu untuk memulihkannya, karena semua ini perlu dimainkan pada instance murni PostgreSQL.
Utilitas ini sangat nyaman untuk menggunakan case ketika kita melebih-lebihkan kekuatan kita dan tidak membuat banyak database kecil. Kita bisa menggabungkannya menjadi satu contoh. Kita bisa melihatnya dengan cara ini jika kita sekarang mengevaluasi kekuatan kita, basis data kita bengkak atau kita mengubah arsitektur di sana dari satu monolit ke layanan satu dan melihat data. Pg_dump dalam hal ini adalah satu-satunya hal yang memungkinkan Anda untuk melakukan ini tanpa rasa sakit.


Anda juga dapat mengembalikan satu basis data dan pgbackrest terdaftar di sini. Dia memiliki chip seperti itu, sehingga kita dapat mengindikasikan bahwa kita hanya membutuhkan satu database dari cadangan biner. Apa yang dia lakukan Ini mengembalikan database default dari cadangan, ini adalah template dan postgres dan database yang kami tentukan. Semua database lain, itu me-reset file dan membuatnya panjang nol. Artinya, PostgreSQL memiliki struktur transparan untuk menyimpan basis data dalam file, di sana Anda dapat, pada tingkat ini, seolah-olah, untuk mengurangi database yang dipulihkan. Misalkan kita perlu menemukan data mendesak apa dari biner, kami tidak ingin menaikkan basis 10 TB, kami memiliki dua basis di sana, dan kami menaikkannya, yang memungkinkan total 5 TB. Dalam hal ini, tentu saja, konsistensi dilanggar, tetapi untuk beberapa solusi cepat, ketika Anda perlu segera mengangkat data nosebore dari database besar, yang ada beberapa, ini adalah fitur yang sangat bagus. Tetapi sebagai database cadangan lengkap tidak harus dipertimbangkan selama pemulihan. Artinya, ini untuk pekerjaan darurat.



Bagaimana cara kerjanya dengan banyak versi database? Di sini juga, semuanya cukup menarik. Pg_dump sangat bagus karena kita tidak terikat dengan versi database yang akan dipulihkan. Ada mode teks biasa, dan itu hanya SQL murni, yang menggambarkan seluruh struktur basis data, semua data. Pada prinsipnya, Anda dapat memulihkan dari mana pun Anda inginkan, di MySQL, di MSSQL, di Oracle dengan beberapa suntingan ke dump ini. Di antara versi utama PostgreSQL, kesedihan ini juga cukup mudah digunakan.
Multi-versi, apa yang saya maksud dengan ini? Ini adalah sejauh mana utilitas dapat memproses versi database yang berbeda dan bekerja secara bersamaan dengan PostgreSQL 9.6, 10, 11. Semuanya kecuali yang built-in dari pg_dump dan pg_basebackup, karena mereka terikat dengan versi spesifik yang mereka bawa. Sisanya berfokus pada utilitas ini. Mereka dapat ditunjukkan di mana pg_basebackup, pg_dump dari berbagai versi berada. Mereka masing-masing dengan versi PostgreSQL memilih utilitas terbaru untuk menghapus cadangan.
Semua utilitas kecuali pg_dump cocok untuk membuat replika dan server siaga, karena ini adalah cadangan logis. Menggunakan salah satu dari utilitas ini, Anda dapat memulihkan server dan menyambungkan ke wizard agar berfungsi sebagai replika server ini.



Bagaimana cadangan dapat dihapus secara umum, mode apa yang ada untuk menghapus cadangan. Anda cukup menyalin file menggunakan alat OS standar: melalui protokol ssh (rsync, scp) dan mungkin beberapa utilitas lain. Mengapa ada peluang seperti itu, karena memungkinkan Anda untuk memparalelkan penyalinan. Pgbackrest hanya berfungsi seperti ini, bartender dapat bekerja seperti itu, dan dapat bekerja menggunakan protokol PostgreSQL.
Protokol PostgreSQL - ketika utilitas cadangan terhubung ke PostgreSQL dan menarik semua file dan arsip log yang muncul selama proses pencadangan menggunakan protokol replikasi. Semua orang dan bartender dapat melakukannya.
Pada dasarnya, semuanya dapat melakukan backup dari replika, itu tergantung pada versi PostgreSQL. Dengan PostgreSQL 10 dan 11, kita dapat menghapus cadangan dari replika. Tetapi saya tidak merekomendasikan ini, secara umum, tidak ada perusahaan kami yang akan merekomendasikannya. Karena ada situasi ketika mereka melewatkan pemantauan, mereka mengambil cadangan dari replika selama sebulan, yang jatuh dari server master dan tidak relevan. Artinya, cadangan dalam hal apa pun harus selalu dihapus dari server master. Hanya dalam hal ini Anda akan yakin bahwa Anda memiliki basis data cadangan yang benar-benar terkini.
Cadangan multithreading - semua orang dapat melakukan ini, karena semuanya karena alasan yang berbeda, seseorang melalui protokol ssh, seseorang diimplementasikan pada tingkat salinan basis data. Kecuali pg_basebackup dan BART, karena operasi BART hanya pada pg_basebackup ketika cadangan dihapus dan sayangnya, single-threaded dan tidak akan multi-threaded.



Contoh multithreading. Saya sedang memulihkan database 8 TB. Ketika Anda fokus pada memilih sistem untuk menghapus cadangan, maka ketahuilah bahwa wal-e ditulis dengan Python, wal-g ditulis dalam Golang. Saya harus mengembalikan basis 8 TB. Wal-e berlari ke keterbatasan Python dan menarik saya dengan AWS dengan kecepatan 600 Mbps. Ketika saya beralih ke wal-g, dia memiliki situasi bahwa dia tidak dapat bekerja dengan wal-e backup, tetapi dia dapat menarik file wal. Oleh karena itu, gambar tengah ini di sini adalah pemulihan database. Kemudian digulung wal, yang ada di S3 dan dikembalikan ke titik waktu tertentu. Wal-e berlari ke dalam batasan Python dan konkurensi dalam Python, itu sangat kondisional. Wal-g berlari ke antarmuka S3, yaitu, seberapa cepat S3 dapat memberikan setiap saat, sehingga sangat cepat. Rata-rata, itu 2 Gb / s, yang cukup baik. Yaitu, dengan wal-e, satu jam perubahan ke basis data diterima dalam 45 menit cadangan bergulir. Dengan wal-g, ternyata mereka menggulung satu jam di suatu tempat di database selama sekitar 5 menit.



Mode operasi, apa yang menarik di sini di sistem cadangan.


  • Pemulihan dalam waktu ke titik tertentu. Jika kami telah mengarsipkan log dan menyalinnya, kami dapat memulihkannya. Ini memungkinkan Anda melakukan sistem cadangan, seperti faktor standar. Yang utama adalah kami menyimpan file wal di suatu tempat. Dumps, tentu saja, tidak tahu caranya, karena mereka sedikit tentang sesuatu yang lain.
  • Menyesuaikan beban pada jaringan adalah hal yang cukup penting, karena seperti yang saya katakan, diinginkan untuk menghapus dump dari server master, maka Anda menjamin diri Anda bahwa Anda benar-benar mendapatkan cadangan yang sebenarnya. Yah, kadang-kadang terjadi bahwa server sangat dimuat sehingga cukup sulit untuk masuk ke sana. Kami memiliki beberapa pelanggan menempel antarmuka jaringan yang terpisah. Terkadang ada waktu buka minimal yang dilakukan. Ini juga bagus ketika kita dapat menentukan beban di jaringan saat membuat cadangan. Ini memungkinkan Anda melakukan pg_basebackup, bartender dan BART, wal-e, wal-g.
  • Kompresi dengan cepat. Ini adalah pertanyaan tentang seberapa banyak kita akan mengirimkan melalui jaringan. Jika kita dapat mengompres file sebelum mengirimnya ke repositori, maka ini bagus. Dan hampir semua orang bisa melakukannya, di sini. Yang utama adalah menunjukkan level kompresi di sana.


Kemudahan Servis, apa yang menarik di sini untuk sistem cadangan?


  • CLI โ€” , , , , . , CLI, , , . , , .
  • barman, pgbackrest BART, . , 20-30 , , , , backup- . , , .
  • โ€“ , , backup-, , backup-. , - . . .
  • โ€“ backup-, , - . , , . , , , , wal , , . wal-e, wal-g, , backup - . 7 backup .


backup. , backup, backup , , . , . , . . stage . , , backup . CLI , backup .


, , . , backup . , . , . , . . checksum PostgreSQL. , checksum PostgreSQL. checksum, .


pgbackrest pg_probackup backup , checksum. checksum.


, backup, checksum , , checksum . .



:



. , . , .



: , backup , , , . , , backup. , , - , , , , , , . - ?


: , , . . . - , , backup , , , . , . , , , , , , / . , , . , . , . , .


: , , ? .


: . 4 . . . backup. . , .


: ?


: . . wal-e, wal-g, pgbackrest. borman, pg_dump, basebackup. , , . .


: , - PostgreSQL, , , postgis - -?


: , backup , . checksum , PostgreSQL checksum, , . postgis, - . Pg_dump , , , SQL . SQL . . , , . dump, .


: , . , - ?


: . dump , . , โ€“ , , - , , . , . , - , .


: , , , bloat ?


: .


: โ€” , - . , Symantec, Veritas Backup Exec . PostgreSQL?


: , , . PostgreSQL , pg_start_backup. , . .


: , - Symantec, Veritas Backup Exec .


: .


: , , . checksum - , , - ?


: โ€” . stage , . stage . . . , -, . . .


: , WAL , S3. wal-e, wal-g - awscli . ?


( ): wal-g. wal-g. 40 wal-g . . , . , prefetch, wal , . , โ€” , wal. wal , page cache , , wal, , . , .


: . , PostgreSQL โ€” -> /dev/null, , . , . smoke . amcheck , . , , , .


: 10 . . . . wal โ€” . ?


: . . . , .


: , pg_dump, . ?


: - . , .


: , , - ?


: pg_dump , .


: pg_dump, , , , , .


: , -, .


: , .


: , - .


: . . . . , , . . Pg_dump , - , exit_code . , , . , .


PS โ„–1 pg_dump, pg_basebackup.


barmanwal-ewal-gpg_probackuppgbackrestBART
ssh (rsync, scp)++
++++++
S3+++
Azure++
Google Cloud++
+++++
++
++
barmanwal-ewal-gpg_probackuppgbackrestBART
++
+
-++++++
Dump multithreaded+++++
Pemulihan Point-in-Time++++++
Penyesuaian beban jaringan+++
Kompresi on-the-fly+++++
CLI++++++
Server khusus+++
bartenderwal-ewal-gpg_probackuppgbackrestBart
Penyimpanan cadangan terstruktur++++++
Kebijakan penyimpanan+croncron+++
CLI untuk pemantauan++++++
Validitas penyelesaian pencadangan++++++
Periksa postgresql++

PS No. 2 Kesalahan, koreksi di bawah artikel, penambahan ke tabel pivot dapat dilakukan melalui permintaan Tarik


PS # 3 Wal-g menyambut sukarelawan untuk membantu dengan dokumentasi.


PS No. 4 Untuk menginstal wal-g menggunakan rpm Anda dapat menggunakan repositori saya: Github , Fedora COPR .


PS No. 5 Bagaimana cara membuat cadangan penuh dan cadangan tambahan dalam membuat dan menyimpan di S3, dan menyimpan hanya cadangan penuh untuk direkam? Jika Anda memiliki ide, beri tahu saya di komentar atau di PM.



Survei: Alat cadangan apa yang Anda gunakan?


PS No. 6 saluran Telegram PostgreSQL: https://t.me/pgsql

Source: https://habr.com/ru/post/id485622/


All Articles