Мен сизге Андрей Бородиндин 2019-жылдын башындагы отчетунун стенограммасын окууну сунуштайм "WAL-G менен резервдик. 2019-жылы эмне бар?"
Баарына салам! Менин атым Андрей Бородин. Мен Яндексте иштеп чыгуучумун. Мен PostgreSQLге 2016-жылдан бери кызыгып келем, мен иштеп чыгуучулар менен сүйлөшкөндөн кийин, алар бардыгы жөнөкөй экенин айтышты - сиз баштапкы кодду алып, аны курсаңыз, баары ойдогудай болот. Ошондон бери мен токтото албайм - ар кандай нерселерди жазам.
Мен иштеп жаткан нерселердин бири - резервдик система. . Жалпысынан, Яндексте биз PostgreSQLде резервдик системалардын үстүндө көптөн бери иштеп келе жатабыз. Ал эми сиз Интернеттен резервдик системаларды кантип түзөөрүбүз жөнүндө алты отчеттун сериясын таба аласыз. Жана жыл сайын алар бир аз өнүгүп, бир аз өнүгүп, ишенимдүү болуп калышат.
Бирок бүгүнкү күндө отчетто биз эмне кылганыбыз жөнүндө гана эмес, анын канчалык жөнөкөй жана эмне экендиги жөнүндө да. Сиздин канчаңыз менин WAL-G жөнүндө репортаждарымды көрдүңүз беле? Бир топ адам көрбөй калганы жакшы, себеби эң жөнөкөй нерседен баштайын.
Эгер күтүлбөгөн жерден сизде PostgreSQL кластери болсо жана менимче, ар бир адамда алардын бир нечеси бар болсо жана күтүлбөгөн жерден резервдик система жок болсо, анда сиз S3 сактагычын же Google Cloud шайкеш сактагычын алышыңыз керек.
Мисалы, сиз биздин стендге келип, S3 менен шайкеш келген Яндекс объектисин сактоо үчүн промо-кодду ала аласыз.
Андан кийин чака түзүңүз. Бул жөн гана маалымат үчүн контейнер.
Кызмат колдонуучуну түзүү.
Кызмат колдонуучусу үчүн кирүү ачкычын түзүңүз: aws-s3-key.
WAL-G акыркы туруктуу релизди жүктөп алыңыз.
Биздин алдын ала релиздер релиздерден эмнеси менен айырмаланат? Мени көп учурда эрте бошотууну суранышат. Ал эми версияда жетиштүү убакытка, мисалы, бир айга ката жок болсо, анда мен аны чыгарам. Бул жерде ноябрда бул чыгарылыш. Бул ай сайын биз кандайдыр бир мүчүлүштүктөрдү таптык дегенди билдирет, адатта, критикалык эмес функцияларда, бирок биз азырынча чыгара элекпиз. Мурунку версия ноябрда гана. Анда бизге белгилүү мүчүлүштүктөр жок, б.а. мүчүлүштүктөр долбоор ишке ашкан сайын кошулган.
WAL-G жүктөп алгандан кийин, сиз жөнөкөй "камдык тизме" буйругун иштете аласыз, чөйрө өзгөрмөлөрүндө өтүп. Жана ал Object Storage менен туташып, кандай камдык көчүрмөлөр бар экенин айтып берет. Алгач, албетте, сизде камдык көчүрмөлөр болбошу керек. Бул слайддын максаты - бардыгы абдан жөнөкөй экенин көрсөтүү. Бул чөйрө өзгөрмөлөрүн кабыл алган жана подкомандаларды аткарган консол буйругу.
Андан кийин, сиз биринчи камдык көчүрмөсүн жасай аласыз. WAL-Gде "камдык-түртүү" деп айтыңыз жана WAL-Gде кластериңиздин pgdata жайгашкан жерин көрсөтүңүз. Кыязы, PostgreSQL сизге, эгер сизде резервдик система жок болсо, "архив режимин" иштетишиңиз керек экенин айтат.
Бул сиз жөндөөлөргө өтүп, “archive_mode = on” күйгүзүшүңүз керек дегенди билдирет жана “archive_command” кошуу керек, бул дагы WAL-Gдеги подкоманда. Бирок эмнегедир адамдар бул темада тилке скрипттерин колдонушат жана аны WAL-G айланасында ороп алышат. Сураныч, муну кылбаңыз. WAL-Gде табылган функцияны колдонуңуз. Эгерде сизге бир нерсе жетишпей жатса, жазыңыз . WAL-G бул archive_command ичинде иштеген жалгыз программа деп болжолдойт.
Биз WAL-Gди негизинен Yandex маалымат базасын башкарууда Жогорку жеткиликтүүлүк кластерин түзүү үчүн колдонобуз.
Ал, адатта, бир Мастер топологиясында жана бир нече репликацияда колдонулат. Ошол эле учурда, ал Yandex объект сактагычында резервдик көчүрмөнү түзөт.
Эң кеңири таралган сценарийлер убакытты калыбына келтирүү пунктун колдонуу менен кластердин көчүрмөлөрүн түзүү болуп саналат. Бирок бул учурда резервдик системанын иштеши биз үчүн анчалык деле маанилүү эмес. Биз жөн гана камдык көчүрмөдөн жаңы кластерди жүктөп беришибиз керек.
Эреже катары, жаңы түйүндү кошууда бизге резервдик системанын иштеши керек. Бул эмне үчүн маанилүү? Адатта адамдар кластерге жаңы түйүн кошушат, анткени учурдагы кластер окуу жүгүн көтөрө албайт. Алар жаңы көчүрмөсүн кошуу керек. Эгерде pg_basebackup программасынан жүктү Мастерге кошсок, анда Мастер кулап калышы мүмкүн. Ошондуктан, биз Мастерге минималдуу жүктү түзүп, архивден жаңы түйүндү тез жүктөй алганыбыз абдан маанилүү болчу.
Жана дагы бир окшош жагдай. Бул байланыш жоголгон Маалымат борборунан кластердик мастерди которгондон кийин эски Мастерди кайра иштетүү зарылчылыгы.
- Натыйжада, көчүрүү системасына талаптарды түзүп жатканда, биз pg_basebackup булутта иштөөдө бизге ылайыктуу эмес экенин түшүндүк.
- Биз маалыматыбызды кысууну кааладык. Бирок кутуга киргенден башка дээрлик бардык резервдик система маалыматтарды кысуу менен камсыз кылат.
- Биз бардыгын параллелдештирүүнү кааладык, анткени булуттагы колдонуучу көп сандагы процессордун өзөгүн сатып алат. Бирок кээ бир операцияларда параллелизм болбосо, анда көп сандагы өзөктөр жараксыз болуп калат.
- Бизге шифрлөө керек, анткени көбүнчө маалыматтар биздики эмес жана аны ачык текстте сактоо мүмкүн эмес. Айтмакчы, биздин WAL-Gге кошкон салымыбыз шифрлөө менен башталды. Биз WAL-Gде шифрлөөнү бүтүрдүк, андан кийин бизден: "Балким, биздин бирөөбүз долбоорду иштеп чыгабызбы?" Ошондон бери мен WAL-G менен бир жылдан ашык иштеп келем.
- Бизге ресурстарды тескөө да керек болчу, анткени убакыттын өтүшү менен булутту колдонуп, кээде адамдар түн ичинде маанилүү азык-түлүк жүктөрүн жана бул жүккө тоскоолдук кыла албастыгын билдик. Ошондуктан биз ресурстарды чектөөнү коштук.
- Ошондой эле листинг жана башкаруу.
- Жана текшерүү.
Биз көп түрдүү куралдарды карап чыктык. Бактыга жараша, бизде PostgreSQLде чоң тандоо бар. Жана бардык жерде бизге бир нерсе жетишпей жатты, кээ бир кичинекей функция, кээ бир кичинекей функция.
Ал эми иштеп жаткан системаларды карап чыгып, биз WAL-G иштеп чыгабыз деген жыйынтыкка келдик. Ал кезде жаңы долбоор болчу. Камдык тутумдун булут инфраструктурасын өнүктүрүүгө таасир этүү оңой эле.
Биз карманган негизги идеология - WAL-G балалайкадай жөнөкөй болушу керек.
WAL-G 4 буйругу бар. Бул:
WAL-PUSH – валдын архиви.
WAL-FETCH – вал алуу.
BACKUP-PUSH – камдык көчүрмөнү түзүү.
BACKUP-FETCH – резервдик системадан резервдик көчүрмөнү алуу.
Чынында, WAL-G да бул камдык көчүрмөлөрдү башкарууга ээ, б.а. тарыхтагы жазууларды жана резервдик көчүрмөлөрдү тизмелөө жана жок кылуу, алар учурда кереги жок.
Биз үчүн маанилүү функциялардын бири - дельта көчүрмөлөрүн түзүү функциясы.
Delta көчүрмөлөрү биз бүткүл кластердин толук камдык көчүрмөсүн түзбөй, кластердеги өзгөртүлгөн файлдардын гана өзгөртүлгөн барактарын түзөбүз дегенди билдирет. Функционалдык жактан бул WAL аркылуу калыбына келтирүү жөндөмүнө абдан окшош окшойт. Бирок биз WAL бир жиптүү дельта камдык көчүрмөсүн параллелдүү түрдө топтой алабыз. Демек, бизде ишемби күнү жасалган базалык резервдик көчүрмө болгондо, дельтанын камдык көчүрмөлөрү күн сайын, ал эми бейшемби күнү биз иштебей калсак, анда биз 4 дельта камдык көчүрмөсүн жана 10 саат WAL топтошубуз керек. Бул болжол менен бирдей убакытты талап кылат, анткени дельтанын камдык көчүрмөлөрү параллелдүү жылат.
LSN негизиндеги дельталар - бул камдык көчүрмөнү түзүүдө биз ар бир баракты бириктирип, анын өзгөргөнүн түшүнүү үчүн анын LSNди мурунку камдык көчүрмөнүн LSNи менен текшеришибиз керек дегенди билдирет. Өзгөртүлгөн маалыматтарды камтышы мүмкүн болгон бардык барак дельта камдык көчүрмөсүндө болушу керек.
Мен айткандай, параллелизмге абдан көп көңүл бурулду.
Бирок PostgreSQLдеги архив API ырааттуу. PostgreSQL бир WAL файлын архивдейт жана аны калыбына келтиргенде бир WAL файлын сурайт. Бирок маалымат базасы "WAL-FETCH" буйругун колдонуп бир WAL файлын сураганда, биз "WAL-PREFETCH" буйругун чакырабыз, ал кийинки 8 файлды объектилер дүкөнүнөн параллелдүү түрдө алуу үчүн даярдайт.
Ал эми маалымат базасы бизден бир файлды архивдеп коюуну суранганда, биз archive_status дарегин карап, башка WAL файлдары бар-жогун көрөбүз. Ошондой эле биз WALды параллелдүү жүктөөгө аракет кылып жатабыз. Бул олуттуу аткарууну камсыз кылат жана архивделбеген WAL санындагы аралыкты бир топ кыскартат. Көптөгөн резервдик системаны иштеп чыгуучулар бул өтө кооптуу система деп эсептешет, анткени биз PostgreSQL API эмес, коддун ички түзүлүштөрү тууралуу билимибизге таянабыз. PostgreSQL биз үчүн archive_status папкасынын бар экендигине кепилдик бербейт жана семантикага, WAL файлдары үчүн даярдык сигналдарынын болушуна кепилдик бербейт. Ошого карабастан, биз баштапкы кодду изилдеп жатабыз, биз мунун ушундай экенин көрүп жатабыз жана аны пайдаланууга аракет кылып жатабыз. Жана биз PostgreSQL өнүгүп жаткан багытты көзөмөлдөйбүз; эгер күтүлбөгөн жерден бул механизм бузулуп калса, биз аны колдонууну токтотобуз.
Таза түрүндө, LSN негизиндеги WAL дельтасы файл тутумундагы режим убактысы мурунку резервдик көчүрмөдөн бери өзгөргөн каалаган кластердик файлды окууну талап кылат. Биз муну менен көп убакыт, дээрлик бир жыл жашадык. Акырында бизде WAL дельталары бар деген жыйынтыкка келдик.
Бул WALды Мастерде архивдеген сайын биз аны кысып, шифрлеп, тармакка жөнөтүп эле койбостон, ошону менен бирге окуйбуз дегенди билдирет. Андагы жазууларды талдап, окуйбуз. Кайсы блоктор өзгөргөнүн түшүнөбүз жана дельта файлдарын чогултабыз.
Delta файлы WAL файлдарынын белгилүү бир диапазонун сүрөттөйт, бул WAL диапазонунда кайсы блоктор өзгөртүлгөнү жөнүндө маалыматты сүрөттөйт. Анан бул дельта файлдары да архивделет.
Бул жерде биз бардыгын тез эле параллелдештиргенибиз менен бетме-бет келдик, бирок ырааттуу тарыхты параллелдүү окуй албайбыз, анткени белгилүү бир сегментте биз мурунку WAL рекордунун аягына туш болушубуз мүмкүн, аны менен байланышууга эч нерсебиз жок, анткени параллелдүү окуу биз адегенде өткөнү жок келечекти талдообузга алып келди.
Натыйжада, биз _delta_partial файлдарына түшүнүксүз бөлүктөрдү салууга туура келди. Натыйжада, өткөнгө кайтып келгенде, биз WAL жазуусунун бөлүктөрүн бирге чаптайбыз, андан кийин аны талдап, анда эмне өзгөргөнүн түшүнөбүз.
Эгерде биздин валдын талдоо тарыхында биз эмне болуп жатканын түшүнбөгөн жок дегенде бир учур болсо, демек, кийинки камдык көчүрмөдө биз кадимки LSN менен кылгандай, бүт кластерди кайрадан окууга аргасыз болобуз. - дельтага негизделген.
Натыйжада, биздин бардык азап-кайгыларыбыз WAL-G талдоо китепканасын ачык булактарга алып келгенбиз. Менин билишимче, азырынча эч ким колдонбойт, бирок кимде-ким кааласа, жазып, колдонсо, ал коомдук менчикте. (Жаңыртылган шилтеме )
Натыйжада, бардык маалымат агымдары абдан татаал көрүнөт. Биздин Мастер валды жана дельта файлдарын архивдейт. Ал эми камдык көчүрмөнү түзгөн реплика камдык көчүрмөлөр ортосунда өткөн убакыттын ичинде дельта файлдарын кабыл алышы керек. Бул учурда тарыхтын бөлүктөрүн жапырт кошуу жана талдоо керек болот, анткени бүт тарых чоң сегменттерге туура келбейт. Ошондон кийин гана реплика толук дельта камдык көчүрмөсүн архивдей алат.
Графиктерде баары бир топ жөнөкөй көрүнөт. Бул биздин чыныгы кластерлердин биринен жүктөлүп алынган. Биз LSN негизинде, бир күндө жасалган. LSN негизиндеги дельтанын камдык көчүрмөсү таңкы үчтөн таңкы бешке чейин иштеп жатканын көрүп жатабыз. Бул процессордун өзөктөрүнүн санындагы жүк. WAL-delta бул жерде бизге 20 мүнөткө жакын убакытты талап кылды, башкача айтканда, ал бир топ ылдамдады, бирок ошол эле учурда тармак аркылуу бир кыйла интенсивдүү алмашуу болду.
Бизде кайсы блоктор жана кайсы убакта маалымат базасынын тарыхында өзгөргөндүгү жөнүндө маалымат бар болгондуктан, биз андан ары бардык жана функционалдуулукту интеграциялоону чечтик - PostgreSQL кеңейтүүсү "pg_prefaulter"
Бул күтүү базасы калыбына келтирүү буйругун аткарганда, ал WAL-Gге кийинки WAL файлын алып келүүнү айтат дегенди билдирет. Биз WAL калыбына келтирүү процесси жакынкы келечекте кайсы маалыматтар блокторуна кире турганын түшүнөбүз жана бул блоктордо окуу операциясын башташат. Бул SSD контроллерлорунун натыйжалуулугун жогорулатуу максатында жасалган. Анткени WAL түрмөгү өзгөртүлүшү керек болгон баракка жетет. Бул барак дискте жана барактын кэшинде эмес. Жана ал бул баракчанын келишин синхрондуу түрдө күтөт. Бирок жакын жерде WAL-G бар, ал кийинки бир нече жүз мегабайт WAL ичинде бизге белгилүү бир барактар керек болорун билет жана ошол эле учурда аларды жылыта баштайт. Алар параллелдүү аткарылышы үчүн бир нече дискке кирүүнү демилгелейт. Бул SSD дисктеринде жакшы иштейт, бирок, тилекке каршы, бул катуу диск үчүн таптакыр колдонулбайт, анткени биз ага биздин көрсөтмөлөр менен гана кийлигишебиз.
Бул азыр кодексте жазылган.
Биз кошууну каалаган өзгөчөлүктөр бар.
Бул сүрөттө WAL-дельта салыштырмалуу кыска убакытты талап кылаарын көрсөтүп турат. Ал эми бул күн ичинде маалымат базасында болгон өзгөрүүлөрдү окуп жатат. Биз WAL-дельтаны түнкүсүн гана эмес, жасай алганбыз, анткени ал жүктүн олуттуу булагы болбой калды. Биз WAL-дельтаны мүнөт сайын окуй алабыз, анткени ал арзан. Бир мүнөттө биз кластерде болгон бардык өзгөрүүлөрдү сканерлей алабыз. Ал эми бул "instant WAL-delta" деп атоого болот.
Кеп, кластерди калыбына келтиргенде, биз ырааттуу түрдө топтошубуз керек болгон окуялардын санын азайтабыз. Башкача айтканда, PostgreSQL түрмөгүндө турган WAL көлөмү азайтылышы керек, анткени бул олуттуу убакытты талап кылат.
Бирок бул баары эмес. Эгерде биз кээ бир блоктун резервдик ырааттуулукка чейин өзгөрөрүн билсек, анда биз аны мурда өзгөртө албайбыз. Башкача айтканда, азыр бизде WAL-дельта багыттоосун файл боюнча оптималдаштыруу бар. Бул, мисалы, шейшемби күнү таблица толугу менен жок кылынса же кээ бир файлдар таблицадан толугу менен жок кылынса, анда дүйшөмбү күнү дельта айланганда жана ишемби күнү pg_basebackup калыбына келтирилгенде, биз бул маалыматты түзбөйбүз дегенди билдирет.
Биз бул технологияны барак деңгээлине чейин кеңейткибиз келет. Башкача айтканда, эгер файлдын кайсы бир бөлүгү дүйшөмбү күнү өзгөрүп, бирок шаршемби күнү кайра жазыла турган болсо, анда бейшемби күнү бир пунктка калыбына келтирилгенде, дискке барактардын алгачкы бир нече версиясын жазуунун кереги жок.
Бирок бул дагы эле биздин ичибизде активдүү талкууланып жаткан идея, бирок ал кодго жете элек.
Биз WAL-Gде дагы бир өзгөчөлүк жасагыбыз келет. Биз аны кеңейтүүнү каалайбыз, анткени биз ар кандай маалымат базаларын колдошубуз керек жана камдык көчүрмөнү башкарууга дал ушундай мамиледе болгубуз келет. Бирок маселе MySQL API түп-тамырынан бери айырмаланып турат. MySQLде PITR физикалык WAL журналына эмес, бинлогго негизделген. Жана бизде MySQLде архивдөө системасы жок, ал тышкы системага бул бинлог бүттү жана архивделиши керек деп кабарлайт. Биз маалымат базасы менен cron бир жерде туруп, даяр бир нерсе бар же жок экенин текшерүү керек?
Жана ошол эле жол менен, MySQL калыбына келтирүү учурунда, системага мага ушундай жана ушундай файлдар керек экенин айта турган калыбына келтирүү буйругу жок. Кластериңизди калыбына келтирүүнү баштоодон мурун, сизге кандай файлдар керек болорун билишиңиз керек. Сизге кандай файлдар керек болорун өзүңүз билишиңиз керек. Бирок бул көйгөйлөр кандайдыр бир жол менен айланып өтүшү мүмкүн. (Түшүндүрүү: MySQL буга чейин колдоого алынган)
Баяндамада мен WAL-G сизге ылайыктуу болбогон учурлар жөнүндө да айткым келди.
Эгер сизде синхрондуу реплика жок болсо, WAL-G акыркы сегмент сакталып кала тургандыгына кепилдик бербейт. Ал эми архивдөө тарыхтын акыркы сегменттеринен артта калса, бул коркунуч. Эгерде синхрондуу реплика жок болсо, мен WAL-Gди колдонууну сунуштабайм. Ошентсе да, ал негизинен булутту орнотуу үчүн иштелип чыккан, бул синхрондуу реплика менен Жогорку Жеткиликтүү чечимди билдирет, ал акыркы жасалган байттардын коопсуздугу үчүн жооп берет.
Мен көп учурда бир эле учурда WAL-G жана WAL-E экөөнү тең иштетүүгө аракет кылган адамдарды көрөм. WAL-G файлды WAL-Eден калыбына келтире алат жана WAL-Eде жасалган камдык көчүрмөнү калыбына келтире алат деген мааниде артка дал келүүнү колдойбуз. Бирок бул эки система тең параллелдүү wal-push колдонгондуктан, алар бири-биринен файлдарды уурдай башташат. Аны WAL-Gде оңдосок, ал WAL-Eде кала берет. WAL-Eде ал архив абалын карап, даяр файлдарды көрөт жана аларды архивдейт, ал эми башка системалар бул WAL файлы бар экенин билишпейт, анткени PostgreSQL аны экинчи жолу архивдегенге аракет кылбайт.
Бул жерде WAL-G тарабында эмнени оңдойбуз? Биз PostgreSQLге бул файл параллелдүү өткөрүлүп берилгенин билдирбейбиз жана PostgreSQL бизден аны архивдештирүүнү суранганда, биз бул режим убактысы жана md5 менен файл мурунтан эле архивделгенин билебиз жана биз жөн гана PostgreSQL деп айтабыз - Макул, эч нерсе кылбай эле баары даяр.
Бирок бул көйгөйдүн WAL-E тарабында чечилиши күмөн, андыктан учурда WAL-G жана WAL-E экөө тең файлды архивдей турган архив буйругун түзүү мүмкүн эмес.
Мындан тышкары, WAL-G азыр сизге ылайыксыз болгон учурлар бар, бирок биз аны сөзсүз түрдө оңдойбуз.
Биринчиден, бизде учурда камтылган камдык текшерүү жок. Камдык көчүрмөнү сактоо же калыбына келтирүү учурунда бизде текшерүү жок. Албетте, бул булут менен ишке ашырылат. Бирок бул жөн гана алдын ала текшерүү аркылуу, жөн гана кластерди калыбына келтирүү менен ишке ашырылат. Мен бул функцияны колдонуучуларга бергим келет. Бирок текшерүү жолу менен, мен WAL-Gде кластерди калыбына келтирип, аны баштоого жана түтүн сыноолорун жүргүзүүгө болот деп ойлойм: pg_dumpall - /dev/null жана amcheck индексин текшерүү.
Учурда WAL-Gде WALдан бир камдык көчүрмөнү кийинкиге калтырууга эч кандай жол жок. Башкача айтканда, биз кандайдыр бир терезени колдойбуз. Мисалы, акыркы жети күндү сактоо, акыркы он камдык көчүрмөнү сактоо, акыркы үч толук камдык көчүрмөнү сактоо. Көбүнчө адамдар келип: "Бизге Жаңы жылда болгон нерселердин резервдик көчүрмөсү керек жана биз аны түбөлүккө сактап калгыбыз келет" деп айтышат. WAL-G муну кантип жасоону азырынча билбейт. (Эскертүү - Бул мурунтан эле оңдолгон. Дагы окуу - Камдык белги опциясы )
Ал эми бизде PITRди валидациялоодо барактын текшерүү суммасы жана бардык шахта сегменттери үчүн бүтүндүк текшерүүлөрү жок.
Мунун баарынан мен Google Summer of Code долбоорун чогулттум. Эгер сиз Go'до бир нерсе жазып, бир компаниядан "G" тамгасы менен бир нече миң доллар алгысы келген акылдуу студенттерди билсеңиз, анда аларга биздин долбоорду сунуштаңыз. Мен бул долбоорго насаатчы катары иштейм, алар муну жасай алышат. Студенттер жок болсо, жайкысын өзүм алып кетем.
Анан дагы көптөгөн майда көйгөйлөрүбүз бар, аларды акырындап иштеп жатабыз. Жана кээ бир укмуштуудай нерселер болот.
Мисалы, WAL-Gге бош резервдик көчүрмөнү берсеңиз, ал жөн эле кулап калат. Мисалы, сиз ага бош папканын камдык көчүрмөсүн сактоо керек деп айтсаңыз. pg_control файлы ал жерде болбойт. Анан бир нерсени түшүнбөй калдым деп ойлойт. Теориялык жактан алганда, бул учурда колдонуучуга куралды кантип колдонуу керектигин түшүндүрүү үчүн кадимки билдирүү жазуу керек. Бирок бул программалоонун өзгөчөлүгү эмес, жакшы, түшүнүктүү тилдин өзгөчөлүгү.
Оффлайн камдык көчүрмөнү кантип жасоону билбейбиз. Эгер маалымат базасы жалган болсо, биз анын камдык көчүрмөсүн жасай албайбыз. Бирок бул жерде баары абдан жөнөкөй. LSN баштаганда биз камдык көчүрмөлөрдү чакырабыз. Негизги базанын LSNин башкаруу файлынан окуу керек. Жана бул ишке ашпаган өзгөчөлүк. Көптөгөн резервдик системалар базалык маалымат базасынын камдык көчүрмөсүн жасай алат. Жана бул ыңгайлуу.
Учурда камдык мейкиндиктин жетишсиздигин туура чече албайбыз. Анткени биз көбүнчө үйдө чоң резервдик көчүрмөлөр менен иштейбиз. Жана алар ага барышкан жок. Бирок кимдир-бирөө азыр Go программасында программалоону кааласа, мейкиндиктен тышкаркы каталарды башкарууну чакага кошуңуз. Мен сөзсүз түрдө тартуу өтүнүчүн карайм.
Бизди тынчсыздандырган негизги нерсе, биз ар кандай сценарийлерди текшерген мүмкүн болушунча көп докер интеграция тесттерин каалайбыз. Азыр биз негизги сценарийлерди гана сынап жатабыз. Ар бир милдеттенмеде, бирок биз колдогон бардык функцияларды милдеттенме боюнча текшерүүнү каалайбыз. Атап айтканда, бизде PostgreSQL 9.4-9.5 үчүн жетиштүү колдоо болот. Коомчулук PostgreSQLди колдогондуктан, биз аларды колдойбуз, бирок баары бузулбагандыгын текшерүү үчүн милдеттенме боюнча тапшырманы текшербейбиз. Анан менимче, бул өтө олуттуу тобокелдик.
Бизде WAL-G Яндекс маалымат базасын башкарууда миңден ашык кластерлерде иштейт. Ал күн сайын бир нече жүз терабайт маалыматтардын резервдик көчүрмөсүн түзөт.
Биздин кодубузда көп TODO бар. Программа кылгыңыз келсе келиңиз, тартуу сурамдарын күтөбүз, суроолорду күтөбүз.
суроолор
Кайырлуу кеч! Рахмат! Менин оюмча, эгер сиз WAL-delta колдонуп жатсаңыз, сиз толук беттик жазууларга көп ишенип жатасыз. Эгер ошондой болсо, сиз тесттерди өткөрдүңүз беле? Сиз сонун графикти көрсөттүңүз. FPW өчүрүлгөн болсо, ал канчалык кооз болуп калат?
Толук баракты жазуу биз үчүн иштетилген, биз аны өчүрүүгө аракет кылган жокпуз. Башкача айтканда, мен иштеп чыгуучу катары аны өчүрүүгө аракет кылган жокмун. Бул маселени изилдеген системалык администраторлор, балким, изилдешкен. Бирок бизге FPW керек. Аны дээрлик эч ким өчүрбөйт, анткени антпесе репликадан камдык көчүрмөнү алуу мүмкүн эмес.
Отчет үчүн рахмат! Менин эки суроом бар. Биринчи суроо - столдор менен эмне болот?
Биз тартуу өтүнүчүн күтүп жатабыз. Биздин маалымат базаларыбыз SSD жана NMVE дисктеринде жашайт жана бизге бул функциянын кереги жок. Мен азыр аны жакшы аткарууга олуттуу убакыт коротууга даяр эмесмин. Мен муну чын жүрөктөн колдойбуз. Колдоп, бирок өздөрүнө ылайыктуу түрдө колдогондор бар. Алар вилка жасашты, бирок алар тартуу өтүнүчтөрүн беришпейт. (0.2.13 версиясында кошулган)
Жана экинчи суроо. Сиз башында айттыңыз, WAL-G ал жалгыз иштейт деп болжолдойт жана эч кандай каптоочунун кереги жок. Мен өзүм орогучтарды колдоном. Эмне үчүн аларды колдонууга болбойт?
Балалайкадай жөнөкөй болушун каалайбыз. Бул балалайкадан башка эч нерсеге муктаж эмес экенин билдирет. Биз системанын жөнөкөй болушун каалайбыз. Эгерде сизде скриптте аткарышыңыз керек болгон функциялар болсо, анда келип бизге айтыңыз - биз муну Go'до жасайбыз.
Кайырлуу кеч! Отчет үчүн рахмат! WAL-Gди GPG чечмелөө менен иштөөгө ала алган жокпуз. Ал кадимкидей шифрлейт, бирок шифрди чечүүнү каалабайт. Бул биз үчүн иштебеген нерсеби? Кырдаал чөктүрөт.
GitHubда маселе жаратыңыз жана аны аныктап көрөлү.
Башкача айтканда, сиз буга жолуккан жоксузбу?
Ката жөнүндө отчеттун өзгөчөлүгү бар, ал WAL-G анын кандай файл экенин түшүнбөгөндө: "Балким ал шифрленгендир?" Балким, көйгөй шифрлөөдө эмес. Мен бул тема боюнча журналдарды жакшырткым келет. Ал аны чечмелеши керек. Учурда биз бул теманын үстүндө иштеп жатабыз, анткени биз ачык жана купуя ачкычтарды алуу системасы кантип уюштурулганын жактырбайт. Анткени биз тышкы GPG деп атабыз, ал бизге ачкычтарын берет. Анан биз бул ачкычтарды алып, аларды ички GPGге өткөрүп беребиз, ал ачык PGP, ал биз үчүн WAL-G ичинде түзүлгөн жана ал жерде биз шифрлөө деп атабыз. Ушуга байланыштуу, биз системаны жакшыртууну каалайбыз жана Libsodium шифрлөөсүн колдогубуз келет (0.2.15 версиясында кошулган). Албетте, декоддоо иштеши керек, келгиле, аны аныктап көрөлү - сизге бир нече сөзгө караганда көбүрөөк симптом керек. Сиз спикердин бөлмөсүнө чогулуп, системаны карап көрсөңүз болот. (Тышкы GPG жок PGP шифрлөө - v0.2.9)
Салам! Отчет үчүн рахмат! Менин эки суроом бар. Менде эки провайдерде pg_basebackup жана WAL логин жасоого кызыктай каалоом бар, б.а. мен бир булут, экинчисин кылгым келет. Муну жасоонун кандайдыр бир жолу барбы?
Бул азыр жок, бирок бул кызыктуу идея.
Мен жөн гана бир провайдерге ишенбейм, мен дагы башка бир провайдерге ээ болгум келет.
Идея кызыктуу. Техникалык жактан алганда, бул ишке ашыруу кыйын эмес. Идеянын жоголушуна жол бербөө үчүн, мен сизден GitHub сайтында маселе жаратууну сурансам болобу?
Ооба албетте.
Андан кийин, студенттер Google Summer of Code программасына келгенде, биз аларды долбоорго кошобуз, ошондо алардан көбүрөөк пайда алуу үчүн көбүрөөк иш болот.
Жана экинчи суроо. GitHubда маселе бар. Мен ал эчак эле жабылган деп ойлойм. Калыбына келтирүү учурунда паника пайда болот. Ал эми аны жеңүү үчүн өзүнчө жыйын курдуңуз. Маселелерде туура. Жана бир жипте өзгөрмө чөйрөнү жасоо мүмкүнчүлүгү бар. Ошондон улам ал өтө жай иштеп жатат. Жана биз бул көйгөйгө туш болдук, бирок ал дагы эле чечиле элек.
Көйгөй, кандайдыр бир себептерден улам, сактагыч (CEPH) биз ага жогорку параллелдүүлүк менен келгенде байланышты баштапкы абалга келтирет. Бул жөнүндө эмне кылсак болот? Кайра аракет кылуу логикасы ушундай көрүнөт. Биз файлды кайра жүктөп алууга аракет кылып жатабыз. Бир өтүүдө бизде бир нече файлдар жүктөлбөй калды, биз кирбегендердин бардыгы үчүн экинчисин жасайбыз. Жана итерацияда жок дегенде бир файл жүктөлсө, биз кайталап, кайталап жана кайталайбыз. Кайра аракет кылуунун логикасын жакшырттык - экспоненциалдык артка кайтаруу. Бирок, бул байланыш жөн гана сактоо системасы тарапта үзүлгөн менен эмне кылуу керек экенин так эмес. Башкача айтканда, биз бир агымга жүктөгөндө, бул байланыштарды үзбөйт. Бул жерде эмнени жакшыртсак болот? Бизде тармакты чектөө бар, биз ар бир туташууну жөнөткөн байттардын саны менен чектей алабыз. Болбосо, объекттин сакталышы бизге параллелдүү түрдө жүктөөгө же жүктөөгө мүмкүндүк бербеген факты менен кантип күрөшүү керектигин билбейм.
SLA жокпу? Алар өздөрүн азапка кантип жол берип жатканы жазылган эмеспи?
Кеп, бул суроо менен келген адамдардын, адатта, өздөрүнүн сейфтери бар. Башкача айтканда, Amazon же Google Cloud же Yandex Object Storageден эч ким келбейт.
Балким бул суроо сиз үчүн эместир?
Бул жерде суроо ким үчүн маанилүү эмес. Муну менен кантип күрөшүү керектиги боюнча кандайдыр бир идеялар бар болсо, WAL-Где жасайлы. Бирок азырынча менде муну менен кантип күрөшүү керектиги боюнча жакшы идеяларым жок. Листинг камдык көчүрмөлөрүн башкача колдогон объект сактагычтары бар. Сиз алардан объекттерди тизмелөөсүн сурайсыз, алар ошол жерге папканы кошот. WAL-G ушундан коркуп кетет - бул жерде файл эмес кандайдыр бир нерсе бар, мен аны калыбына келтире албайм, бул камдык көчүрмө калыбына келтирилген эмес дегенди билдирет. Башкача айтканда, чындыгында, сизде толугу менен калыбына келтирилген кластер бар, бирок ал сизге ката статусун кайтарат, анткени Object Storage ал толук түшүнбөгөн кызыктай маалыматты кайтарып берди.
Бул Почта булутунда боло турган нерсе.
Эгер сиз репродукцияны кура алсаңыз ...
Ал ырааттуу түрдө кайра чыгарылат ...
Эгерде кайталоо бар болсо, анда биз кайра аракет кылуу стратегиялары менен эксперимент жасайбыз жана булут бизден эмнени талап кыларын түшүнүп, кантип кайра аракет кылууну аныктайбыз деп ойлойм. Балким, үч байланыш боюнча биз үчүн туруктуу болуп, байланышты үзбөйт, ошондо кылдаттык менен үчкө жетебиз. Анткени азыр биз байланышты тез эле таштайбыз, башкача айтканда, биз 16 жип менен калыбына келтирүүнү ишке киргизсек, анда биринчи кайталоодон кийин 8 жип, 4 жип, 2 жип жана бир болот. Анан файлды бир агымга тартат. Эгерде кээ бир сыйкырдуу баалуулуктар бар болсо, мисалы, 7,5 жип соргуч үчүн эң жакшы, анда биз аларга токтолуп, дагы 7,5 жипти жасоого аракет кылабыз. Бул жерде бир идея.
Кабар үчүн рахмат! WAL-G менен иштөө үчүн толук иш процесси кандай көрүнөт? Мисалы, барактардын ортосунда дельта жок болгон келесоо учурда. Ал эми биз баштапкы резервдик көчүрмөнү алып, алып салабыз, андан кийин көгөргөнчө валды архивдейбиз. Бул жерде, мен түшүнгөндөй, бузулуу бар. Кайсы бир учурда сиз барактардын дельта камдык көчүрмөсүн жасашыңыз керек, башкача айтканда, кандайдыр бир тышкы процесс муну башкарып жатат же бул кантип болот?
Delta камдык API абдан жөнөкөй. Ал жерде бир сан бар - максималдуу дельта кадамдары, ал ушундай деп аталат. Ал демейки нөлгө барабар. Бул сиз камдык түрткөн сайын, ал толук камдык көчүрмөнү жүктөйт дегенди билдирет. Эгер сиз аны кандайдыр бир оң санга өзгөртсөңүз, мисалы, 3, анда кийинки жолу сиз резервдик көчүрүүнү жасаганыңызда, ал мурунку резервдик көчүрмөлөрдүн тарыхын карайт. 3 дельтанын чынжырынан ашпаганыңды көрүп, дельта жасайт.
Башкача айтканда, биз WAL-G ишке киргизген сайын, ал толук камдык көчүрмөсүн жасоого аракет кылат?
Жок, биз WAL-G иштетебиз жана саясаттарыңыз уруксат берсе, ал дельтаны түзүүгө аракет кылат.
Болжол менен айтканда, эгер сиз аны ар бир жолу нөл менен иштетсеңиз, ал pg_basebackup сыяктуу иштейби?
Жок, ал дагы эле тезирээк иштейт, анткени ал кысуу жана параллелизмди колдонот. Pg_basebackup вал сиздин жаныңызга коёт. WAL-G сизде архивдөө конфигурацияланган деп болжолдойт. Ал конфигурацияланбаса, эскертүү берет.
Pg_basebackup валсыз иштетсе болот.
Ооба, анда алар өздөрүн дээрлик бирдей алып жүрүшөт. Pg_basebackup файл тутумуна көчүрөт. Айтмакчы, бизде жаңы өзгөчөлүк бар, мен аны унутуп калдым. Биз азыр pg_basebackup файлдык тутумуна камдык көчүрө алабыз. Бул эмне үчүн керек экенин билбейм, бирок ал бар.
Мисалы, CephFS боюнча. Баары эле Object Storage конфигурациялоону каалабайт.
Ооба, балким, ошондуктан алар бул функция жөнүндө суроо беришкен, ошондуктан биз муну жасай алабыз. Жана биз муну жасадык.
Баяндама үчүн рахмат! Файлдык системага көчүрүү жөнүндө гана суроо бар. Кутудан тышкары, сиз азыр алыскы сактагычка көчүрүүнү колдойсузбу, мисалы, маалымат борборунда кандайдыр бир текче же башка нерсе болсо?
Бул формулировкада бул татаал суроо. Ооба, биз колдойбуз, бирок бул функция азырынча эч кандай чыгарылышта камтылган эмес. Башкача айтканда, бардык алдын ала релиздер муну колдойт, бирок релиз версиялары андай эмес. Бул функция 0.2 версиясында кошулган. Биз бардык белгилүү мүчүлүштүктөрдү оңдоп алсак, ал сөзсүз түрдө жакында чыгат. Бирок азыр муну алдын ала чыгарууда гана жасоого болот. Алдын ала чыгарууда эки мүчүлүштүктөр бар. WAL-E калыбына келтирүүдөгү көйгөй, биз аны оңдой элекпиз. Ал эми акыркы алдын ала чыгарууда delta-backup жөнүндө ката кошулган. Ошондуктан биз бардыгына релиз версияларын колдонууну сунуштайбыз. Алдын ала релизде мүчүлүштүктөр калбай калгандан кийин, биз Google Булутту, S3 менен шайкеш нерселерди жана файлдарды сактоону колдойбуз деп айта алабыз.
Салам, отчет үчүн рахмат. Мен түшүнгөндөй, WAL-G бармендер сыяктуу борборлоштурулган система эмеспи? Бул багытта жылууну пландап жатасызбы?
Маселе бул багыттан алыстап кеткенибизде. WAL-G базалык хостто, кластердик хостто жана кластердеги бардык хосттордо жашайт. Биз бир нече миң кластерлерге көчкөндө, бизде көптөгөн бармен инсталляциялары болгон. Жана аларда бир нерсе ыдыраган сайын бул чоң көйгөй. Аларды оңдоо керек болгондуктан, азыр кайсы кластерлерде резервдик көчүрмөлөр жок экенин түшүнүү керек. Мен резервдик системалар үчүн физикалык жабдыктар багытында WAL-Gди иштеп чыгууну пландаган жокмун. Коомчулук бул жерде кандайдыр бир функцияны кааласа, мен таптакыр каршы эмесмин.
Бизде сактоого жооптуу топтор бар. Жана биз өзүбүздү ушунчалык жакшы сезип жатабыз, бул биз эмес, биздин файлдарды коопсуз жерге койгон атайын адамдар бар. Белгилүү бир сандагы файлдарды жоготууга туруштук берүү үчүн алар ал жерде ар кандай акылдуу коддоолорду жасашат. Алар тармактын өткөрүү жөндөмдүүлүгүнө жооптуу. Сизде бармен болгондо, сиз күтүлбөгөн жерден трафик көп болгон кичинекей маалымат базалары бир серверде чогулганын билип калышыңыз мүмкүн. Сизде көп орун бар окшойт, бирок эмнегедир баары тармак аркылуу туура келбейт. Бул тескерисинче болушу мүмкүн. Ал жерде көптөгөн тармактар бар, процессордук өзөктөр бар, бирок бул жерде дисктер жок. Жана биз бул зарылчылыктан чарчадык, жана биз маалыматтарды сактоо өзүнчө кызмат, ал үчүн өзүнчө атайын адамдар жооптуу экенине өттүк.
PS Жаңы версиясы чыкты , анда сиз демейки боюнча postgres үй каталогунда жайгашкан .walg.json конфигурация файлын колдоно аласыз. Сиз bash скрипттерин таштасаңыз болот. Мисал .walg.json бул чыгарылышта
Videos:
Source: www.habr.com