Abdi nyarankeun anjeun maca transkrip laporan ti mimiti 2019 ku Andrey Borodin "Nyadangkeun sareng WAL-G. Aya naon di 2019?"
Halo sadayana! Nami abdi Andrey Borodin. Abdi pamekar di Yandex. Kuring geus kabetot dina PostgreSQL saprak 2016, sanggeus kuring dikaitkeun kana pamekar jeung maranéhna ngomong yén sagalana geus basajan - Anjeun nyandak kodeu sumber sarta ngawangun eta, sarta sagalana bakal jalan kaluar. Sarta saprak harita kuring teu bisa eureun - Kuring nulis sagala sorts hal béda.
Salah sahiji hal anu kuring dianggo nyaéta sistem cadangan. . Sacara umum, di Yandex kami parantos ngusahakeun sistem cadangan dina PostgreSQL kanggo waktos anu lami pisan. Tur anjeun tiasa manggihan dina Internet runtuyan genep laporan ngeunaan kumaha urang nyieun sistem cadangan. Sareng unggal taun aranjeunna mekar sakedik, ngembangkeun sakedik, sareng janten langkung dipercaya.
Tapi ayeuna laporan éta henteu ngan ukur ngeunaan naon anu urang laksanakeun, tapi ogé ngeunaan kumaha saderhana sareng naon éta. Sakumaha seueur anjeun anu parantos ningali laporan kuring ngeunaan WAL-G? Ieu alus nu rada sababaraha urang teu lalajo, sabab kuring bakal mimitian ku hal basajan.
Upami ujug-ujug anjeun gaduh klaster PostgreSQL, sareng kuring nyangka sadayana gaduh sababaraha aranjeunna sareng aranjeunna, sareng ujug-ujug teu acan aya sistem cadangan, maka anjeun kedah kéngingkeun panyimpen S3 atanapi panyimpenan anu cocog sareng Google Cloud.
Salaku conto, anjeun tiasa sumping ka stand kami sareng nyandak kode promosi pikeun Panyimpenan Objék Yandex, anu cocog sareng S3.
Teras jieun Ember. Éta ngan ukur wadah inpormasi.
Jieun pamaké jasa.
Jieun konci aksés pikeun pamaké jasa: aws-s3-key.
Unduh sékrési stabil panganyarna tina WAL-G.
Kumaha pra-kaluaran urang béda ti sékrési? Abdi sering dipenta pikeun ngaleupaskeun awal. Sareng upami teu aya bug dina versi pikeun waktos anu cekap, contona, sabulan, teras kuring ngaleupaskeun. Ieu pelepasan ieu ti Nopémber. Ieu ngandung harti yén unggal bulan urang kapanggih sababaraha jenis bug, biasana dina fungsionalitas non-kritis, tapi urang teu acan ngarilis release a. Versi saméméhna ngan November. Henteu aya kutu anu dipikanyaho ku urang di jerona, nyaéta kutu-kutu anu ditambahkeun nalika proyékna maju.
Saatos diunduh WAL-G, anjeun tiasa ngajalankeun paréntah "daftar cadangan" anu saderhana, ngalangkungan variabel lingkungan. Sarta eta bakal nyambung ka Panyimpenan Objék sarta ngabejaan Anjeun naon cadangan anjeun gaduh. Mimitina, tangtosna, anjeun henteu kedah gaduh cadangan. Titik slide ieu nunjukkeun yén sadayana saderhana. Ieu paréntah konsol nu narima variabel lingkungan jeung executes subcommands.
Sanggeus ieu, anjeun bisa nyieun cadangan munggaran anjeun. Sebutkeun "cadangan-push" dina WAL-G sareng sebutkeun dina WAL-G lokasi pgdata klaster anjeun. Sareng paling dipikaresep, PostgreSQL bakal nyarioskeun ka anjeun, upami anjeun teu acan gaduh sistem cadangan, anjeun kedah ngaktipkeun "mode arsip".
Ieu ngandung harti yén anjeun kedah lebet kana setélan sareng hurungkeun "archive_mode = on" sareng tambahkeun "archive_command", anu ogé mangrupikeun subcommand dina WAL-G. Tapi pikeun sababaraha alesan jalma sering ngagunakeun skrip bar dina topik ieu sareng dibungkus kana WAL-G. Punten ulah ngalakukeun ieu. Paké fungsionalitas kapanggih dina WAL-G. Mun anjeun leungit hal, nulis ka . WAL-G nganggap yén éta hiji-hijina program anu dijalankeun dina archive_command.
Kami nganggo WAL-G utamina pikeun nyiptakeun klaster Kasadiaan Tinggi dina manajemén Database Yandex.
Sareng biasana dianggo dina topologi hiji Master sareng sababaraha réplikasi. Dina waktos anu sami, éta ngadamel salinan cadangan dina Panyimpenan Obyék Yandex.
Skenario anu paling umum nyaéta nyiptakeun salinan klaster nganggo Point dina waktos pamulihan. Tapi dina hal ieu, kinerja sistem cadangan teu jadi penting pikeun urang. Urang ngan perlu unggah klaster anyar tina cadangan.
Ilaharna, urang peryogi kinerja sistem cadangan nalika nambahkeun titik anyar. Naha éta penting? Biasana jalma nambihan titik énggal kana klaster sabab klaster anu tos aya henteu tiasa ngadamel beban baca. Aranjeunna kedah nambihan réplika énggal. Upami urang nambihan beban tina pg_basebackup ka Master, maka Master tiasa ambruk. Ku sabab éta, penting pisan pikeun urang yén urang tiasa gancang unggah titik énggal tina arsip, nyiptakeun beban minimal dina Master.
Jeung kaayaan sejen sarupa. Ieu mangrupikeun kabutuhan pikeun ngamimitian deui Master anu lami saatos ngalihkeun Master Kluster ti Pusat Data dimana konektipitasna leungit.
- Hasilna, nalika ngarumuskeun sarat pikeun sistem salinan, urang sadar yén pg_basebackup teu cocog pikeun urang nalika operasi di awan.
- Urang hayang bisa niiskeun data urang. Tapi ampir sagala sistem cadangan lian ti naon asalna dina kotak bakal nyadiakeun komprési data.
- Urang hayang parallelize sagalana sabab pamaké dina awan mundut sajumlah badag cores processor. Tapi lamun urang teu boga paralelisme dina sababaraha operasi, angka nu gede ngarupakeun cores janten gunana.
- Urang peryogi énkripsi sabab sering datana sanés milik urang sareng teu tiasa disimpen dina téks anu jelas. Ku jalan kitu, kontribusi kami ka WAL-G dimimitian ku enkripsi. Kami parantos réngsé enkripsi dina WAL-G, saatos kami ditaros: "Panginten salah sahiji urang bakal ngembangkeun proyék éta?" Sareng ti saprak éta kuring parantos damel sareng WAL-G langkung ti sataun.
- Kami ogé peryogi throttling sumberdaya, sabab kana waktosna nganggo awan, kami mendakan yén kadang-kadang jalma ngagaduhan beban grosir anu penting dina wengi sareng beban ieu teu tiasa diganggu. Éta pisan sababna naha urang ditambahkeun throttling sumberdaya.
- Kitu ogé daptar sareng manajemén.
- Jeung verifikasi.
Urang nempo loba alat béda. Kabeneran, urang gaduh pilihan anu ageung dina PostgreSQL. Sareng dimana-mana urang leungit hiji hal, sababaraha hiji fungsi leutik, sababaraha hiji fitur leutik.
Sareng saatos nalungtik sistem anu aya, kami dugi ka kacindekan yén kami bakal ngembangkeun WAL-G. Éta mangrupikeun proyék énggal. Éta gampang pisan pikeun mangaruhan pangwangunan kana infrastruktur awan tina sistem cadangan.
Ideologi anu utama anu ku urang dianut nyaéta WAL-G kedah basajan sapertos balalaika.
WAL-G gaduh 4 paréntah. Ieu:
WAL-PUSH - arsipkeun aci.
WAL-FETCH - meunang aci.
BACKUP-PUSH - nyieun cadangan.
BACKUP-FETCH - kéngingkeun cadangan tina sistem cadangan.
Nyatana, WAL-G ogé gaduh manajemén cadangan ieu, nyaéta daptar sareng mupus rékaman sareng cadangan dina sajarah anu henteu diperyogikeun deui ayeuna.
Salah sahiji fungsi anu penting pikeun urang nyaéta fungsi nyiptakeun salinan délta.
Salinan Delta hartina urang teu nyieun cadangan pinuh ku sakabéh klaster, tapi ngan kaca robah tina file robah dina klaster. Ieu bakal sigana nu functionally ieu pisan sarupa kamampuhan pikeun cageur maké WAL. Tapi urang tiasa ngagulung cadangan délta single-threaded WAL paralel. Sasuai, nalika urang boga cadangan dasar dijieun dina Sabtu, délta cadangan poean, sarta dina Kemis urang gagal, lajeng urang kudu gulung nepi 4 delta cadangan tur 10 jam WAL. Bakal butuh waktu nu sarua sabab cadangan délta gulung dina paralel.
Déltas basis LSN - ieu ngandung harti yén nalika nyieun cadangan, urang kudu ngagabungkeun unggal kaca jeung pariksa LSN na jeung LSN tina cadangan saméméhna pikeun ngarti yén éta geus robah. Halaman naon waé anu berpotensi ngandung data anu dirobih kedah aya dina cadangan délta.
Salaku Cenah mah, rada loba perhatian ieu dibayar ka paralelisme.
Tapi API arsip di PostgreSQL konsisten. PostgreSQL ngarsipkeun hiji file WAL sareng nalika malikkeun éta menta hiji file WAL. Tapi lamun database requests hiji file WAL ngagunakeun paréntah "WAL-FETCH", urang nelepon paréntah "WAL-PREFETCH", nu prepares salajengna 8 file pikeun dipulut data ti toko objék dina paralel.
Sareng nalika pangkalan data naroskeun ka arsip hiji file, urang tingali dina archive_status sareng ningali naha aya file WAL anu sanés. Sareng kami ogé nyobian ngaunduh WAL paralel. Ieu nyadiakeun gain kinerja signifikan sarta nyata ngurangan jarak dina jumlah WAL unarchived. Seueur pamekar sistem cadangan yakin yén ieu mangrupikeun sistem anu picilakaeun sabab urang ngandelkeun pangaweruh urang ngeunaan kode internal anu sanés PostgreSQL API. PostgreSQL henteu ngajamin ayana folder archive_status pikeun urang sareng henteu ngajamin semantik, ayana sinyal kesiapan pikeun file WAL di dinya. Nanging, urang nuju diajar kode sumber, urang ningali yén éta leres sareng urang nyobian ngamangpaatkeunana. Sareng urang ngontrol arah anu dikembangkeun PostgreSQL; upami ujug-ujug mékanisme ieu rusak, urang bakal ngeureunkeun ngagunakeunana.
Dina bentuk murni, WAL délta basis LSN merlukeun maca sagala file klaster anu mode-waktos dina sistem file geus robah ti cadangan saméméhna. Urang cicing jeung ieu keur lila, ampir sataun. Sarta dina tungtungna urang sumping ka kacindekan yen urang boga deltas Wal.
Ieu ngandung harti yén unggal waktos urang arsip WAL on Master, urang teu ngan niiskeun eta, encrypt eta sarta ngirimkeunana ka jaringan, tapi urang ogé maca eta dina waktos anu sareng. Urang nganalisis jeung maca rékaman di dinya. Urang ngarti mana blok geus robah sarta ngumpulkeun file délta.
File délta ngajelaskeun sajumlah file WAL, ngajelaskeun inpormasi ngeunaan blok mana anu dirobih dina rentang WAL ieu. Teras file délta ieu ogé diarsipkeun.
Di dieu urang Nyanghareupan kanyataan yén urang parallelized sagalana rada gancang, tapi urang teu bisa maca sajarah sequential di paralel, sabab dina bagean nu tangtu urang bisa sapatemon tungtung catetan WAL saméméhna, nu urang teu boga nanaon pikeun nyambungkeun, sabab. bacaan paralel ngarah ka urang mimiti analisa mangsa nu bakal datang, nu teu acan boga kaliwat.
Hasilna, urang kedah nempatkeun potongan anu teu kaharti kana file _delta_partial. Hasilna, nalika urang balik deui ka jaman baheula, urang bakal lem potongan-potongan catetan WAL kana hiji, sanggeus éta kami bakal parse tur ngartos naon robah di dinya.
Upami dina sajarah parsing aci urang sahenteuna aya hiji titik dimana urang henteu ngartos naon anu kajantenan, maka, sasuai, salami cadangan salajengna urang bakal kapaksa maca sadayana klaster deui, sapertos anu urang lakukeun ku LSN biasa. -basis délta.
Hasilna, sadaya kasangsaraan urang nyababkeun kanyataan yén urang muka-sumber perpustakaan parsing WAL-G. Sajauh anu kuring terang, teu acan aya anu nganggo, tapi upami aya anu hoyong, nyerat sareng dianggo, éta dina domain umum. (Tumbu anu diropéa )
Hasilna, sadaya aliran inpormasi katingalina rada rumit. Master kami arsipkeun aci sareng arsip file délta. Sareng réplika anu ngadamel salinan cadangan kedah nampi file délta salami waktos anu parantos aya antara cadangan. Dina hal ieu, bagian tina sajarah bakal perlu ditambahkeun dina bulk na parsed, sabab teu sakabeh sajarah fits kana bagéan badag. Sareng saatos ieu réplika tiasa ngarsipkeun cadangan délta pinuh.
Dina grafik sagalana Sigana leuwih basajan. Ieu mangrupikeun unduhan tina salah sahiji klaster nyata kami. Kami ngagaduhan basis LSN, dilakukeun dina hiji dinten. Sarta kami ningali yén cadangan délta basis LSN ieu ngajalankeun ti tilu isuk-isuk nepi ka lima isuk-isuk. Ieu beban dina jumlah cores processor. WAL-délta nyandak urang ngeunaan menit 20. Hartina, eta janten nyata gancang, tapi di waktu nu sami aya bursa leuwih sengit ngaliwatan jaringan.
Kusabab kami gaduh inpormasi ngeunaan blok mana anu dirobih sareng iraha waktos dina sajarah pangkalan data, kami langkung jauh sareng mutuskeun pikeun ngahijikeun fungsionalitas - extension PostgreSQL anu disebut "pg_prefaulter"
Ieu ngandung harti yén nalika stand-by base executes paréntah balikkeun, éta ngabejaan WAL-G pikeun dipulut file WAL salajengna. Urang ngarti kira-kira data mana anu ngahalangan prosés pamulihan WAL anu bakal diaksés dina waktos anu caket sareng ngamimitian operasi anu dibaca dina blok ieu. Hal ieu dilakukeun dina raraga ngaronjatkeun kinerja controller SSD. Kusabab roll WAL bakal ngahontal kaca nu kudu dirobah. Kaca ieu aya dina disk sareng henteu aya dina cache halaman. Sarta anjeunna bakal antosan synchronously pikeun kaca ieu anjog. Tapi caket dieu nyaéta WAL-G, anu terang yén dina sababaraha ratus megabyte WAL salajengna urang peryogi halaman-halaman anu tangtu sareng dina waktos anu sami mimiti ngamanaskeunana. Inisiasi sababaraha aksés disk ambéh maranéhanana dieksekusi paralel. Ieu tiasa dianggo saé dina drive SSD, tapi, hanjakalna, éta leres-leres henteu tiasa dianggo pikeun hard drive, sabab urang ngan ukur ngaganggu kana paréntah kami.
Ieu naon dina kode ayeuna.
Aya fitur anu urang hoyong tambahkeun.
Gambar ieu nunjukkeun yén WAL-delta butuh waktos anu pondok. Sareng ieu maca parobihan anu kajantenan dina pangkalan data siang. Urang bisa ngalakukeun WAL-delta teu ngan peuting, sabab geus euweuh sumber signifikan beban. Urang bisa maca WAL-delta unggal menit sabab éta mirah. Dina hiji menit urang tiasa nyeken sagala parobahan anu lumangsung dina klaster. Sarta ieu bisa disebut "instan WAL-delta".
Intina nyaéta nalika urang mulangkeun kluster, urang ngirangan jumlah carita anu kedah urang gulung sacara berurutan. Hartina, jumlah WAL nu PostgreSQL gulungan kudu ngurangan, sabab butuh waktu signifikan.
Tapi éta henteu sadayana. Upami urang terang yén sababaraha blok bakal dirobih kana konsistensi cadangan, urang moal tiasa ngarobih éta dina jaman baheula. Nyaéta, ayeuna urang gaduh optimasi file-demi-file tina WAL-delta diteruskeun. Ieu ngandung harti yén lamun, contona, dina Salasa hiji méja lengkep dihapus atawa sababaraha file dihapus sagemblengna tina tabél, lajeng nalika délta gulung dina Senén jeung Sabtu pg_basebackup disimpen, urang malah moal nyieun data ieu.
Kami hoyong manjangkeun téknologi ieu ka tingkat halaman. Nyaéta, upami sababaraha bagian tina file robih dina Senén, tapi bakal ditindih dinten Rebo, teras nalika mulangkeun ka titik dina Kemis, urang henteu kedah nyerat sababaraha versi halaman munggaran kana disk.
Tapi ieu téh masih mangrupa gagasan anu keur aktip dibahas dina urang, tapi teu acan ngahontal kode.
Kami hoyong ngadamel hiji deui fitur dina WAL-G. Kami hoyong ngalegaan sabab kami kedah ngadukung pangkalan data anu béda sareng hoyong tiasa ngadeukeutan manajemén cadangan dina cara anu sami. Tapi masalahna nyaéta yén API MySQL béda sacara radikal. Dina MySQL, PITR henteu dumasar kana log WAL fisik, tapi dina binlog. Sarta kami teu boga sistem archiving di MySQL nu bakal ngabejaan sababaraha sistem éksternal anu binlog ieu réngsé sarta perlu diarsipkeun. Urang kudu nangtung wae di cron jeung database jeung pariksa lamun aya hal siap?
Sareng dina cara anu sami, salami pamulihan MySQL, teu aya paréntah pamulihan anu tiasa nyarioskeun sistem yén kuring peryogi file sapertos kitu. Sateuacan anjeun ngamimitian ngawangun deui kluster anjeun, anjeun kedah terang file naon anu anjeun peryogikeun. Anjeun sorangan kedah nebak file naon anu anjeun peryogikeun. Tapi masalah ieu bisa jadi bisa circumvented kumaha bae. (Klarifikasi: MySQL parantos dirojong)
Dina laporan éta, kuring ogé hoyong ngobrol ngeunaan kasus éta nalika WAL-G henteu cocog pikeun anjeun.
Upami anjeun teu gaduh réplika sinkron, WAL-G henteu ngajamin yén bagéan anu terakhir bakal dilestarikan. Tur upami archiving lags balik sababaraha bagéan panungtungan sajarah, éta resiko. Upami teu aya réplika sinkron, kuring henteu nyarankeun ngagunakeun WAL-G. Masih, éta utamana dirancang pikeun instalasi awan, nu ngakibatkeun solusi Kasadiaan High kalawan replica sinkron, nu jawab kasalametan bait panungtungan komitmen.
Kuring sering ningali jalma nyobian ngajalankeun WAL-G sareng WAL-E dina waktos anu sami. Kami ngadukung kasaluyuan mundur dina harti yén WAL-G tiasa mulangkeun file tina WAL-E sareng tiasa mulangkeun cadangan anu dilakukeun dina WAL-E. Tapi saprak duanana sistem ieu ngagunakeun paralel wal-push, aranjeunna mimiti maok file ti silih. Lamun urang ngalereskeun eta dina WAL-G, éta bakal tetep dina WAL-E. Dina WAL-E, eta Sigana di arsip-status, ningali file rengse tur arsip aranjeunna, bari sistem sejenna saukur moal nyaho yén file WAL ieu aya, sabab PostgreSQL moal nyobian arsip kadua kalina.
Naon anu urang badé ngalereskeun di dieu di sisi WAL-G? Kami moal nginpokeun ka PostgreSQL yén file ieu ditransfer paralel, sareng nalika PostgreSQL naroskeun kami pikeun ngarsipkeunana, kami bakal terang yén file sapertos kieu sareng mode-waktos ieu sareng md5 ieu parantos diarsipkeun sareng urang ngan saukur bakal nyarios PostgreSQL - OKÉ, sagalana geus siap tanpa dasarna ngalakukeun nanaon.
Tapi masalah ieu saperti teu mirip dibereskeun di sisi WAL-E, jadi ayeuna teu mungkin keur nyieun hiji paréntah arsip nu bakal arsip file dina duanana WAL-G jeung WAL-E.
Salaku tambahan, aya kasus dimana WAL-G henteu cocog pikeun anjeun ayeuna, tapi kami pasti bakal ngalereskeunana.
Anu mimiti, urang ayeuna teu gaduh verifikasi cadangan anu diwangun. Urang teu boga verifikasi boh salila cadangan atawa recovery. Tangtu, ieu dilaksanakeun dina awan. Tapi ieu dilaksanakeun saukur ku pre-mariksa, cukup ku mulangkeun klaster. Abdi hoyong masihan fungsionalitas ieu ka pangguna. Tapi ku verifikasi, Kuring nganggap yén dina WAL-G bakal mungkin mulangkeun klaster tur mimitian eta, tur ngajalankeun tés haseup: pg_dumpall ka / dev / null sarta verifikasi indéks amcheck.
Ayeuna di WAL-G teu aya cara pikeun nunda hiji cadangan ti WAL. Hartina, urang ngarojong sababaraha jandela. Contona, nyimpen tujuh poe panungtungan, nyimpen sapuluh cadangan panungtungan, nyimpen tilu panungtungan cadangan pinuh. Sering pisan jalma-jalma datang sareng nyarios: "Kami peryogi cadangan naon anu kajantenan dina Taun Anyar sareng kami hoyong tetep salamina." WAL-G henteu acan terang kumaha ngalakukeun ieu. (Catetan - Ieu parantos dilereskeun. Baca deui - Pilihan cadangan-tanda di )
Sarta kami teu boga kaca checksums na cék integritas pikeun sakabéh bagéan aci nalika validating PITR.
Ti sadayana ieu kuring nunda babarengan hiji proyék pikeun Google Summer of Code. Upami anjeun terang murid pinter anu hoyong nyerat hiji hal di Go sareng kéngingkeun sababaraha rébu dolar ti hiji perusahaan kalayan hurup "G", teras nyarankeun proyék kami ka aranjeunna. Kuring bakal meta salaku mentor pikeun proyék ieu, aranjeunna tiasa ngalakukeun eta. Upami teu aya murid, maka kuring bakal nyandak sareng ngalakukeunana sorangan dina usum panas.
Sarta kami boga loba masalah leutik lianna nu urang laun digarap. Jeung sababaraha hal geulis aneh kajadian.
Salaku conto, upami anjeun masihan WAL-G cadangan kosong, éta ngan saukur ragrag. Salaku conto, upami anjeun nyarioskeun yén anjeunna kedah nyadangkeun polder kosong. File pg_control moal aya. Sarta anjeunna bakal mikir yén anjeunna teu ngartos hal. Dina tiori, dina hal ieu anjeun kudu nulis pesen normal ka pamaké pikeun ngajelaskeun ka anjeunna kumaha ngagunakeun alat. Tapi ieu sanés mangrupikeun fitur program, tapi fitur anu saé, basa anu kaharti.
Kami henteu terang kumaha ngalakukeun cadangan offline. Upami pangkalan data bohong, urang moal tiasa nyadangkeunana. Tapi sagalana basajan pisan di dieu. Urang nelepon cadangan ku LSN nalika dimimitian. LSN tina dasar dasarna kedah dibaca tina file kontrol. Sareng ieu mangrupikeun fitur anu teu direalisasikeun. Seueur sistem cadangan tiasa nyadangkeun pangkalan data dasar. Tur éta merenah.
Urang ayeuna teu bisa nanganan kurangna spasi cadangan leres. Kusabab urang biasana damel sareng cadangan ageung di bumi. Jeung maranéhna teu meunang sabudeureun eta. Tapi upami aya anu hoyong program di Go ayeuna, tambahkeun penanganan kasalahan di luar rohangan kana ember. Kuring pasti bakal ningali kana pamundut tarik.
Jeung hal utama nu worries kami nyaeta urang hoyong saloba tés integrasi docker sabisa anu pariksa skenario béda. Ayeuna kami ngan ukur nguji skenario dasar. Dina unggal commit, tapi kami hoyong pariksa commit-by-commit sadaya fungsionalitas anu kami dukung. Khususna, contona, urang bakal gaduh dukungan anu cukup pikeun PostgreSQL 9.4-9.5. Kami ngadukung aranjeunna kusabab komunitas ngadukung PostgreSQL, tapi kami henteu pariksa commit-by-commit pikeun mastikeun yén sadayana henteu rusak. Sareng sigana kuring yén ieu mangrupikeun résiko anu rada serius.
Kami ngagaduhan WAL-G dina langkung ti sarébu klaster dina manajemén Database Yandex. Sareng nyadangkeun sababaraha ratus terabytes data unggal dinten.
Kami ngagaduhan seueur TODO dina kode kami. Upami anjeun hoyong program, sumping, kami ngantosan pamundut tarik, kami ngantosan patarosan.
patarosan
Wilujeng sonten! Hatur nuhun! Dugaan kuring nyaéta yén upami anjeun nganggo WAL-delta, anjeun sigana ngandelkeun pisan kana tulisan halaman pinuh. Sareng upami kitu, naha anjeun ngajalankeun tés? Anjeun nunjukkeun grafik anu saé. Sakumaha langkung geulis upami FPW dipareuman?
Tulisan halaman pinuh diaktipkeun pikeun kami, kami henteu acan nyobian nganonaktipkeun. Hartina, kuring salaku pamekar, teu acan nyobian mareuman. Administrator sistem anu parantos naliti sigana parantos nalungtik masalah ieu. Tapi urang peryogi FPW. Ampir teu aya anu nganonaktipkeun, sabab upami henteu mustahil nyandak cadangan tina réplika.
Hatur nuhun laporan! Abdi gaduh dua patarosan. Patarosan kahiji nyaeta naon anu bakal kajadian ka tablespaces?
Kami ngantosan pamundut tarik. Pangkalan data kami hirup dina disk SSD sareng NMVE sareng kami henteu peryogi pisan fitur ieu. Abdi henteu siap nyéépkeun waktos anu serius ayeuna pikeun ngalakukeunana saé. Kuring wholeheartedly ngajengkeun yén urang ngarojong ieu. Aya jalma anu ngadukung, tapi ngadukung ku cara anu cocog sareng aranjeunna. Aranjeunna nyieun garpu, tapi maranéhna teu nyieun requests tarikan. (Ditambahkeun dina versi 0.2.13)
Jeung patarosan kadua. Anjeun nyarios di awal yén WAL-G nganggap yén éta tiasa dianggo nyalira sareng teu aya bungkus anu diperyogikeun. Kuring make wrappers sorangan. Naha aranjeunna henteu kedah dianggo?
Simkuring hoyong janten basajan sakumaha balalaika a. Ieu ngandung harti yén anjeun teu butuh nanaon iwal balalaika a. Simkuring hoyong sistem janten basajan. Upami anjeun ngagaduhan fungsionalitas anu anjeun kedah laksanakeun dina naskah, teras sumping sareng béjakeun ka kami - kami bakal ngalakukeun éta di Go.
Wilujeng sonten! Hatur nuhun laporan! Kami henteu tiasa kéngingkeun WAL-G damel sareng dekripsi GPG. Ieu encrypts normal, tapi teu hayang ngadekrip. Naha éta hal anu henteu hasil pikeun urang? kaayaan keur depresi.
Jieun masalah dina GitHub sareng hayu urang terangkeun.
Nyaéta, anjeun henteu acan mendakan ieu?
Aya fitur laporan kasalahan yén nalika WAL-G henteu ngartos jenis file éta, éta naros: "Panginten énkripsi?" Panginten masalahna sanés énkripsi. Abdi hoyong ningkatkeun logging dina topik ieu. Anjeunna kedah decipher eta. Kami ayeuna nuju ngerjakeun topik ieu dina harti yén kami henteu resep kumaha sistem pikeun kéngingkeun konci umum sareng swasta diatur. Kusabab urang nyauran GPG éksternal supados masihan kami konci na. Teras we nyandak konci ieu sareng mindahkeun kana GPG internal, nyaéta PGP kabuka, anu disusun pikeun urang di jero WAL-G, sareng di dinya urang nyauran enkripsi. Dina hal ieu, urang hoyong ningkatkeun sistem sareng hoyong ngadukung enkripsi Libsodium (Ditambahkeun dina versi 0.2.15). Tangtosna, decoding kedah dianggo, hayu urang terangkeun - anjeun peryogi langkung seueur gejala tibatan sababaraha kecap. Anjeun tiasa ngumpul di kamar spiker urang sometime jeung kasampak di sistem. (Enkripsi PGP tanpa GPG éksternal - v0.2.9)
Halo! Hatur nuhun laporan! Abdi gaduh dua patarosan. Kuring boga kahayang aneh mun ngalakukeun pg_basebackup na WAL asup dua panyadia, ie Abdi hoyong ngalakukeun hiji awan sarta séjén. Aya sababaraha cara pikeun ngalakukeun ieu?
Ieu teu aya ayeuna, tapi mangrupa gagasan metot.
Kuring ngan teu percanten ka hiji panyadia, abdi hoyong gaduh sami di sejen, bisi wae.
Ide ieu metot. Téhnisna, ieu teu pisan hésé pikeun nerapkeun. Pikeun nyegah ideu leungit, naha kuring tiasa naroskeun anjeun ngadamel masalah dina GitHub?
Leres tangtosna.
Teras, nalika murid sumping ka Google Summer of Code, kami bakal nambihanana kana proyék supados langkung seueur padamelan pikeun langkung seueur.
Jeung patarosan kadua. Aya masalah dina GitHub. Jigana éta geus ditutup. Aya panik salila mulangkeun. Sareng pikeun ngelehkeunana, anjeun ngadamel rakitan anu misah. Éta leres dina masalah. Sareng aya pilihan pikeun ngalakukeun lingkungan variabel dina hiji benang. Sareng éta sababna jalanna laun pisan. Sarta kami encountered masalah ieu, sarta eta teu acan dibereskeun.
Masalahna nyaeta pikeun sababaraha alesan gudang (CEPH) ngareset sambungan nalika urang datang ka dinya kalawan concurrency tinggi. Naon anu tiasa dilakukeun ngeunaan ieu? Logika cobian deui sapertos kieu. Kami nyobian ngaunduh file deui. Dina hiji pas, kami ngagaduhan sajumlah file anu henteu diunduh, kami bakal ngadamel anu kadua pikeun sadayana anu henteu lebet. Sarta salami sahanteuna hiji file dimuat per iteration, urang ngulang jeung ngulang jeung ngulang. Kami ningkatkeun logika coba deui - backoff eksponensial. Tapi teu sagemblengna jelas naon nu kudu jeung kanyataan yén sambungan saukur megatkeun dina sisi sistem gudang. Hartina, nalika urang unggah kana hiji aliran, éta henteu megatkeun sambungan ieu. Naon anu urang tiasa ningkatkeun di dieu? Kami gaduh jaringan throttling, urang tiasa ngawatesan unggal sambungan ku jumlah bait anu dikirimkeun. Upami teu kitu, abdi henteu terang kumaha carana nungkulan kanyataan yén gudang obyék teu ngidinan urang pikeun ngundeur atanapi ngundeur ti dinya dina paralel.
Henteu SLA? Naha henteu ditulis pikeun aranjeunna kumaha aranjeunna ngantepkeun diri disiksa?
Intina nyaeta jalma anu datang nepi ka sual ieu biasana boga kolong sorangan. Nyaéta, teu aya anu asalna ti Amazon atanapi Google Cloud, atanapi Yandex Object Storage.
Meureun patarosan geus euweuh keur anjeun?
Patarosan di dieu dina hal ieu henteu masalah ka saha. Upami aya ide kumaha cara nungkulan ieu, hayu urang lakukeun di WAL-G. Tapi sajauh ieu kuring teu boga pamanggih alus ngeunaan cara nungkulan ieu. Aya sababaraha Panyimpenan Objék anu ngadukung daptar cadangan anu béda. Anjeun naroskeun ka daptar objék, sareng aranjeunna nambihan folder di dinya. WAL-G sieun ku ieu - aya sababaraha hal di dieu anu sanés file, kuring henteu tiasa ngabalikeun deui, anu hartosna cadanganna henteu disimpen deui. Nyaéta, kanyataanna, anjeun gaduh klaster anu dipulangkeun lengkep, tapi éta ngabalikeun anjeun status anu salah sabab Panyimpenan Objék ngabalikeun sababaraha inpormasi aneh anu henteu ngartos.
Ieu mangrupikeun hal anu lumangsung dina méga Surat.
Upami anjeun tiasa ngawangun réproduksi ...
Éta sacara konsisten direproduksi ...
Upami aya réproduksi, maka kuring nyangka urang bakal ékspérimén sareng strategi coba deui sareng terang kumaha nyobian deui sareng ngartos naon anu diperyogikeun awan pikeun urang. Panginten éta bakal stabil pikeun urang dina tilu sambungan sareng moal ngalanggar sambungan, maka urang taliti bakal ngahontal tilu. Kusabab ayeuna urang leupaskeun sambungan anu gancang pisan, nyaéta upami urang ngaluncurkeun pamulihan kalayan 16 utas, maka saatos nyobian deui heula bakal aya 8 utas, 4 utas, 2 utas sareng hiji. Teras bakal narik file kana hiji aliran. Upami aya sababaraha nilai sihir sapertos 7,5 benang anu pangsaéna pikeun ngompa, maka urang bakal ngahudangkeunana sareng nyobian ngadamel 7,5 benang anu sanés. Ieu hiji gagasan.
Hatur nuhun laporan! Kumaha alur kerja lengkep pikeun gawé bareng WAL-G? Contona, dina kasus bodo lamun euweuh délta sakuliah kaca. Sareng urang nyandak sareng cabut cadangan awal, teras arsipkeun aci dugi ka biru dina raray. Di dieu, sakumaha Abdi ngartos eta, aya ngarecahna. Di sawatara titik anjeun kudu nyieun cadangan délta kaca, i.e. sababaraha prosés éksternal nyetir ieu atanapi kumaha ieu kajadian?
API cadangan délta cukup basajan. Aya jumlahna - max délta léngkah, éta naon disebutna. Ieu standar nol. Ieu ngandung harti yén unggal waktos Anjeun ngalakukeun cadangan-push, éta ngundeur cadangan pinuh. Upami anjeun ngarobih kana nomer anu positif, contona, 3, teras waktos salajengna anjeun ngalakukeun cadangan-push, éta bakal ningali sajarah cadangan sateuacana. Anjeunna ningali yén anjeun teu ngaleuwihan ranté 3 delta jeung ngajadikeun délta a.
Nyaéta, unggal waktos urang ngaluncurkeun WAL-G, éta nyobian ngadamel cadangan lengkep?
Henteu, urang ngajalankeun WAL-G, sareng éta nyobian ngadamel délta upami kawijakan anjeun ngijinkeun.
Sacara kasar, upami anjeun ngajalankeun éta kalayan nol unggal waktos, éta bakal kalakuanana sapertos pg_basebackup?
Henteu, éta bakal ngajalankeun langkung gancang sabab ngagunakeun komprési sareng paralélisme. Pg_basebackup bakal nempatkeun aci gigireun anjeun. WAL-G nganggap yén anjeun parantos ngonpigurasikeun arsip. Sareng éta bakal ngaluarkeun peringatan upami henteu dikonpigurasi.
Pg_basebackup bisa dijalankeun tanpa shafts.
Leres, teras aranjeunna bakal kalakuanana ampir sami. Pg_basebackup nyalin kana sistem file. Ku jalan kitu, urang gaduh fitur anyar anu kuring hilap disebatkeun. Urang ayeuna tiasa nyadangkeun kana sistem file tina pg_basebackup. Kuring henteu weruh naha ieu diperlukeun, tapi aya.
Contona, dina CephFS. Henteu sadayana hoyong ngonpigurasikeun Panyimpenan Objék.
Leres, éta panginten aranjeunna naroskeun patarosan ngeunaan fitur ieu supados urang tiasa ngalakukeunana. Sarta kami ngalakukeun eta.
Hatur nuhun laporan! Aya ngan patarosan ngeunaan nyalin kana sistem file. Out of the box, naha anjeun ayeuna ngadukung nyalin kana panyimpenan jauh, contona, upami aya sababaraha rak di pusat data atanapi anu sanés?
Dina rumusan ieu, ieu patarosan hésé. Leres, kami ngadukung, tapi fungsionalitas ieu henteu acan kalebet dina sékrési naon waé. Nyaéta, sadaya pre-release ngadukung ieu, tapi versi pelepasan henteu. fungsionalitas ieu ditambahkeun dina versi 0.2. Pasti bakal dileupaskeun pas, pas urang ngalereskeun sadaya bug anu dipikanyaho. Tapi ayeuna ieu ngan bisa dipigawé dina pre-release. Aya dua bug dina pre-release. Masalah sareng pamulihan WAL-E, kami henteu acan ngalereskeunana. Sarta dina pre-release panganyarna bug ngeunaan delta-cadangan ditambahkeun. Ku alatan éta, kami nyarankeun ka sadayana nganggo versi pelepasan. Pas teu aya deui bug dina pre-release, urang bisa disebutkeun yen urang ngarojong Google Cloud, S3-cocog hal jeung neundeun file.
Halo, hatur nuhun pikeun laporan. Sakumaha kuring ngartos, WAL-G sanés sistem terpusat sapertos barmen? Naha anjeun badé ngalih ka arah ieu?
Masalahna nyaeta urang geus dipindahkeun jauh ti arah ieu. WAL-G hirup dina host dasar, dina host kluster, sareng sadaya host dina kluster. Nalika kami ngalih ka sababaraha rébu klaster, kami ngagaduhan seueur pamasangan palayan bar. Sareng unggal waktos aya anu rusak dina aranjeunna, éta mangrupikeun masalah anu ageung. Kusabab aranjeunna kedah dilereskeun, anjeun kedah ngartos klaster mana anu ayeuna teu gaduh cadangan. Abdi henteu ngarencanakeun ngembangkeun WAL-G dina arah hardware fisik pikeun sistem cadangan. Upami komunitas hoyong sababaraha fungsionalitas di dieu, kuring henteu kapikiran pisan.
Kami ngagaduhan tim anu tanggung jawab pikeun neundeun. Sarta kami ngarasa jadi alus éta lain urang, yén aya jalma husus anu nempatkeun file kami dimana file aman. Maranehna ngalakukeun sagala sorts coding palinter aya pikeun tahan leungitna sababaraha file. Aranjeunna jawab rubakpita jaringan. Lamun anjeun boga palayan bar, Anjeun bisa ujug-ujug manggihan yén database leutik kalawan loba lalulintas geus dikumpulkeun dina server sarua. Anjeun sigana boga loba spasi dina, tapi pikeun sababaraha alesan sagalana teu cocog ngaliwatan jaringan. Bisa jadi sabalikna. Aya seueur jaringan di dinya, aya inti prosesor, tapi henteu aya disk di dieu. Sarta kami meunang bosen ieu kedah juggle hal, sarta kami dipindahkeun ka kanyataan yén gudang data nyaéta layanan misah, nu tanggung jawab jalma husus misah.
PS Versi anyar parantos dileupaskeun , dimana anjeun tiasa nganggo file konfigurasi .walg.json, anu perenahna di diréktori home postgres sacara standar. Anjeun tiasa ngantunkeun skrip bash. Conto .walg.json aya dina masalah ieu
video:
sumber: www.habr.com