Saya sarankan Anda membaca transkrip laporan awal tahun 2019 oleh Andrey Borodin "Cadangan dengan WAL-G. Apa yang ada di tahun 2019?"
Halo semua! Nama saya Andrey Borodin. Saya seorang pengembang di Yandex. Saya tertarik dengan PostgreSQL sejak 2016, setelah saya berbicara dengan pengembangnya dan mereka mengatakan bahwa semuanya sederhana - Anda mengambil kode sumber dan membuatnya, dan semuanya akan berhasil. Dan sejak itu saya tidak bisa berhenti β saya menulis berbagai macam hal.
Salah satu hal yang saya kerjakan adalah sistem cadangan. . Secara umum, di Yandex kami telah lama mengerjakan sistem cadangan di PostgreSQL. Dan Anda dapat menemukan di Internet serangkaian enam laporan tentang cara kami membuat sistem cadangan. Dan setiap tahun mereka berkembang sedikit, berkembang sedikit, dan menjadi lebih dapat diandalkan.
Namun laporan hari ini tidak hanya tentang apa yang telah kami lakukan, tetapi juga tentang betapa sederhananya dan apa adanya. Berapa banyak dari Anda yang sudah menonton laporan saya tentang WAL-G? Ada baiknya banyak orang yang tidak menonton, karena saya akan mulai dengan hal yang paling sederhana.
Jika tiba-tiba Anda memiliki cluster PostgreSQL, dan menurut saya setiap orang memiliki beberapa cluster tersebut, dan tiba-tiba belum ada sistem cadangan, maka Anda perlu mendapatkan penyimpanan S3 atau penyimpanan yang kompatibel dengan Google Cloud.
Misalnya, Anda dapat datang ke stan kami dan mengambil kode promosi untuk Yandex Object Storage, yang kompatibel dengan S3.
Kemudian buat Ember. Itu hanya wadah informasi.
Buat pengguna layanan.
Buat kunci akses untuk pengguna layanan: aws-s3-key.
Unduh rilis stabil terbaru WAL-G.
Apa perbedaan pra-rilis kami dengan rilis? Saya sering diminta untuk melepaskan lebih awal. Dan jika tidak ada bug pada versi tersebut untuk jangka waktu yang cukup lama, misalnya sebulan, maka saya rilis. Ini rilis bulan November ini. Artinya, setiap bulan kami menemukan beberapa jenis bug, biasanya pada fungsi yang tidak kritis, tetapi kami belum merilis rilisnya. Versi sebelumnya hanya bulan November. Tidak ada bug yang kami ketahui di dalamnya, mis. bug ditambahkan seiring kemajuan proyek.
Setelah Anda mengunduh WAL-G, Anda dapat menjalankan perintah βdaftar cadanganβ sederhana, meneruskan variabel lingkungan. Dan itu akan terhubung ke Object Storage dan memberi tahu Anda cadangan apa yang Anda miliki. Pada awalnya, tentu saja, Anda tidak boleh memiliki cadangan. Inti dari slide ini adalah untuk menunjukkan bahwa semuanya cukup sederhana. Ini adalah perintah konsol yang menerima variabel lingkungan dan menjalankan subperintah.
Setelah ini, Anda dapat membuat cadangan pertama Anda. Ucapkan βbackup-pushβ di WAL-G dan tentukan di WAL-G lokasi pgdata cluster Anda. Dan kemungkinan besar, PostgreSQL akan memberi tahu Anda, jika Anda belum memiliki sistem cadangan, bahwa Anda perlu mengaktifkan "mode arsip".
Ini berarti Anda harus masuk ke pengaturan dan mengaktifkan βarchive_mode = onβ dan menambahkan βarchive_commandβ, yang juga merupakan sub-perintah di WAL-G. Namun untuk beberapa alasan orang sering menggunakan skrip batang pada topik ini dan membungkusnya di sekitar WAL-G. Tolong jangan lakukan ini. Gunakan fungsionalitas yang ditemukan di WAL-G. Jika Anda melewatkan sesuatu, tulislah ke . WAL-G berasumsi bahwa ini adalah satu-satunya program yang berjalan di archive_command.
Kami menggunakan WAL-G terutama untuk membuat cluster Ketersediaan Tinggi dalam manajemen Database Yandex.
Dan biasanya digunakan pada topologi satu Master dan beberapa replikasi. Pada saat yang sama, ia membuat salinan cadangan di Yandex Object Storage.
Skenario yang paling umum adalah membuat salinan klaster menggunakan pemulihan Point in time. Namun dalam hal ini, kinerja sistem cadangan tidak begitu penting bagi kami. Kita hanya perlu mengupload cluster baru dari backup.
Biasanya, kita memerlukan cadangan kinerja sistem saat menambahkan node baru. Mengapa ini penting? Biasanya orang menambahkan node baru ke cluster karena cluster yang ada tidak dapat menangani beban baca. Mereka perlu menambahkan replika baru. Jika kita menambahkan beban dari pg_basebackup ke Master, maka Master mungkin akan runtuh. Oleh karena itu, sangat penting bagi kami untuk dapat dengan cepat mengunggah node baru dari arsip, sehingga menimbulkan beban minimal pada Master.
Dan situasi serupa lainnya. Ini adalah kebutuhan untuk me-restart Master lama setelah mengalihkan Cluster Master dari Pusat Data yang konektivitasnya terputus.
- Akibatnya, ketika merumuskan persyaratan untuk sistem penyalinan, kami menyadari bahwa pg_basebackup tidak cocok untuk kami saat beroperasi di cloud.
- Kami ingin dapat mengompresi data kami. Namun hampir semua sistem cadangan selain yang disertakan dalam kemasannya akan menyediakan kompresi data.
- Kami ingin memparalelkan semuanya karena pengguna di cloud membeli inti prosesor dalam jumlah besar. Tetapi jika kita tidak memiliki paralelisme dalam beberapa operasi, maka sejumlah besar inti menjadi tidak berguna.
- Kami memerlukan enkripsi karena seringkali data tersebut bukan milik kami dan tidak dapat disimpan dalam bentuk teks biasa. Omong-omong, kontribusi kami pada WAL-G dimulai dengan enkripsi. Kami menyelesaikan enkripsi di WAL-G, setelah itu kami ditanya: βMungkin salah satu dari kami akan mengembangkan proyek ini?β Dan sejak itu saya telah bekerja dengan WAL-G selama lebih dari setahun.
- Kami juga memerlukan pembatasan sumber daya, karena seiring berjalannya waktu dengan menggunakan cloud, kami menemukan bahwa terkadang orang mempunyai barang belanjaan penting di malam hari dan beban ini tidak dapat diganggu. Itu sebabnya kami menambahkan pembatasan sumber daya.
- Serta pencatatan dan pengelolaan.
- Dan verifikasi.
Kami melihat banyak alat yang berbeda. Untungnya, kami memiliki banyak pilihan di PostgreSQL. Dan di mana pun kami kehilangan sesuatu, suatu fungsi kecil, suatu fitur kecil.
Dan setelah mempelajari sistem yang ada, kami sampai pada kesimpulan bahwa kami akan mengembangkan WAL-G. Itu adalah proyek baru saat itu. Cukup mudah untuk mempengaruhi pengembangan infrastruktur cloud pada sistem cadangan.
Ideologi utama yang kami anut adalah WAL-G harus sesederhana balalaika.
WAL-G memiliki 4 perintah. Ini:
WAL-PUSH β arsipkan poros.
WAL-FETCH β ambil poros.
BACKUP-PUSH β membuat cadangan.
BACKUP-FETCH β mendapatkan cadangan dari sistem cadangan.
Faktanya, WAL-G juga memiliki pengelolaan cadangan ini, yaitu membuat daftar dan menghapus catatan dan cadangan dalam riwayat yang tidak lagi diperlukan saat ini.
Salah satu fungsi yang penting bagi kami adalah fungsi membuat salinan delta.
Salinan Delta berarti kita tidak membuat cadangan penuh seluruh cluster, tetapi hanya halaman yang diubah dari file yang diubah di cluster. Tampaknya secara fungsional ini sangat mirip dengan kemampuan memulihkan menggunakan WAL. Namun kita dapat menggabungkan cadangan delta single-threaded WAL secara paralel. Oleh karena itu, jika kita memiliki pencadangan dasar yang dilakukan pada hari Sabtu, pencadangan delta setiap hari, dan pada hari Kamis kami gagal, maka kami perlu menggabungkan 4 pencadangan delta dan 10 jam WAL. Ini akan memakan waktu yang hampir sama karena pencadangan delta dilakukan secara paralel.
Delta berbasis LSN - ini berarti saat membuat cadangan, kita perlu menggabungkan setiap halaman dan memeriksa LSN-nya dengan LSN dari cadangan sebelumnya untuk memahami bahwa itu telah berubah. Halaman apa pun yang berpotensi berisi data yang diubah harus ada di cadangan delta.
Seperti yang saya katakan, cukup banyak perhatian diberikan pada paralelisme.
Namun API arsip di PostgreSQL konsisten. PostgreSQL mengarsipkan satu file WAL dan ketika memulihkannya meminta satu file WAL. Namun ketika database meminta satu file WAL menggunakan perintah "WAL-FETCH", kita memanggil perintah "WAL-PREFETCH", yang menyiapkan 8 file berikutnya untuk mengambil data dari penyimpanan objek secara paralel.
Dan ketika database meminta kita untuk mengarsipkan satu file, kita melihat archive_status dan melihat apakah ada file WAL lainnya. Dan kami juga mencoba mendownload WAL secara paralel. Hal ini memberikan peningkatan kinerja yang signifikan dan secara signifikan mengurangi jarak dalam jumlah WAL yang tidak diarsipkan. Banyak pengembang sistem pencadangan percaya bahwa ini adalah sistem yang berisiko karena kami mengandalkan pengetahuan kami tentang kode internal yang bukan API PostgreSQL. PostgreSQL tidak menjamin keberadaan folder archive_status bagi kami dan tidak menjamin semantik, adanya sinyal kesiapan file WAL disana. Namun demikian, kami sedang mempelajari kode sumbernya, kami melihat bahwa memang demikian dan kami mencoba untuk mengeksploitasinya. Dan kami mengontrol arah perkembangan PostgreSQL; jika tiba-tiba mekanisme ini rusak, kami akan berhenti menggunakannya.
Dalam bentuknya yang murni, WAL delta berbasis LSN memerlukan pembacaan file cluster apa pun yang waktu modenya dalam sistem file telah berubah sejak pencadangan sebelumnya. Kami hidup dengan ini untuk waktu yang lama, hampir satu tahun. Dan pada akhirnya kami sampai pada kesimpulan bahwa kami memiliki delta WAL.
Artinya, setiap kali kita mengarsipkan WAL di Master, kita tidak hanya mengompresnya, mengenkripsinya, dan mengirimkannya ke jaringan, tetapi kita juga membacanya pada saat yang bersamaan. Kami menganalisis dan membaca catatan di dalamnya. Kami memahami blok mana yang telah berubah dan mengumpulkan file delta.
File delta menjelaskan rentang file WAL tertentu, menjelaskan informasi tentang blok mana yang diubah dalam rentang WAL ini. Dan kemudian file delta ini juga diarsipkan.
Di sini kita dihadapkan pada kenyataan bahwa kita memparalelkan semuanya dengan cukup cepat, tetapi kita tidak dapat membaca sejarah yang berurutan secara paralel, karena pada segmen tertentu kita mungkin menemukan akhir dari catatan WAL sebelumnya, yang belum ada hubungannya dengan kita, karena pembacaan paralel mengarah pada fakta bahwa pertama-tama kita menganalisis masa depan, yang belum memiliki masa lalu.
Akibatnya, kami harus memasukkan bagian yang tidak dapat dipahami ke dalam file _delta_partial. Alhasil, ketika kita kembali ke masa lalu, kita akan merekatkan potongan-potongan record WAL menjadi satu, setelah itu kita akan menguraikannya dan memahami apa yang berubah di dalamnya.
Jika dalam riwayat penguraian poros kami setidaknya ada satu titik di mana kami tidak memahami apa yang terjadi, maka selama pencadangan berikutnya kami akan dipaksa untuk membaca seluruh cluster lagi, seperti yang kami lakukan dengan LSN biasa berbasis delta.
Akibatnya, semua penderitaan kami mengarah pada fakta bahwa kami membuat perpustakaan parsing WAL-G menjadi open source. Sejauh yang saya tahu, belum ada yang menggunakannya, tetapi jika ada yang mau, menulis dan menggunakannya, itu ada di domain publik. (Tautan yang diperbarui )
Akibatnya, semua arus informasi terlihat cukup rumit. Master kami mengarsipkan poros dan mengarsipkan file delta. Dan replika yang membuat salinan cadangan harus menerima file delta selama waktu yang telah berlalu di antara pencadangan. Dalam hal ini, sebagian dari sejarah perlu ditambahkan secara massal dan diurai, karena tidak seluruh sejarah dapat dimasukkan ke dalam segmen yang besar. Dan hanya setelah itu replika dapat mengarsipkan cadangan delta lengkap.
Pada grafik semuanya terlihat lebih sederhana. Ini adalah unduhan dari salah satu cluster kami yang sebenarnya. Kami berbasis LSN, dibuat dalam satu hari. Dan kita melihat delta backup berbasis LSN berjalan dari jam tiga pagi sampai jam lima pagi. Ini adalah beban jumlah inti prosesor. WAL-delta membawa kami sekitar 20 menit ke sini, yaitu menjadi jauh lebih cepat, tetapi pada saat yang sama terjadi pertukaran yang lebih intens melalui jaringan.
Karena kami memiliki informasi tentang blok mana yang berubah dan jam berapa dalam riwayat database, kami melangkah lebih jauh dan memutuskan untuk mengintegrasikan fungsionalitas - ekstensi PostgreSQL yang disebut βpg_prefaulterβ
Ini berarti bahwa ketika basis siaga menjalankan perintah pemulihan, ia memberitahu WAL-G untuk mengambil file WAL berikutnya. Kami memahami kira-kira blok data mana yang akan diakses oleh proses pemulihan WAL dalam waktu dekat dan memulai operasi baca pada blok ini. Hal ini dilakukan guna meningkatkan kinerja pengontrol SSD. Karena gulungan WAL akan sampai pada halaman yang perlu diubah. Halaman ini ada di disk dan tidak ada di cache halaman. Dan dia akan menunggu secara serempak hingga halaman ini tiba. Namun di dekatnya ada WAL-G, yang mengetahui bahwa dalam beberapa ratus megabyte WAL berikutnya kita akan membutuhkan halaman tertentu dan pada saat yang sama mulai menghangatkannya. Memulai beberapa akses disk sehingga dijalankan secara paralel. Ini berfungsi dengan baik pada drive SSD, tetapi sayangnya, ini sama sekali tidak berlaku untuk hard drive, karena kami hanya mengganggu perintah kami.
Inilah yang ada di kode sekarang.
Ada fitur yang ingin kami tambahkan.
Gambar ini menunjukkan bahwa WAL-delta membutuhkan waktu yang relatif singkat. Dan ini membaca perubahan yang terjadi pada database pada siang hari. WAL-delta tidak hanya dapat dilakukan pada malam hari, karena tidak lagi menjadi sumber beban yang signifikan. Kita bisa membaca WAL-delta setiap menit karena murah. Dalam satu menit kita dapat memindai semua perubahan yang terjadi pada cluster. Dan ini bisa disebut "WAL-delta instan".
Intinya adalah ketika kita memulihkan cluster, kita mengurangi jumlah cerita yang harus kita gulung secara berurutan. Artinya, jumlah WAL yang digulung PostgreSQL harus dikurangi, karena memerlukan waktu yang cukup lama.
Tapi bukan itu saja. Jika kita mengetahui bahwa beberapa blok akan diubah hingga titik konsistensi cadangan, kita tidak dapat mengubahnya di masa lalu. Artinya, sekarang kami memiliki optimalisasi penerusan WAL-delta file demi file. Artinya jika, misalnya, pada hari Selasa sebuah tabel dihapus seluruhnya atau beberapa file dihapus seluruhnya dari tabel, maka ketika delta digulirkan pada hari Senin dan Sabtu pg_basebackup dipulihkan, kami bahkan tidak akan membuat data ini.
Kami ingin memperluas teknologi ini ke tingkat halaman. Artinya, jika beberapa bagian file berubah pada hari Senin, tetapi ditimpa pada hari Rabu, maka ketika memulihkan ke suatu titik pada hari Kamis, kita tidak perlu menulis beberapa versi halaman pertama ke disk.
Tapi ini masih merupakan ide yang sedang aktif dibahas di dalam diri kita, namun belum mencapai kode etiknya.
Kami ingin membuat satu fitur lagi di WAL-G. Kami ingin menjadikannya dapat diperluas karena kami perlu mendukung database yang berbeda dan ingin dapat melakukan pendekatan manajemen pencadangan dengan cara yang sama. Namun masalahnya adalah API MySQL sangat berbeda. Di MySQL, PITR tidak didasarkan pada log WAL fisik, tetapi pada binlog. Dan kami tidak memiliki sistem pengarsipan di MySQL yang dapat memberi tahu sistem eksternal bahwa binlog ini telah selesai dan perlu diarsipkan. Kita perlu berdiri di suatu tempat di cron dengan database dan memeriksa apakah ada sesuatu yang siap?
Dan dengan cara yang sama, selama pemulihan MySQL, tidak ada perintah pemulihan yang dapat memberi tahu sistem bahwa saya memerlukan file ini dan itu. Sebelum Anda mulai membangun kembali cluster Anda, Anda perlu mengetahui file apa yang Anda perlukan. Anda sendiri perlu menebak file apa yang Anda perlukan. Namun masalah ini mungkin bisa diatasi. (Klarifikasi: MySQL sudah didukung)
Dalam laporan tersebut, saya juga ingin membicarakan kasus-kasus ketika WAL-G tidak cocok untuk Anda.
Jika Anda tidak memiliki replika sinkron, WAL-G tidak menjamin bahwa segmen terakhir akan dipertahankan. Dan jika pengarsipan tertinggal dari beberapa segmen sejarah terakhir, itu adalah sebuah risiko. Jika tidak ada replika sinkron, saya tidak akan merekomendasikan penggunaan WAL-G. Namun, ini terutama dirancang untuk instalasi cloud, yang menyiratkan solusi Ketersediaan Tinggi dengan replika sinkron, yang bertanggung jawab atas keamanan byte terakhir yang dilakukan.
Saya sering melihat orang mencoba menjalankan WAL-G dan WAL-E secara bersamaan. Kami mendukung kompatibilitas mundur dalam artian WAL-G dapat memulihkan file dari WAL-E dan dapat memulihkan cadangan yang dibuat di WAL-E. Namun karena kedua sistem ini menggunakan wal-push paralel, mereka mulai saling mencuri file. Jika kita memperbaikinya di WAL-G, maka akan tetap ada di WAL-E. Di WAL-E, ia melihat status arsip, melihat file yang sudah selesai dan mengarsipkannya, sementara sistem lain tidak akan mengetahui bahwa file WAL ini ada, karena PostgreSQL tidak akan mencoba mengarsipkannya untuk kedua kalinya.
Apa yang akan kita perbaiki di sisi WAL-G? Kami tidak akan memberi tahu PostgreSQL bahwa file ini ditransfer secara paralel, dan ketika PostgreSQL meminta kami untuk mengarsipkannya, kami sudah mengetahui bahwa file tersebut dengan mode-waktu ini dan dengan md5 ini telah diarsipkan dan kami hanya akan mengatakan PostgreSQL - Oke, semuanya sudah siap tanpa perlu melakukan apa pun.
Namun masalah ini sepertinya tidak akan diperbaiki di sisi WAL-E, jadi saat ini tidak mungkin membuat perintah arsip yang akan mengarsipkan file di WAL-G dan WAL-E.
Selain itu, ada beberapa kasus di mana WAL-G tidak cocok untuk Anda saat ini, namun kami pasti akan memperbaikinya.
Pertama, saat ini kami tidak memiliki verifikasi cadangan bawaan. Kami tidak memiliki verifikasi selama pencadangan atau pemulihan. Tentu saja ini diterapkan di cloud. Namun hal ini diimplementasikan hanya dengan melakukan pra-pemeriksaan, cukup dengan memulihkan cluster. Saya ingin memberikan fungsi ini kepada pengguna. Tetapi dengan verifikasi, saya berasumsi bahwa di WAL-G dimungkinkan untuk memulihkan cluster dan memulainya, dan menjalankan tes asap: pg_dumpall ke /dev/null dan verifikasi indeks amcheck.
Saat ini di WAL-G tidak ada cara untuk menunda satu cadangan dari WAL. Artinya, kami mendukung beberapa jendela. Misalnya menyimpan tujuh hari terakhir, menyimpan sepuluh backup terakhir, menyimpan tiga full backup terakhir. Seringkali orang datang dan berkata: βKami memerlukan cadangan dari apa yang terjadi pada Tahun Baru dan kami ingin menyimpannya selamanya.β WAL-G belum bisa melakukan ini. (Catatan - Ini telah diperbaiki. Baca selengkapnya - Opsi tanda cadangan di )
Dan kami tidak memiliki checksum halaman dan pemeriksaan integritas untuk semua segmen poros saat memvalidasi PITR.
Dari semua ini saya menyusun proyek untuk Google Summer of Code. Jika Anda mengenal siswa pintar yang ingin menulis sesuatu di Go dan mendapatkan beberapa ribu dolar dari satu perusahaan dengan huruf βGβ, maka rekomendasikan proyek kami kepada mereka. Saya akan bertindak sebagai mentor untuk proyek ini, mereka bisa melakukannya. Jika tidak ada siswa, maka saya akan mengambilnya dan melakukannya sendiri di musim panas.
Dan kami memiliki banyak masalah kecil lainnya yang sedang kami atasi secara bertahap. Dan beberapa hal aneh terjadi.
Misalnya, jika Anda memberikan WAL-G cadangan kosong, cadangan tersebut akan hilang begitu saja. Misalnya, jika Anda memberi tahu dia bahwa dia perlu membuat cadangan folder kosong. File pg_control tidak akan ada di sana. Dan dia akan berpikir bahwa dia tidak memahami sesuatu. Secara teori, dalam hal ini Anda perlu menulis pesan biasa kepada pengguna untuk menjelaskan kepadanya cara menggunakan alat tersebut. Tapi ini bahkan bukan fitur pemrograman, tapi fitur bahasa yang bagus dan dapat dipahami.
Kami tidak tahu cara melakukan pencadangan offline. Jika database berbohong, kami tidak dapat membackupnya. Tapi semuanya sangat sederhana di sini. Kami memanggil pencadangan oleh LSN saat dimulai. LSN dari basis yang mendasarinya harus dibaca dari file kontrol. Dan ini adalah fitur yang belum terealisasi. Banyak sistem cadangan yang dapat membuat cadangan database yang mendasarinya. Dan itu nyaman.
Saat ini kami tidak dapat menangani kekurangan ruang cadangan dengan baik. Karena kami biasanya bekerja dengan cadangan besar di rumah. Dan mereka tidak sempat melakukannya. Namun jika seseorang ingin memprogram di Go sekarang, tambahkan penanganan kesalahan di luar ruang ke dalam bucket. Saya pasti akan memeriksa permintaan penarikan.
Dan hal utama yang membuat kami khawatir adalah kami menginginkan sebanyak mungkin pengujian integrasi buruh pelabuhan yang memeriksa berbagai skenario. Saat ini kami hanya menguji skenario dasar. Pada setiap penerapan, namun kami ingin memeriksa penerapan demi penerapan semua fungsi yang kami dukung. Secara khusus, misalnya, kami akan memiliki dukungan yang cukup untuk PostgreSQL 9.4-9.5. Kami mendukung mereka karena komunitas mendukung PostgreSQL, namun kami tidak memeriksa komitmen demi komitmen untuk memastikan semuanya tidak rusak. Dan menurut saya ini adalah risiko yang cukup serius.
Kami memiliki WAL-G yang berjalan di lebih dari seribu cluster di manajemen Database Yandex. Dan itu mencadangkan beberapa ratus terabyte data setiap hari.
Kami memiliki banyak TODO dalam kode kami. Kalau mau program ayo, kami tunggu pull requestnya, kami tunggu pertanyaannya.
pertanyaan
Selamat malam! Terima kasih! Dugaan saya adalah jika Anda menggunakan WAL-delta, Anda mungkin sangat bergantung pada penulisan satu halaman penuh. Dan jika ya, apakah Anda menjalankan tes? Anda menunjukkan grafik yang indah. Makin cantik lagi kalau FPW dimatikan?
Penulisan satu halaman penuh diaktifkan untuk kami, kami belum mencoba menonaktifkannya. Artinya, saya sebagai pengembang belum mencoba mematikannya. Administrator sistem yang telah melakukan penelitian mungkin telah meneliti masalah ini. Tapi kita butuh FPW. Hampir tidak ada yang menonaktifkannya, karena jika tidak, tidak mungkin mengambil cadangan dari replika.
Terima kasih atas laporannya! Saya punya dua pertanyaan. Pertanyaan pertama adalah apa yang akan terjadi pada tablespace?
Kami sedang menunggu permintaan tarik. Basis data kami ada di disk SSD dan NMVE dan kami tidak terlalu membutuhkan fitur ini. Saya belum siap menghabiskan waktu serius saat ini untuk melakukannya dengan baik. Saya dengan sepenuh hati menganjurkan agar kita mendukung hal ini. Ada orang yang mendukungnya, tapi mendukungnya dengan cara yang sesuai bagi mereka. Mereka membuat garpu, tapi mereka tidak membuat permintaan tarik. (Ditambahkan di versi 0.2.13)
Dan pertanyaan kedua. Anda mengatakan di awal bahwa WAL-G berasumsi bahwa ia bekerja sendiri dan tidak diperlukan pembungkus. Saya sendiri menggunakan pembungkusnya. Mengapa tidak digunakan?
Kami ingin ini sesederhana balalaika. Artinya Anda tidak memerlukan apa pun kecuali balalaika. Kami ingin sistemnya sederhana. Jika Anda memiliki fungsi yang perlu dilakukan dalam skrip, datang dan beri tahu kami - kami akan melakukannya di Go.
Selamat malam! Terima kasih atas laporannya! Kami tidak dapat membuat WAL-G berfungsi dengan dekripsi GPG. Ini mengenkripsi secara normal, tetapi tidak ingin mendekripsi. Apakah ini sesuatu yang tidak berhasil bagi kita? Situasinya menyedihkan.
Buat masalah di GitHub dan mari kita cari tahu.
Artinya, Anda belum pernah mengalami hal ini?
Ada fitur laporan kesalahan ketika WAL-G tidak memahami jenis file apa itu, ia bertanya: βMungkin itu dienkripsi?β Mungkin masalahnya bukan pada enkripsi sama sekali. Saya ingin meningkatkan pencatatan topik ini. Dia harus menguraikannya. Kami sedang mengerjakan topik ini dalam artian kami tidak begitu menyukai cara sistem untuk mendapatkan kunci publik dan privat diatur. Karena kami memanggil GPG eksternal sehingga memberikan kami kuncinya. Dan kemudian kami mengambil kunci ini dan mentransfernya ke GPG internal, yaitu PGP terbuka, yang dikompilasi untuk kami di dalam WAL-G, dan di sana kami menyebutnya enkripsi. Dalam hal ini, kami ingin meningkatkan sistem dan ingin mendukung enkripsi Libsodium (Ditambahkan di versi 0.2.15). Tentu saja, penguraian kode akan berhasil, mari kita cari tahu - Anda memerlukan lebih banyak gejala daripada beberapa kata. Anda dapat berkumpul di ruang pembicara suatu saat dan melihat sistemnya. (Enkripsi PGP tanpa GPG eksternal - v0.2.9)
Halo! Terima kasih atas laporannya! Saya punya dua pertanyaan. Saya memiliki keinginan aneh untuk melakukan log pg_basebackup dan WAL di dua penyedia, yaitu saya ingin melakukan satu cloud dan lainnya. Apakah ada cara untuk melakukan ini?
Ini belum ada sekarang, tapi ini ide yang menarik.
Saya hanya tidak mempercayai satu penyedia, saya ingin memiliki penyedia yang sama, untuk berjaga-jaga.
Idenya menarik. Secara teknis, hal ini sama sekali tidak sulit untuk diterapkan. Agar idenya tidak hilang, bolehkah saya meminta Anda membuat masalah di GitHub?
Ya tentu saja
Lalu, ketika siswa datang ke Google Summer of Code, kami akan menambahkan mereka ke proyek sehingga ada lebih banyak pekerjaan untuk memaksimalkan manfaat mereka.
Dan pertanyaan kedua. Ada masalah di GitHub. Saya pikir itu sudah ditutup. Ada kepanikan saat pemulihan. Dan untuk mengalahkannya, Anda membuat majelis terpisah. Itu benar dalam masalah. Dan ada pilihan untuk melakukan lingkungan variabel dalam satu thread. Dan itulah mengapa ini bekerja sangat lambat. Dan kami mengalami masalah ini, dan masalah ini belum diperbaiki.
Masalahnya adalah karena alasan tertentu penyimpanan (CEPH) mengatur ulang koneksi ketika kita melakukannya dengan konkurensi tinggi. Apa yang bisa dilakukan mengenai hal ini? Logika coba lagi terlihat seperti ini. Kami mencoba mengunduh file lagi. Dalam satu langkah, kami memiliki sejumlah file yang belum diunduh, kami akan membuat yang kedua untuk semua yang belum login. Dan selama setidaknya satu file dimuat per iterasi, kami ulangi dan ulangi dan ulangi. Kami meningkatkan logika percobaan ulang - kemunduran eksponensial. Namun tidak sepenuhnya jelas apa yang harus dilakukan dengan fakta bahwa koneksi terputus di sisi sistem penyimpanan. Artinya, ketika kita mengunggah ke satu aliran, itu tidak memutus koneksi tersebut. Apa yang bisa kami tingkatkan di sini? Kami memiliki pembatasan jaringan, kami dapat membatasi setiap koneksi berdasarkan jumlah byte yang dikirimkannya. Kalau tidak, saya tidak tahu bagaimana menghadapi kenyataan bahwa penyimpanan objek tidak memungkinkan kita mengunduh atau mengunduhnya secara paralel.
Tidak ada SLA? Bukankah sudah tertulis bagi mereka bagaimana mereka membiarkan diri mereka disiksa?
Intinya orang yang mengajukan pertanyaan ini biasanya punya brankas sendiri. Artinya, tidak ada yang berasal dari Amazon atau Google Cloud atau Yandex Object Storage.
Mungkin pertanyaannya bukan lagi untuk Anda?
Pertanyaannya di sini dalam hal ini tidak masalah kepada siapa. Jika ada ide untuk mengatasi hal ini, mari kita lakukan di WAL-G. Namun sejauh ini saya tidak punya ide bagus tentang cara menghadapinya. Ada beberapa Object Storage yang mendukung pencadangan daftar secara berbeda. Anda meminta mereka membuat daftar objek, dan mereka menambahkan folder di sana. WAL-G menjadi takut dengan hal ini - ada sesuatu di sini yang bukan file, saya tidak dapat memulihkannya, yang berarti cadangan tidak dipulihkan. Faktanya, Anda memiliki cluster yang dipulihkan sepenuhnya, tetapi cluster tersebut mengembalikan Anda status yang salah karena Object Storage mengembalikan beberapa informasi aneh yang tidak sepenuhnya dipahami.
Ini adalah hal yang terjadi di cloud Mail.
Jika Anda dapat membuat reproduksi...
Itu secara konsisten direproduksi...
Jika ada reproduksi, maka saya pikir kita akan bereksperimen dengan strategi percobaan ulang dan mencari cara untuk mencoba ulang dan memahami apa yang dibutuhkan cloud dari kita. Mungkin akan stabil bagi kita pada tiga koneksi dan tidak akan memutus koneksi, maka kita akan hati-hati mencapai tiga. Karena sekarang kita putuskan koneksi dengan sangat cepat, yaitu jika kita meluncurkan pemulihan dengan 16 thread, maka setelah percobaan ulang pertama akan ada 8 thread, 4 thread, 2 thread dan satu. Dan kemudian itu akan menarik file tersebut ke dalam satu aliran. Jika ada beberapa nilai ajaib seperti 7,5 utas yang terbaik untuk dipompa, maka kami akan memikirkannya dan mencoba membuat 7,5 utas lainnya. Ini sebuah ide.
Terima kasih atas laporannya! Seperti apa alur kerja lengkap untuk bekerja dengan WAL-G? Misalnya, dalam kasus bodoh ketika tidak ada delta di seluruh halaman. Dan kami mengambil dan menghapus cadangan awal, lalu mengarsipkan porosnya hingga wajah kami membiru. Di sini, seperti yang saya pahami, ada kerusakan. Pada titik tertentu Anda perlu membuat cadangan halaman delta, yaitu beberapa proses eksternal yang mendorong hal ini atau bagaimana hal ini bisa terjadi?
API cadangan delta cukup sederhana. Ada angka disana β langkah max delta, begitulah sebutannya. Defaultnya adalah nol. Artinya, setiap kali Anda melakukan backup-push, backup lengkap akan diunduh. Jika Anda mengubahnya ke angka positif apa pun, misalnya 3, maka saat berikutnya Anda melakukan backup-push, riwayat pencadangan sebelumnya akan terlihat. Dia melihat bahwa Anda tidak melebihi rantai 3 delta dan membuat delta.
Artinya, setiap kali kami meluncurkan WAL-G, ia mencoba membuat cadangan penuh?
Tidak, kami menjalankan WAL-G, dan mencoba membuat delta jika kebijakan Anda mengizinkannya.
Secara kasar, jika Anda menjalankannya dengan nol setiap saat, apakah akan berperilaku seperti pg_basebackup?
Tidak, ini akan tetap berjalan lebih cepat karena menggunakan kompresi dan paralelisme. Pg_basebackup akan menempatkan poros di sebelah Anda. WAL-G berasumsi bahwa Anda telah mengkonfigurasi pengarsipan. Dan itu akan mengeluarkan peringatan jika tidak dikonfigurasi.
Pg_basebackup dapat dijalankan tanpa poros.
Ya, maka mereka akan berperilaku hampir sama. Pg_basebackup menyalin ke sistem file. Omong-omong, kami memiliki fitur baru yang saya lupa sebutkan. Sekarang kita dapat melakukan backup ke sistem file dari pg_basebackup. Saya tidak tahu mengapa ini diperlukan, tetapi hal itu ada.
Misalnya di CephFS. Tidak semua orang ingin mengkonfigurasi Object Storage.
Ya, mungkin itu sebabnya mereka mengajukan pertanyaan tentang fitur ini agar kami dapat melakukannya. Dan kami berhasil.
Terima kasih atas laporannya! Hanya ada pertanyaan tentang menyalin ke sistem file. Secara langsung, apakah Anda sekarang mendukung penyalinan ke penyimpanan jarak jauh, misalnya jika ada rak di pusat data atau yang lainnya?
Dalam rumusan ini, ini adalah pertanyaan yang sulit. Ya, kami mendukung, namun fungsi ini belum disertakan dalam rilis apa pun. Artinya, semua pra-rilis mendukung hal ini, tetapi versi rilis tidak. Fungsionalitas ini ditambahkan di versi 0.2. Pasti akan segera dirilis, segera setelah kami memperbaiki semua bug yang diketahui. Namun saat ini hal tersebut baru bisa dilakukan pada pra-rilis. Ada dua bug di pra-rilis. Masalah pemulihan WAL-E, kami belum memperbaikinya. Dan dalam pra-rilis terbaru, bug tentang delta-backup telah ditambahkan. Oleh karena itu, kami menyarankan semua orang untuk menggunakan versi rilis. Segera setelah tidak ada lagi bug dalam pra-rilis, kami dapat mengatakan bahwa kami mendukung Google Cloud, hal-hal yang kompatibel dengan S3, dan penyimpanan file.
Halo, terima kasih atas laporannya. Sepengetahuan saya, WAL-G bukanlah semacam sistem terpusat seperti bartender? Apakah Anda berencana untuk bergerak ke arah ini?
Masalahnya adalah kita telah menjauh dari arah ini. WAL-G tinggal di host dasar, di host cluster, dan di semua host di cluster. Ketika kami pindah ke beberapa ribu cluster, kami memiliki banyak instalasi bartender. Dan setiap kali ada sesuatu yang berantakan di dalamnya, itu menjadi masalah besar. Karena perlu diperbaiki, Anda perlu memahami cluster mana yang sekarang tidak memiliki cadangan. Saya tidak berencana mengembangkan WAL-G ke arah perangkat keras fisik untuk sistem cadangan. Jika komunitas menginginkan beberapa fungsi di sini, saya tidak keberatan sama sekali.
Kami memiliki tim yang bertanggung jawab atas penyimpanan. Dan kami merasa sangat baik karena bukan kami, ada orang-orang khusus yang meletakkan file kami di tempat yang aman. Mereka melakukan segala macam pengkodean cerdas di sana untuk menahan hilangnya sejumlah file tertentu. Mereka bertanggung jawab atas bandwidth jaringan. Ketika Anda memiliki seorang bartender, Anda mungkin tiba-tiba mengetahui bahwa database kecil dengan banyak lalu lintas telah berkumpul di server yang sama. Tampaknya Anda memiliki banyak ruang di dalamnya, tetapi karena alasan tertentu semuanya tidak dapat masuk melalui jaringan. Ini mungkin terjadi sebaliknya. Ada banyak jaringan di sana, ada inti prosesor, tetapi tidak ada disk di sini. Dan kami bosan dengan kebutuhan untuk menyulap sesuatu, dan kami beralih ke fakta bahwa penyimpanan data adalah layanan terpisah, yang menjadi tanggung jawab orang-orang khusus yang terpisah.
PS Versi baru telah dirilis , di mana Anda dapat menggunakan file konfigurasi .walg.json, yang secara default terletak di direktori home postgres. Anda dapat meninggalkan skrip bash. Contoh .walg.json ada dalam masalah ini
Video:
Sumber: www.habr.com