Aku saranake sampeyan maca transkrip laporan saka awal 2019 dening Andrey Borodin "Serep karo WAL-G. Apa ana ing 2019?"
Halo kabeh! Jenengku Andrey Borodin. Aku pangembang ing Yandex. Aku wis kasengsem ing PostgreSQL wiwit 2016, sawise aku ngomong karo pangembang lan padha ngandika sing kabeh iku prasaja - sampeyan njupuk kode sumber lan mbangun, lan kabeh bakal bisa. Lan wiwit iku aku ora bisa mandheg - aku nulis kabeh macem-macem perkara.
Salah sawijining perkara sing dakgarap yaiku sistem serep. . Umumé, ing Yandex kita wis nggarap sistem cadangan ing PostgreSQL kanggo wektu sing suwe. Lan sampeyan bisa nemokake ing Internet seri saka enem laporan carane kita nggawe sistem serep. Lan saben taun padha berkembang sethitik, berkembang sethitik, lan dadi luwih dipercaya.
Nanging dina iki laporan ora mung bab apa kita wis rampung, nanging uga bab carane prasaja lan apa. Pira saka sampeyan sing wis nonton laporanku babagan WAL-G? Iku apik yen sawetara wong ora nonton, amarga aku bakal miwiti karo sing paling gampang.
Yen dumadakan sampeyan duwe kluster PostgreSQL, lan aku saben wong wis saperangan karo wong-wong mau, lan dumadakan durung ana sistem serep, sampeyan kudu njaluk sembarang panyimpenan S3 utawa panyimpenan kompatibel Google Cloud.
Contone, sampeyan bisa teka ing stand lan njupuk kode promosi kanggo Yandex Object Storage, sing kompatibel karo S3.
Banjur nggawe Ember. Iku mung wadhah kanggo informasi.
Nggawe pangguna layanan.
Gawe kunci akses kanggo pangguna layanan: aws-s3-key.
Ngundhuh rilis stabil paling anyar saka WAL-G.
Kepiye pra-rilis kita beda karo rilis? Aku kerep dijaluk ngeculake awal. Lan yen ora ana bug ing versi kanggo wektu sing cukup, contone, sasi, banjur aku ngeculake. Punika release saka November. Lan iki tegese saben wulan kita nemokake sawetara bug, biasane ing fungsi non-kritis, nanging kita durung dirilis release. Versi sadurungé mung November. Ora ana kewan omo sing kita kenal, yaiku bug ditambahake nalika proyek kasebut maju.
Sawise sampeyan wis ndownload WAL-G, sampeyan bisa mbukak printah "daftar serep" prasaja, maringaken ing variabel lingkungan. Lan bakal nyambung menyang Obyek Storage lan pitutur marang kowe apa serep sampeyan duwe. Kaping pisanan, mesthi, sampeyan ora kudu nggawe serep. Titik slide iki kanggo nuduhake yen kabeh iku cukup prasaja. Iki minangka printah console sing nampa variabel lingkungan lan nglakokake subcommands.
Sawise iki, sampeyan bisa nggawe serep pisanan. Ngomong "serep-push" ing WAL-G lan nemtokake ing WAL-G lokasi pgdata kluster sampeyan. Lan paling kamungkinan, PostgreSQL bakal pitutur marang kowe, yen sampeyan durung duwe sistem serep, sampeyan kudu ngaktifake "archive-mode".
Iki tegese sampeyan kudu pindhah menyang setelan lan nguripake "archive_mode = on" lan nambah "archive_command", kang uga subcommand ing WAL-G. Nanging sakperangan alesan wong asring nggunakake skrip bar ing topik iki lan mbungkus ing WAL-G. Aja nglakoni iki. Gunakake fungsi sing ditemokake ing WAL-G. Yen sampeyan ilang soko, nulis menyang . WAL-G nganggep iku mung program sing mlaku ing archive_command.
Kita nggunakake WAL-G utamane kanggo nggawe kluster Ketersediaan Dhuwur ing manajemen Database Yandex.
Lan biasane digunakake ing topologi siji Master lan sawetara replikasi. Ing wektu sing padha, nggawe salinan serep ing Panyimpenan Obyek Yandex.
Skenario sing paling umum yaiku nggawe salinan kluster nggunakake titik pemulihan wektu. Nanging ing kasus iki, kinerja sistem serep ora penting banget kanggo kita. Kita mung kudu ngunggah kluster anyar saka serep.
Biasane, kita butuh kinerja sistem serep nalika nambahake simpul anyar. Apa sebabe penting? Biasane wong nambah simpul anyar menyang kluster amarga kluster sing ana ora bisa nangani beban sing diwaca. Dheweke kudu nambah replika anyar. Yen kita nambahake beban saka pg_basebackup menyang Master, mula Master bisa ambruk. Mulane, penting banget kanggo kita supaya bisa ngunggah simpul anyar saka arsip kanthi cepet, nggawe beban minimal ing Master.
Lan kahanan liyane sing padha. Iki minangka kabutuhan kanggo miwiti maneh Master lawas sawise ngalih Master Kluster saka Pusat Data sing ilang konektivitas.
- Akibaté, nalika ngrumusake syarat kanggo sistem salinan, kita nyadari yen pg_basebackup ora cocok kanggo kita nalika operasi ing méga.
- Kita pengin bisa ngompres data kita. Nanging meh kabeh sistem serep liyane saka apa sing ana ing kothak bakal nyedhiyakake komprèsi data.
- We wanted kanggo parallelize kabeh amarga pangguna ing maya tuku nomer akeh intine prosesor. Nanging yen kita ora duwe paralelisme ing sawetara operasi, nomer akeh intine dadi ora ana guna.
- Kita butuh enkripsi amarga asring data kasebut dudu duweke lan ora bisa disimpen ing teks sing jelas. Miturut cara, kontribusi kita kanggo WAL-G diwiwiti kanthi enkripsi. Kita ngrampungake enkripsi ing WAL-G, banjur ditakoni: "Mungkin salah sijine bakal ngembangake proyek kasebut?" Lan wiwit iku aku wis kerja karo WAL-G luwih saka setahun.
- Kita uga mbutuhake throttling sumber daya, amarga liwat wektu nggunakake maya, kita nemokake yen kadhangkala wong duwe beban sembako sing penting ing wayah wengi lan beban iki ora bisa diganggu. Pramila kita nambahake throttling sumber.
- Uga listing lan manajemen.
- Lan verifikasi.
Kita nyawang macem-macem alat. Untunge, kita duwe pilihan gedhe ing PostgreSQL. Lan nang endi wae kita padha ilang soko, sawetara siji fungsi cilik, sawetara siji fitur cilik.
Lan sawise mriksa sistem sing ana, kita entuk kesimpulan yen bakal ngembangake WAL-G. Iku proyek anyar banjur. Iku cukup gampang kanggo pengaruhe pembangunan menyang infrastruktur maya saka sistem serep.
Ideologi utama sing dianut yaiku WAL-G kudu prasaja kaya balalaika.
WAL-G duwe 4 printah. Iki:
WAL-PUSH - arsip poros.
WAL-FETCH - njaluk poros.
BACKUP-PUSH - gawe serep.
BACKUP-FETCH - entuk serep saka sistem serep.
Nyatane, WAL-G uga duwe manajemen serep kasebut, yaiku nyathet lan mbusak cathetan lan serep ing sejarah sing saiki ora dibutuhake maneh.
Salah sawijining fungsi penting kanggo kita yaiku fungsi nggawe salinan delta.
Salinan Delta tegese kita ora nggawe serep lengkap kabeh kluster, nanging mung kaca diganti file diganti ing kluster. Iku bakal katon sing fungsi iki banget padha karo kemampuan kanggo mbalekake nggunakake WAL. Nanging kita bisa muter serep delta siji-Utas WAL ing podo karo. Patut, nalika kita duwe serep dhasar digawe ana, delta serep saben dina, lan ana kita gagal, banjur kita kudu muter munggah 4 delta serep lan 10 jam WAL. Bakal njupuk bab wektu sing padha amarga serep delta muter ing podo karo.
Delta adhedhasar LSN - iki tegese nalika nggawe serep, kita kudu nggabungake saben kaca lan mriksa LSN karo LSN saka serep sadurunge supaya ngerti sing wis diganti. Sembarang kaca sing bisa ngemot data sing diganti kudu ana ing serep delta.
Kaya sing dakkandhakake, cukup akeh perhatian kanggo paralelisme.
Nanging API arsip ing PostgreSQL konsisten. PostgreSQL arsip siji file WAL lan nalika mulihake njaluk siji file WAL. Nanging nalika database njaluk siji file WAL nggunakake printah "WAL-FETCH", kita nelpon printah "WAL-PREFETCH", kang nyiapake sabanjuré 8 file kanggo njupuk data saka nyimpen obyek ing podo karo.
Lan nalika database njaluk kita arsip siji file, kita katon ing archive_status lan ndeleng yen ana file WAL liyane. Lan kita uga nyoba ndownload WAL kanthi paralel. Iki menehi gain kinerja pinunjul lan Ngartekno nyuda kadohan ing nomer unarchived WAL. Akeh pangembang sistem cadangan percaya yen iki minangka sistem sing beboyo amarga kita ngandelake kawruh babagan kode internal sing dudu API PostgreSQL. PostgreSQL ora njamin anané folder archive_status kanggo kita lan ora njamin semantik, anané sinyal kesiapan kanggo file WAL ing kana. Nanging, kita nyinaoni kode sumber kasebut, kita ngerti manawa pancen bener lan kita nyoba ngeksploitasi. Lan kita ngontrol arah sing dikembangake PostgreSQL; yen dumadakan mekanisme iki rusak, kita bakal mandheg nggunakake.
Ing wangun murni, WAL delta basis LSN mbutuhake maca file kluster sing mode-wektu ing sistem file wis diganti wiwit serep sadurunge. Kita urip karo iki kanggo dangu, meh setahun. Lan ing pungkasan kita teka menyang kesimpulan sing kita duwe delta WAL.
Iki tegese saben-saben kita arsip WAL ing Master, kita ora mung compress, encrypt lan ngirim menyang jaringan, nanging uga maca ing wektu sing padha. Kita nganalisa lan maca cathetan kasebut. Kita ngerti pamblokiran sing wis diganti lan ngumpulake file delta.
File delta nggambarake sawetara file WAL tartamtu, nggambarake informasi babagan pamblokiran sing diganti ing sawetara WAL iki. Banjur file delta iki uga diarsipaké.
Ing kene kita ngadhepi kasunyatan manawa kabeh paralel kanthi cepet, nanging kita ora bisa maca sejarah kanthi sejajar, amarga ing bagean tartamtu kita bisa nemoni pungkasan rekaman WAL sadurunge, sing durung ana hubungane, amarga maca podo mimpin kanggo sing pisanan kita njelasno mangsa, kang durung duwe past.
Akibaté, kita kudu nglebokake potongan sing ora bisa dingerteni menyang file _delta_partial. Akibaté, nalika bali menyang jaman kepungkur, kita bakal nempelake potongan-potongan rekaman WAL dadi siji, sawise iku kita bakal ngurai lan ngerti apa sing diganti.
Yen ing sajarah parsing poros kita paling ora ana siji titik sing ora ngerti apa sing kedadeyan, mula, sajrone serep sabanjure, kita bakal kepeksa maca kabeh kluster maneh, kaya sing kita lakoni karo LSN biasa. - adhedhasar delta.
Akibaté, kabeh kasangsaran kita nyebabake kasunyatan manawa kita mbukak perpustakaan parsing WAL-G. Aku ngerti, durung ana sing nggunakake, nanging yen ana sing pengin, nulis lan nggunakake, ana ing domain umum. (Link dianyari )
Akibaté, kabeh informasi mili katon cukup rumit. Master kita arsip poros lan arsip file delta. Lan replika sing nggawe salinan serep kudu nampa file delta sajrone wektu sing wis liwati antarane serep. Ing kasus iki, bagean saka sajarah kudu ditambahake ing akeh lan parsed, amarga ora kabeh sajarah pas menyang bagean gedhe. Lan mung sawise iki tiron bisa arsip serep delta lengkap.
Ing grafik, kabeh katon luwih gampang. Iki minangka undhuhan saka salah sawijining klompok nyata. Kita duwe basis LSN, digawe ing sawijining dina. Lan kita waca yen serep delta basis LSN mlaku saka jam telu esuk nganti jam lima esuk. Iki minangka beban ing jumlah inti prosesor. WAL-delta njupuk kita udakara menit 20. Yaiku, dadi luwih cepet, nanging ing wektu sing padha ana ijol-ijolan sing luwih kuat liwat jaringan.
Amarga kita duwe informasi babagan pamblokiran sing diganti lan ing wektu apa ing sejarah database, kita luwih maju lan mutusake kanggo nggabungake fungsi - ekstensi PostgreSQL sing diarani "pg_prefaulter"
Iki tegese nalika stand-by basis executes mulihake printah, marang WAL-G kanggo njupuk file WAL sabanjuré. Kita ngerti kira-kira data sing ngalangi proses pemulihan WAL sing bakal diakses ing mangsa ngarep lan miwiti operasi maca ing blok kasebut. Iki ditindakake kanggo nambah kinerja pengontrol SSD. Amarga gulung WAL bakal tekan kaca sing kudu diganti. Kaca iki ana ing disk lan ora ana ing cache kaca. Lan dheweke bakal ngenteni kanthi sinkron nganti kaca iki teka. Nanging ing cedhak yaiku WAL-G, sing ngerti yen ing sawetara atus megabyte WAL sabanjure, kita butuh kaca tartamtu lan ing wektu sing padha wiwit anget. Miwiti macem-macem akses disk supaya bisa dieksekusi kanthi paralel. Iki bisa digunakake kanthi apik ing drive SSD, nanging, sayangé, pancen ora bisa ditrapake kanggo hard drive, amarga kita mung ngganggu pandhuane.
Iki sing ana ing kode saiki.
Ana fitur sing pengin ditambahake.
Gambar iki nuduhake yen WAL-delta njupuk wektu relatif cendhak. Lan iki maca owah-owahan sing dumadi ing database sak dina. Kita bisa nindakake WAL-delta ora mung ing wayah wengi, amarga iku ora ana maneh sumber pinunjul saka mbukak. Kita bisa maca WAL-delta saben menit amarga iku murah. Ing siji menit kita bisa mindai kabeh owah-owahan sing wis kedaden kanggo kluster. Lan iki bisa disebut "instan WAL-delta".
Intine yaiku yen kita mulihake kluster, kita nyuda jumlah crita sing kudu digulung kanthi urutan. Yaiku, jumlah WAL sing digulung PostgreSQL kudu dikurangi, amarga butuh wektu sing signifikan.
Nanging ora mung kuwi. Yen kita ngerti manawa sawetara blok bakal diowahi dadi konsistensi cadangan, mula kita ora bisa ngganti ing jaman kepungkur. Tegese, saiki kita duwe optimasi file-by-file saka WAL-delta forwarding. Iki tegese yen, contone, ing dina Selasa sawetara tabel rampung dibusak utawa sawetara file dibusak kabeh saka meja, banjur nalika delta muter liwat ana lan pg_basebackup ana dibalèkaké, kita ora malah nggawe data iki.
Kita pengin ngluwihi teknologi iki nganti tingkat kaca. Sing, yen sawetara bagéan saka file diganti dina Senin, nanging bakal ditindih ing Rebo, banjur nalika mulihake menyang titik ana, kita ora perlu kanggo nulis sawetara versi pisanan saka kaca menyang disk.
Nanging iki isih gagasan sing lagi aktif rembugan ing kita, nanging durung tekan kode.
Kita pengin nggawe siji fitur liyane ing WAL-G. Kita pengin nggawe ekstensibel amarga kita kudu ndhukung database sing beda-beda lan pengin bisa nyedhaki manajemen serep kanthi cara sing padha. Nanging masalahe yaiku API MySQL beda banget. Ing MySQL, PITR ora adhedhasar log WAL fisik, nanging ing binlog. Lan kita ora duwe sistem pengarsipan ing MySQL sing bakal ngandhani sawetara sistem eksternal yen binlog iki wis rampung lan kudu diarsipake. We kudu ngadeg nang endi wae ing cron karo database lan mriksa yen ana soko siap?
Lan kanthi cara sing padha, sajrone mulihake MySQL, ora ana perintah mulihake sing bisa ngandhani sistem yen aku butuh file kasebut. Sadurunge miwiti mbangun maneh kluster, sampeyan kudu ngerti file apa sing dibutuhake. Sampeyan dhewe kudu ngira file apa sing sampeyan butuhake. Nanging masalah kasebut bisa uga bisa diatasi. (Klarifikasi: MySQL wis didhukung)
Ing laporan kasebut, aku uga pengin ngomong babagan kasus kasebut nalika WAL-G ora cocog kanggo sampeyan.
Yen sampeyan ora duwe replika sinkron, WAL-G ora njamin yen bagean pungkasan bakal dilestarekake. Lan yen arsip lags konco sawetara perangan pungkasan saka sajarah, sing resiko. Yen ora ana replika sinkron, aku ora nyaranake nggunakake WAL-G. Isih, iku utamané dirancang kanggo instalasi maya, kang nuduhake solusi High Availability karo tiron sinkron, kang tanggung jawab kanggo safety saka bita pungkasan setya.
Aku kerep ndeleng wong nyoba kanggo mbukak loro WAL-G lan WAL-E ing wektu sing padha. Kita ndhukung kompatibilitas mundur ing pangertèn sing WAL-G bisa mulihake file saka WAL-E lan bisa mulihake serep digawe ing WAL-E. Nanging amarga loro sistem iki nggunakake paralel wal-push, padha miwiti nyolong file saka saben liyane. Yen kita ndandani ing WAL-G, iku bakal tetep ing WAL-E. Ing WAL-E, katon ing status arsip, ndeleng file sing wis rampung lan arsip, dene sistem liyane mung ora ngerti manawa file WAL iki ana, amarga PostgreSQL ora bakal nyoba arsip kaping pindho.
Apa sing arep kita ndandani kene ing sisih WAL-G? Kita ora bakal ngandhani PostgreSQL manawa file iki ditransfer kanthi paralel, lan nalika PostgreSQL njaluk kita arsip, kita bakal ngerti manawa file kasebut nganggo mode-wektu iki lan md5 iki wis diarsipake lan kita mung bakal ngomong PostgreSQL - OK, kabeh wis siyap tanpa kudu nindakake apa-apa.
Nanging masalah iki ora bisa diatasi ing sisih WAL-E, mula saiki ora bisa nggawe perintah arsip sing bakal arsip file kasebut ing WAL-G lan WAL-E.
Kajaba iku, ana kasus nalika WAL-G ora cocok kanggo sampeyan saiki, nanging kita mesthi bakal ndandani.
Kaping pisanan, saiki kita ora duwe verifikasi serep sing dibangun. Kita ora duwe verifikasi sajrone serep utawa pemulihan. Mesthi, iki dileksanakake ing méga. Nanging iki dileksanakake kanthi pre-checking, mung kanthi mulihake kluster. Aku pengin menehi fungsi iki kanggo pangguna. Nanging kanthi verifikasi, aku nganggep yen ing WAL-G bakal bisa mulihake kluster lan miwiti, lan mbukak tes kumelun: pg_dumpall menyang / dev / null lan verifikasi indeks amcheck.
Saiki ing WAL-G ora ana cara kanggo nundha siji cadangan saka WAL. Sing, kita ndhukung sawetara jendhela. Contone, nyimpen pitung dina pungkasan, nyimpen sepuluh serep pungkasan, nyimpen telung serep lengkap pungkasan. Asring wong teka lan ujar: "Kita butuh serep apa sing kedadeyan ing Taun Anyar lan kita pengin tetep selawase." WAL-G durung ngerti carane nindakake iki. (Cathetan - Iki wis didandani. Waca liyane - Pilihan tandha serep ing )
Lan kita ora duwe checksum kaca lan mriksa integritas kanggo kabeh segmen poros nalika validasi PITR.
Saka kabeh iki, aku nggawe proyek kanggo Google Summer of Code. Yen sampeyan ngerti siswa pinter sing pengin nulis soko ing Go lan entuk pirang-pirang ewu dolar saka siji perusahaan kanthi huruf "G", banjur nyaranake proyek kita. Aku bakal tumindak minangka mentor kanggo proyek iki, padha bisa nindakake. Yen ora ana siswa, banjur aku bakal njupuk lan nindakake dhewe ing mangsa panas.
Lan kita duwe akeh masalah cilik liyane sing mboko sithik digarap. Lan sawetara kedadeyan sing aneh banget.
Contone, yen sampeyan menehi WAL-G serep kosong, iku mung bakal tiba. Contone, yen sampeyan ngandhani yen dheweke kudu nggawe serep folder kosong. File pg_control ora bakal ana. Lan dheweke bakal mikir yen dheweke ora ngerti apa-apa. Ing teori, ing kasus iki, sampeyan kudu nulis pesen normal kanggo pangguna kanggo nerangake carane nggunakake alat. Nanging iki dudu fitur program, nanging fitur saka basa sing apik lan bisa dingerteni.
Kita ora ngerti carane nggawe serep offline. Yen database ngapusi, kita ora bisa nggawe serep. Nanging kabeh iku prasaja banget ing kene. Kita nelpon serep dening LSN nalika diwiwiti. LSN basis dhasar kudu diwaca saka file kontrol. Lan iki minangka fitur sing ora dingerteni. Akeh sistem serep bisa nggawe serep basis data. Lan iku trep.
Saiki kita ora bisa nangani kekurangan ruang serep kanthi bener. Amarga kita biasane nggarap serep gedhe ing omah. Lan padha ora njaluk watara kanggo iku. Nanging yen ana wong sing pengin program ing Go saiki, tambahake nangani kesalahan sing ora ana ruang menyang ember. Aku mesthi bakal nliti panjaluk narik.
Lan perkara utama sing kuwatir yaiku kita pengin akeh tes integrasi docker sing bisa mriksa skenario sing beda. Saiki kita mung nyoba skenario dhasar. Ing saben commit, nanging kita pengin mriksa commit-by-commit kabeh fungsi sing didhukung. Utamane, contone, kita bakal duwe dhukungan sing cukup kanggo PostgreSQL 9.4-9.5. Kita ndhukung dheweke amarga komunitas ndhukung PostgreSQL, nanging kita ora mriksa komit-by-komit kanggo mesthekake yen kabeh ora rusak. Lan misale jek kula sing iki resiko rodo serius.
Kita duwe WAL-G sing mlaku ing luwih saka sewu kluster ing manajemen Database Yandex. Lan gawe serep sawetara atus terabyte data saben dina.
Kita duwe akeh TODO ing kode kita. Yen sampeyan pengin program, teka, kita ngenteni panjalukan narik, kita ngenteni pitakonan.
Pitakonan
sugeng sonten! Matur nuwun! Kula guess iku yen sampeyan nggunakake WAL-delta, sampeyan mbokmenawa gumantung banget ing full-page nulis. Lan yen mangkono, apa sampeyan nindakake tes? Sampeyan nuduhake grafik sing apik. Luwih ayu maneh yen FPW dipateni?
Tulisan kaca lengkap diaktifake kanggo kita, kita durung nyoba mateni. Yaiku, aku, minangka pangembang, durung nyoba mateni. Administrator sistem sing wis riset mbokmenawa wis riset masalah iki. Nanging kita kudu FPW. Meh ora ana sing mateni, amarga ora bisa njupuk serep saka replika.
Matur nuwun kanggo laporan! Aku duwe rong pitakonan. Pitakonan pisanan yaiku apa sing bakal kelakon ing tablespaces?
We are nunggu panjalukan narik. Basis data kita urip ing disk SSD lan NMVE lan kita ora butuh fitur iki. Aku ora siap nglampahi wektu serius saiki kanggo nindakake kanthi apik. Aku kanthi sepenuh ati nyengkuyung supaya kita ndhukung iki. Ana wong sing ndhukung, nanging ndhukung kanthi cara sing cocog karo dheweke. Dheweke nggawe garpu, nanging ora njaluk panjaluk. (Ditambahake ing versi 0.2.13)
Lan pitakonan kapindho. Sampeyan ngandika ing awal banget sing WAL-G nganggep sing dianggo piyambak lan ora wrappers dibutuhake. Aku nggunakake wrappers dhewe. Apa ora kudu digunakake?
Kita pengin dadi prasaja kaya balalaika. Iki tegese sampeyan ora butuh apa-apa kajaba balalaika. Kita pengin sistem dadi prasaja. Yen sampeyan duwe fungsi sing kudu sampeyan lakoni ing skrip, banjur teka lan ngandhani - kita bakal nindakake ing Go.
sugeng sonten! Matur nuwun kanggo laporan! Kita ora bisa nggawe WAL-G bisa nggarap dekripsi GPG. Iku encrypts biasane, nanging ora pengin decrypt. Apa soko sing ora bisa kanggo kita? Kahanane nyenengke.
Nggawe masalah ing GitHub lan ayo ngerteni.
Yaiku, sampeyan durung nemoni iki?
Ana fitur laporan kesalahan sing nalika WAL-G ora ngerti apa jenis file kasebut, mula takon: "Mungkin dienkripsi?" Mungkin masalahe dudu enkripsi. Aku pengin nambah logging ing topik iki. Dheweke kudu decipher. Saiki kita lagi nggarap topik iki ing pangertèn sing kita ora seneng carane sistem kanggo njupuk kunci umum lan pribadi diatur. Amarga kita nelpon GPG eksternal supaya menehi kita kunci. Banjur kita njupuk tombol kasebut lan nransfer menyang GPG internal, yaiku PGP sing mbukak, sing disusun kanggo kita ing WAL-G, lan ing kana kita nelpon enkripsi. Ing babagan iki, kita pengin nambah sistem lan pengin ndhukung enkripsi Libsodium (Ditambahake ing versi 0.2.15). Mesthine, dekoding kudu bisa, ayo dipikirake - sampeyan butuh gejala luwih akeh tinimbang sawetara tembung. Sampeyan bisa ngumpulake ing kamar speaker lan ndeleng sistem. (Enkripsi PGP tanpa GPG eksternal - v0.2.9)
Hello! Matur nuwun kanggo laporan! Aku duwe rong pitakonan. Aku duwe kepinginan aneh kanggo nindakake pg_basebackup lan WAL log in loro panyedhiya, IE aku arep nindakake siji maya lan liyane. Apa ana sawetara cara kanggo nindakake iki?
Iki ora ana saiki, nanging ide sing menarik.
Aku mung ora ngandel siji panyedhiya, aku pengin duwe padha ing liyane, mung ing kasus.
Ide kasebut menarik. Secara teknis, iki ora angel ditindakake. Kanggo nyegah ide kasebut ilang, aku bisa njaluk sampeyan nggawe masalah ing GitHub?
Ya mesthi wae.
Banjur, nalika siswa teka ing Google Summer of Code, kita bakal nambahake menyang proyek kasebut supaya luwih akeh karya kanggo entuk luwih akeh.
Lan pitakonan kapindho. Ana masalah ing GitHub. Aku iki wis ditutup. Ana gupuh sak mulihake. Lan kanggo ngalahake, sampeyan nggawe perakitan sing kapisah. Iku bener ing masalah. Lan ana pilihan kanggo nindakake lingkungan variabel ing siji thread. Lan mulane kerjane alon banget. Lan kita nemoni masalah iki, lan durung dirampungake.
Masalah iku sakperangan alesan panyimpenan (CEPH) ngreset sambungan nalika kita teka karo concurrency dhuwur. Apa sing bisa ditindakake babagan iki? Logika coba maneh katon kaya iki. Kita nyoba ndownload file kasebut maneh. Ing siji pass, kita duwe sawetara file sing ora diundhuh, kita bakal nggawe nomer loro kanggo kabeh sing ora mlebu. Lan anggere paling ora siji file dimuat saben pengulangan, kita mbaleni lan mbaleni lan mbaleni. Kita nambah logika nyoba maneh - backoff eksponensial. Nanging ora sakabehe jelas apa sing kudu ditindakake yen sambungan kasebut mung rusak ing sisih sistem panyimpenan. Tegese, nalika kita upload menyang siji stream, iku ora break sambungan iki. Apa sing bisa kita tambah ing kene? Kita duwe throttling jaringan, kita bisa mbatesi saben sambungan kanthi jumlah bita sing dikirim. Yen ora, aku ora ngerti carane menehi hasil karo kasunyatan sing panyimpenan obyek ora ngidini kita kanggo ngundhuh utawa ngundhuh saka ing podo karo.
Ora SLA? Apa ora ditulis kanggo wong-wong mau carane ngidini awake dhewe disiksa?
Intine wong sing teka karo pitakonan iki biasane duwe brankas dhewe. Tegese, ora ana sing teka saka Amazon utawa Google Cloud, utawa Panyimpenan Obyek Yandex.
Mungkin pitakonan wis ora kanggo sampeyan?
Pitakonan kene ing kasus iki ora Matter kanggo sapa. Menawi wonten pamanggih kados pundi caranipun, ayo ditindakaken wonten ing WAL-G. Nanging nganti saiki aku ora duwe ide sing apik babagan cara ngatasi iki. Ana sawetara Obyek Storage sing ndhukung listing serep beda. Sampeyan takon wong-wong mau kanggo dhaptar obyek, lan padha nambah folder ana. WAL-G wedi banget - ana sawetara perkara ing kene sing dudu file, aku ora bisa mulihake, tegese serep ora dibalekake. Sing, ing kasunyatan, sampeyan duwe kluster rampung dibalèkaké, nanging bali sampeyan status salah amarga Obyek Storage bali sawetara informasi aneh sing durung ngerti.
Iki kedadeyan ing awan Mail.
Yen sampeyan bisa nggawe reproduksi ...
Iku kanthi konsisten direproduksi ...
Yen ana reproduksi, mula aku bakal nyoba strategi nyoba maneh lan ngerti carane nyoba maneh lan ngerti apa sing dibutuhake awan saka kita. Mungkin bakal stabil kanggo kita ing telung sambungan lan ora bakal ngilangi sambungan kasebut, mula kita bakal tekan telu kanthi ati-ati. Amarga saiki kita ngeculake sambungan kanthi cepet, yaiku yen kita ngluncurake pemulihan kanthi 16 utas, banjur sawise nyoba maneh pisanan bakal ana 8 utas, 4 utas, 2 utas lan siji. Lan banjur bakal narik file menyang siji stream. Yen ana sawetara nilai tenung kaya 7,5 Utas sing paling apik kanggo ngompa, banjur kita bakal linger ing lan nyoba kanggo nggawe liyane 7,5 Utas. Punika ide.
Matur nuwun kanggo laporan! Kaya apa alur kerja lengkap kanggo nggarap WAL-G? Contone, ing kasus bodho nalika ora ana delta ing kaca. Lan kita njupuk lan mbusak serep dhisikan, banjur arsip poros nganti kita biru ing pasuryan. Ing kene, aku ngerti, ana risak. Ing sawetara titik sampeyan kudu nggawe serep delta kaca, yaiku sawetara proses eksternal nyopir iki utawa kepiye kedadeyan kasebut?
API serep delta cukup prasaja. Ana nomer ana - langkah delta max, sing diarani. Iku standar kanggo nul. Iki tegese saben-saben sampeyan nindakake serep-push, download serep lengkap. Yen sampeyan ngganti menyang sembarang nomer positif, contone, 3, banjur ing wektu sabanjuré sampeyan nggawe serep-push, iku katon ing sajarah serep sadurungé. Dheweke ndeleng sing ora ngluwihi chain 3 delta lan ndadekake delta.
Sing, saben-saben kita miwiti WAL-G, iku nyoba kanggo nggawe serep lengkap?
Ora, kita mbukak WAL-G, lan nyoba kanggo nggawe delta yen kawicaksanan ngidini.
Secara kasar, yen sampeyan mbukak kanthi nol saben wektu, apa bakal tumindak kaya pg_basebackup?
Ora, isih bakal mlaku luwih cepet amarga nggunakake kompresi lan paralelisme. Pg_basebackup bakal nyelehake poros ing jejere sampeyan. WAL-G nganggep yen sampeyan wis ngatur arsip. Lan bakal ngetokake bebaya yen ora dikonfigurasi.
Pg_basebackup bisa mbukak tanpa shafts.
Ya, banjur padha bakal tumindak meh padha. Pg_basebackup salinan menyang sistem file. Miturut cara, kita duwe fitur anyar sing aku kelalen kanggo sebutno. Saiki kita bisa nggawe serep menyang sistem file saka pg_basebackup. Aku ora ngerti kenapa iki dibutuhake, nanging ana.
Contone, ing CephFS. Ora saben wong pengin ngatur Panyimpenan Obyek.
Ya, mulane dheweke takon babagan fitur iki supaya kita bisa nindakake. Lan kita nindakake.
Matur nuwun kanggo laporan! Mung ana pitakonan babagan nyalin menyang sistem file. Out of the box, apa sampeyan saiki ndhukung nyalin menyang panyimpenan remot, contone, yen ana sawetara rak ing pusat data utawa liya?
Ing formulasi iki, iki minangka pitakonan sing angel. Ya, kita ndhukung, nanging fungsi iki durung kalebu ing release sembarang. Yaiku, kabeh pra-rilis ndhukung iki, nanging versi rilis ora. Fungsi iki ditambahake ing versi 0.2. Iku mesthi bakal dirilis rauh, sanalika kita ndandani kabeh kewan omo sing dikenal. Nanging saiki iki mung bisa ditindakake ing pre-release. Ana rong kewan omo ing pre-release. Masalah karo Recovery WAL-E, kita durung ndandani. Lan ing pre-release paling anyar bug babagan delta-backup ditambahake. Mulane, disaranake kabeh wong nggunakake versi rilis. Sanalika ora ana kewan omo maneh ing pra-rilis, kita bisa ujar manawa ndhukung Google Cloud, barang sing kompatibel karo S3 lan panyimpenan file.
Halo, matur nuwun kanggo laporan. Nalika aku ngerti, WAL-G dudu sistem terpusat kaya barmen? Apa sampeyan rencana pindhah menyang arah iki?
Masalahe yaiku kita wis pindhah saka arah iki. WAL-G manggon ing host basa, ing host kluster, lan ing kabeh host ing kluster. Nalika kita pindhah menyang sawetara ewu kluster, kita wis akeh instalasi bartender. Lan saben-saben ana sing rusak, dadi masalah gedhe. Amarga kudu didandani, sampeyan kudu ngerti klompok sing saiki ora duwe serep. Aku ora rencana ngembangaken WAL-G ing arah hardware fisik kanggo sistem serep. Yen komunitas pengin sawetara fungsi ing kene, aku ora keberatan.
Kita duwe tim sing tanggung jawab kanggo panyimpenan. Lan kita aran apik banget sing ora kita, sing ana wong khusus sing sijine file kita ngendi file sing aman. Dheweke nindakake macem-macem coding sing cerdas ing kana kanggo nahan mundhut file tartamtu. Dheweke tanggung jawab kanggo bandwidth jaringan. Yen sampeyan duwe bartender, sampeyan bisa uga ngerteni manawa database cilik kanthi lalu lintas akeh wis kumpul ing server sing padha. Sampeyan koyone duwe akeh papan ing, nanging sakperangan alesan kabeh ora pas liwat jaringan. Bisa uga dadi sebaliknya. Ana akeh jaringan ing kana, ana inti prosesor, nanging ora ana disk ing kene. Lan kita kesel iki perlu kanggo juggle soko, lan kita dipindhah menyang kasunyatan sing panyimpenan data layanan kapisah, kang wong khusus kapisah tanggung jawab.
P.S Versi anyar wis dirilis , ing ngendi sampeyan bisa nggunakake file konfigurasi .walg.json, sing dumunung ing direktori ngarep postgres minangka standar. Sampeyan bisa ninggalake skrip bash. Conto .walg.json ana ing masalah iki
Video:
Source: www.habr.com