Beberapa kuliah mendatang akan didasarkan pada Y. Subbotnik pertama pada database yang diadakan
di musim semi . Pertama, pengembang Andrei Borodin berbicara di Y. Subbotnik. Dia berbicara tentang WAL-G, alat sederhana dan efektif untuk membuat cadangan PostgreSQL ke cloud, serta algoritma dan teknologi yang memungkinkan WAL-G untuk membuat cadangan lebih cepat. Fitur utama WAL-G adalah cadangan delta. Dalam kuliah ini Anda akan belajar tentang implementasi mereka dan bagaimana dukungan untuk teknologi ini berkembang di PostgreSQL.
- hai! Saya adalah pengembang Yandex dari Yekaterinburg. Untuk teknologi backup cepat. Kami telah melakukan pencadangan selama beberapa waktu, ada laporan oleh
Vladimir Borodin dan
Evgeny Dyukov tentang bagaimana kami meneliti dan apa yang kami kembangkan untuk menyimpan data dengan aman, andal, mudah, dan efisien. Seri ini didedikasikan untuk perkembangan terbaru di bidang ini.
Mari kita bicara tentang cadangan pada PostgreSQL pada prinsipnya. Utilitas standar untuk mentransfer data -
pg_dump - didefinisikan sebagai utilitas konsol yang membuat file dengan representasi logis dari data Anda.
Itu adalah salinan yang logis cukup nyaman. Anda selalu dapat mentransfer data antara versi yang berbeda, Anda dapat memotong basis data Anda menjadi beberapa bagian, dan ini adalah alat standar yang, misalnya, datang dalam sebuah kotak dengan utilitas administrasi PgAdmin.
Pertama-tama, tentang pg_dump Anda perlu tahu bahwa ini adalah alat pengembang.
Ini bukan alat pemeliharaan basis data. pg_dump tidak dirancang untuk bekerja dengan basis data yang sangat dimuat.
Misalkan semuanya serius dan Anda ingin menggunakan teknologi "Point-in-time recovery", yang menggunakan PostgreSQL API untuk bekerja dengan cadangan online. Anda memanggil fungsi pg_start_backup dan membuat salinan file dari basis data. Faktanya, pg_start_backup memaksa database untuk melakukan CHECKPOINT; dan aktifkan penulisan satu halaman penuh dalam log tulis depan. Salinan database yang Anda buat saat menelepon API bukan salinan data yang konsisten. Anda juga memerlukan log tulis-depan agar dapat mengembalikan database Anda selama panggilan pg_stop_backup, yaitu, di akhir cadangan.
Setelah waktu akhir penghapusan cadangan dan di hadapan catatan terkemuka, Anda dapat memulihkan ke titik yang diinginkan dalam masa hidup database Anda.
Utilitas pg_basebackup disediakan di dalam kotak, yang mengimplementasikan semua teknologi ini dalam bentuk kanonik dan memungkinkan Anda membuat cadangan dengan fungsionalitas minimum yang diperlukan.
Jika Anda masih lebih serius dari sebelumnya, maka Anda menggunakan beberapa jenis perangkat lunak manajemen cadangan, dan biasanya itu adalah Barman.
Ia memiliki beberapa keunggulan. Kelebihan utama adalah utilitas yang sangat umum, ia memiliki komunitas besar, sejumlah besar pertanyaan tentang Stack Overflow.
Anda hanya perlu mengambil satu server cadangan, dan mencadangkan semua PostgreSQL Anda di sana. Ini sangat nyaman - selama satu server cadangan sudah cukup untuk Anda.
Segera setelah Anda memiliki banyak server cadangan, Anda perlu memantau apakah ada yang penuh. Dalam hal kegagalan beberapa server cadangan, Anda perlu memahami yang mana dari basis data Anda yang sekarang dalam bahaya. Anda perlu memahami secara prinsip di mana untuk menyalin kluster basis data baru saat membuatnya.
Ada utilitas penghapusan cadangan yang jauh lebih sederhana yang disebut WAL-E.
WAL-E menjalankan empat perintah utama. Perintah WAL-PUSH mengirim satu file WAL ke cloud, dan WAL-FETCH mengambil satu file WAL jika restore_command perlu dikembalikan.
Ada juga BACKUP-PUSH (mengimplementasikan penghapusan API cadangan) dan BACKUP-FETCH (mengambil semua data dari cloud). Data disimpan di cloud, jadi Anda tidak perlu memonitor apa pun, ini sudah menjadi masalah layanan cloud, bagaimana memastikan ketersediaan data Anda saat Anda membutuhkannya. Ini mungkin keuntungan utama dari WAL-E.
Ada cukup banyak fungsi. Ada daftar cadangan, ada kebijakan retensi, yaitu, kami ingin menyimpan cadangan selama tujuh hari terakhir, misalnya, atau lima cadangan terakhir, kira-kira seperti itu. Dan WAL-E dapat mem-backup ke berbagai layanan cloud: S3, Azure, Google, dapat memanggil sistem file lokal cloud.
Ini memiliki beberapa properti. Pertama, ia ditulis dalam Python dan secara aktif menggunakan pipa Unix, sebagian karena ini, ia memiliki dependensi dan tidak terlalu produktif. Ini normal karena WAL-E berfokus pada kemudahan penggunaan, kemudahan pengaturan sehingga Anda tidak dapat membuat kesalahan ketika Anda membuat rencana cadangan. Dan itu ide yang sangat bagus.
Ada banyak fitur yang ditulis dalam WAL-E, dan di mana penulis mengembangkannya lebih lanjut tidak terlalu jelas bagi penulis. Gagasan muncul bahwa saya membutuhkan alat baru.
Fitur utamanya adalah bahwa ia ditulis ulang di Go, hampir tidak memiliki ketergantungan eksternal, jika Anda tidak menggunakan enkripsi eksternal, dan itu jauh lebih produktif.
WAL-G pada awalnya dibuat oleh dua penulis dari Citus Data, dan keuntungan utama ditunjukkan dalam histogram ini - kecepatan pengiriman "poros". Kita melihat bahwa WAL-E cepat, bisa apa saja, bisa menjadi kolom besar mendekati nol.
WAL-G memiliki bandwidth yang cukup stabil. Pada tes di Citus Data, ia menunjukkan bahwa ia secara stabil mengirim sekitar 800 Mb / s "poros".
Selain itu, di WAL-G, misalnya, saya menulis fitur yang mengimplementasikan cadangan dari replika. Anda tidak perlu memuat master DB Anda dengan membaca, Anda dapat menghapus cadangan dari replika.
Tapi ada satu masalah kecil. Saat Anda mulai membuat cadangan, Anda harus memberi nama cadangan itu entah bagaimana. Nama ini termasuk timeline, yang akan diubah jika replika dipromosikan. Jika failover terjadi dalam rantai replika sebelum replika yang Anda buat cadangannya, Anda akan melihat beberapa replika, timeline akan diubah. WAL-G memahami bahwa situasi ini tidak konsisten, karena memiliki nama di timeline lama, nama itu menjanjikan Anda bahwa Anda dapat melanjutkan pengembangan sejarah database ke arah yang ada. Tapi ini tidak benar. Anda telah pergi ke salah satu arah, Anda tidak dapat melompat ke timeline lain dengan mobil belakang. Oleh karena itu, WAL-G memahami situasi ini dan tidak mengunggah file JSON fiskal ke cloud. Anda membuat salinan fisik. Tetapi intervensi administrator diperlukan agar salinan ini dapat digunakan.
Kami telah mengimplementasikan salinan delta di WAL-G, saya juga mengerjakan pengembangan ini. Ini memungkinkan Anda untuk mengambil lebih sedikit data dalam cadangan basis berikutnya, Anda tidak membuat salinan halaman data yang tidak berubah dari cadangan sebelumnya.
Saat mengatur WAL-G, Anda menentukan jumlah langkah yang paling jauh dari cadangan dasar, cadangan delta, dan menentukan kebijakan salin delta. Entah Anda membuat salinan dari delta terakhir yang ada, atau Anda membuat delta dari cadangan lengkap asli. Ini diperlukan dalam kasus ketika komponen database yang sama selalu berubah di database Anda, data yang sama terus berubah.
Mengapa pada prinsipnya kita membutuhkan salinan delta dari database? Secara teori, Anda memiliki WAL, sehingga Anda dapat memutar di mana saja.
Pada server yang sibuk, memainkan WAL lima detik fisik di masa lalu mungkin membutuhkan empat detik fisik saat ini. Jika Anda diminta untuk menggulung WAL dalam empat hari, ini berarti ada kemungkinan bahwa orang yang meminta untuk melakukan ini harus menunggu tiga hari lagi. Tidak selalu situasi yang dapat diterima.
Anda memerlukan cadangan dasar untuk setiap hari, namun demikian, Anda tidak dapat menyimpan 7 atau 14 salinan penuh dari basis data Anda di sana, meskipun WAL-G akan mengarsipkannya, itu masih akan cukup besar. Dan dalam hal ini, salinan delta membantu.
Ketika mengembangkan salinan delta, beberapa kemungkinan format file data dibahas. Pertama-tama, format itu diusulkan, ketika kami tidak mengganggu halaman, kami hanya membatalkannya. Tetapi kami sampai pada kesimpulan bahwa ini bukan cara yang sangat efektif, nol kemudian dikompres secara efektif, tetapi kemudian kami menolak metode penyimpanan ini, karena sulit untuk men-debug itu jika terjadi situasi darurat.
Teknologi selanjutnya yang dipertimbangkan adalah pertama-tama menyimpan nomor blok dan kemudian blok yang diubah. Tetapi di sini kita dihadapkan dengan kekhasan penyimpanan dalam file TAR, bahwa kita harus terlebih dahulu menunjukkan ukuran file TAR di mana kita menyimpan salinan delta kita, dan kemudian mulai merekamnya. Saya ingin membuat implementasi teknologi dengan konsumsi minimum RAM, jadi kami harus menggunakan format ketiga di mana kami pertama kali benar-benar membaca setiap file data, mencari halaman data yang diubah, pertama-tama menyimpan jumlah blok yang diubah dalam file TAR, dan hanya kemudian blok yang diubah itu sendiri.
Fitur ini belum diterapkan. Saya melihatnya atau mencari seseorang yang ingin mengajukan permintaan tarik di WAL-G. Ketika memulihkan dari salinan delta, database bertahan setiap reinkarnasi dari database di setiap langkah cadangan delta. Terkadang di tengah kehidupan beberapa file dihapus. Pada saat yang sama, kita tidak perlu khawatir tentang kondisi mereka jika mereka tetap dihapus, dan kemudian diciptakan kembali dari salinan delta. Ini sepertinya bukan fitur yang sangat rumit, jadi jika Anda tertarik untuk menulis sesuatu di Go, lihat fitur ini.
Jadwalkan tentang penggunaan jaringan, CPU dan disk. Di WAL-E, seperti yang bisa kita lihat, cadangan di sini belum berakhir, dimulai pukul satu pagi di Moskow, dan itu tidak berakhir pada laporan terakhir yang kita lihat. Jadwal WAL-G telah berakhir, ia bekerja lebih cepat dan bahkan lebih banyak dalam hal konsumsi sumber daya.
Yang paling menarik adalah grafik konsumsi sumber daya selama salinan delta. Kami melihat bahwa semua sumber daya menjadi hampir nol. Beban pada CPU hampir merupakan beban standar pada database, pada malam hari, beberapa permintaan dieksekusi. Kami melihat cabang besar membaca. Saya juga menghadapinya, saya juga ingin menarik permintaan atau saya akan melakukannya sendiri di musim panas. Intinya adalah bahwa kita masih harus membaca data kami untuk mengetahui apa yang telah berubah di dalamnya. Bacaan ini bisa dihindari.
Ada penghapusan dalam WAL-G ketika kami menunjukkan jumlah cadangan atau tanggal dari mana kami perlu menyimpan semua WAL dan semua cadangan dasar. Dan WAL-G sudah berurusan dengan pertanyaan tentang apa WAL dan cadangan dasar yang dibutuhkan. Sejauh ini kami tidak memiliki fitur yang akan menghapus semuanya. Dalam WAL-E, ini juga merupakan kesempatan untuk permintaan tarik. Perintah DELETE EVERYTHING yang menarik belum diimplementasikan.
Ada daftar cadangan.
Kami mengatur variabel lingkungan yang diperlukan agar WAL-G berfungsi dan memanggil utilitas konsol WAL-G. Cadangan yang perlu kita lihat ditampilkan.
WAL-G mengimplementasikan cukup banyak teknologi untuk memparalelkan cadangan dan umumnya berbagai operasi. Sebagai contoh, teknologi ini digunakan untuk mengirim "poros" ke arsip. Segera setelah PostgreSQL memanggil archive_command untuk mengirim satu file, WAL-G melihat apakah ada lebih banyak file yang siap di dekatnya.
Secara umum, ini bukan fitur yang sangat terdokumentasi, sangat stabil di versi terbaru PostgreSQL, banyak teknologi menggunakannya. Kami melihat apakah ada file WAL yang sudah jadi dalam status arsip, dan kami juga mengirimkannya bersama dengan yang meminta untuk mengirim database ke arsip. Dan ketika PostgreSQL meminta mereka untuk mengirim, kami sudah mengirimnya, kami siap. Ini secara signifikan mempercepat pengiriman WAL pada pangkalan yang dimuat dan memungkinkan Anda membuatnya bukan single-threaded. Biasanya, PostgreSQL menyiapkan satu file, lalu menunggu file itu pergi, menyiapkan yang berikutnya. Kami berhasil menghindari pekerjaan yang konsisten ini.
Selama WAL-FETCH, ketika kluster dipulihkan, kami juga mencoba mengunduh file N berikut yang akan dibutuhkan, dan mencoba menyeimbangkan jeda antara awal prefetting file WAL baru sehingga kami dapat memanfaatkan semua sumber daya yang kami miliki sebanyak mungkin: apakah berjalan ke dalam jaringan atau mengalami disk dalam kasus yang jarang terjadi.
Ini semua diatur oleh variabel lingkungan.
Ada juga konkurensi membuat salinan. Meskipun fitur ini tidak ada dalam berbagai rilis - A. B. dirilis pada rilis 0.1.10 pada Juni 2018 - karena paralelisme membaca dari disk memungkinkan Anda dijamin berjalan ke jaringan atau disk. Ini tidak terlalu baik dengan database yang dimuat. WAL-E memiliki fitur yang memungkinkan pelambatan. Sejauh ini, kami belum memilikinya. Hal ini diperlukan untuk membatasi kecepatan penghapusan cadangan sehingga pangkalan dapat hidup sendiri dan melayani beban.
Fitur utama kami bukan tentang teknologi.
Dua tahun lalu, Zhenya Dyukov mengimplementasikan teknologi
delta-backup untuk Barman, belum diadakan, komunitas masih mendiskusikannya.
Hampir setahun yang lalu, Zhenya memperbaiki bug WAL-E, dan kami mengirimnya selama enam bulan (
tautan ke GitHub - kira-kira Ed.). Cukup sering dalam solusi open source ada masalah dengan fakta bahwa mereka tidak terawat dengan baik.
Dengan WAL-G, semuanya cukup sederhana: kami menggunakannya dan saya memeliharanya. Jika kami atau Anda membutuhkan sesuatu, Anda cukup melaporkan bahwa Anda memiliki masalah. Kami akan mencoba menyelesaikannya.
Permintaan standar dari komunitas sederhana - "mari kita lakukan yang paling."
Lebih banyak kriptografi, lebih banyak platform. Mungkin bukan hanya PostgreSQL, tapi MySQL masih cadangan atau yang lainnya? Saya melihat beberapa hal lainnya.
Pertama-tama, sekarang ketika mengirim "poros" kita bisa memahami blok basis data mana yang telah berubah, pindai file WAL ini dan simpan informasi tentang apa yang telah berubah.
Dan ketika cron tiba dengan cadangan delta lain, kami tidak dapat memindai seluruh basis data, menyimpan file pembacaan disk tersebut dan hanya tahu halaman mana yang perlu kami seret ke cloud.
Kami mencoba menggunakan teknologi trek-halaman. Ini mengimplementasikan pelacakan perubahan halaman di tingkat kernel database. Cadangan dihapus dengan sangat cepat. Masalah utama dengan PTRACK adalah sangat invasif. Ini berisi banyak perubahan pada inti PostgreSQL di tempat-tempat yang sangat sensitif, sehingga sepertinya tidak akan segera diadopsi.
Selain itu, delta-delta-nya sedikit berbeda dari delta-delta yang sekarang kita miliki. Saat menghapus delta berbasis LSN, kami menghapus semua perubahan dalam file delta yang telah terjadi dari awal sebelumnya hingga saat ini.
Dalam kasus PTRACK, kami mendapatkan perubahan pada file delta, mulai dari delta yang sebelumnya diterima. Kami tidak memiliki waktu delta yang tepat sebelum dimulainya cadangan, sebelum dimulainya perubahan. Ini bukan masalah utama PTRACK, secara umum, ini bekerja dengan baik, tetapi sejauh ini sulit untuk diterima.
PTRACK tidak mengizinkan penghapusan delta dalam mode LATEST_FULL, karena ia menyimpan peta blok yang diubah dari penghapusan peta ini sebelumnya. Oracle memiliki teknologi yang menarik, ada 8 kartu sebelumnya yang mereka simpan berjaga-jaga. Mungkin kita bisa melakukan hal serupa, tetapi sejauh ini kita tidak bekerja ke arah ini.
September lalu, saya mencoba menawarkan komunitas teknologi berdasarkan fakta bahwa kami hanya menambahkan kait yang kami butuhkan ke kernel, dan kami menerapkan pelacakan untuk perubahan halaman dalam ekstensi sehingga patch pelacakan halaman tidak terlalu invasif. Setelah membahas teknologi ini, kami sampai pada kesimpulan bahwa kami membutuhkan beberapa prototipe, dan kami akan menambahkan kait ketika ada prototipe. Mungkin kita akan melihat cara kerjanya. Saat ini saya sedang mengerjakan prototipe ekstensi ini yang bisa menggunakan kait kernel untuk melacak perubahan basis data.
Ada ekspresi di komunitas bahwa setiap postgresista harus memiliki alat cadangan sendiri. Ini buruk. Setiap orang melakukan pekerjaannya sendiri, yang melakukan tugas yang sangat penting. Pasti ada satu hal di mana semuanya akan berada di dalam kotak, semuanya akan sempurna di dunia yang ideal.
Apa yang ingin saya lihat di kotak di basebackup? Kami ingin melihat, mungkin, pengarsipan ke awan. Dan salinan delta.
Saya juga ingin kompresi, konkurensi, enkripsi, pelambatan, daftar cadangan, verifikasi, validasi cadangan ... Banyak hal. Kami memahami bahwa jika semua ini sekarang ditawarkan kepada masyarakat, itu akan menghasilkan beberapa lusin tambalan, yang agak sulit untuk dibahas dan diimplementasikan melalui commitfest. Oleh karena itu, sekarang kami masih menggunakan alat terpisah, tetapi ada keinginan untuk mencurahkan waktu dan teknologi kepada masyarakat untuk membuat PostgreSQL lebih baik.