Мен Андрей Бородиннің 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 сізге резервтік көшірме жүйесі болмаса, «архив режимін» қосу керек екенін айтады.
Бұл параметрлерге өтіп, «архив_режимі = қосулы» күйін қосып, «архив_командасын» қосу керек дегенді білдіреді, бұл да WAL-G ішіндегі ішкі пәрмен болып табылады. Бірақ қандай да бір себептермен адамдар осы тақырып бойынша жолақты сценарийлерді жиі пайдаланады және оны WAL-G айналасында орап алады. Өтінемін, бұлай істеме. WAL-G ішінде табылған функцияны пайдаланыңыз. Егер сізге бірдеңе жетіспейтін болса, жазыңыз . WAL-G бұл archive_command ішінде жұмыс істейтін жалғыз бағдарлама деп есептейді.
Біз WAL-G негізінен Яндекс дерекқорын басқаруда жоғары қолжетімділік кластерін құру үшін қолданамыз.
Және ол әдетте бір Мастер топологиясында және бірнеше репликацияда қолданылады. Сонымен бірге ол Яндекс объектілер қоймасында сақтық көшірме жасайды.
Ең жиі кездесетін сценарийлер уақытты қалпына келтіру нүктесі арқылы кластердің көшірмелерін жасау болып табылады. Бірақ бұл жағдайда резервтік жүйенің өнімділігі біз үшін соншалықты маңызды емес. Бізге сақтық көшірмеден жаңа кластерді жүктеп салу керек.
Әдетте, жаңа түйінді қосқанда бізге резервтік жүйе өнімділігі қажет. Неліктен маңызды? Әдетте адамдар кластерге жаңа түйін қосады, себебі бар кластер оқу жүктемесін өңдей алмайды. Оларға жаңа көшірме қосу керек. Егер біз 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-delta-ны түнде ғана емес жасай аламыз, өйткені ол енді маңызды жүктеме көзі емес. Біз WAL-дельтаны минут сайын оқи аламыз, себебі ол арзан. Бір минут ішінде біз кластерге енгізілген барлық өзгерістерді сканерлей аламыз. Және мұны «лезде WAL-дельта» деп атауға болады.
Мәселе мынада, біз кластерді қалпына келтірген кезде біз дәйекті түрде жинауға тура келетін оқиғалар санын азайтамыз. Яғни, 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 деп атаймыз, ол бізге кілттерін береді. Содан кейін біз бұл кілттерді алып, оларды WAL-G ішінде біз үшін құрастырылған ашық PGP болып табылатын ішкі GPG-ге береміз, сонда біз шифрлау деп атаймыз. Осыған байланысты біз жүйені жақсартқымыз келеді және 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-G-де жасайық. Бірақ әзірге менде мұнымен қалай күресуге болатыны туралы жақсы идеялар жоқ. Тізімнің сақтық көшірмелерін басқаша қолдайтын кейбір нысандар қоймасы бар. Сіз олардан нысандарды тізімдеуін сұрайсыз және олар сол жерге қалтаны қосады. 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 бойынша. Әрқайсысы Объектілерді сақтауды конфигурациялағысы келмейді.
Иә, сондықтан олар бұл мүмкіндік туралы сұрақ қойды, сондықтан біз мұны істей аламыз. Және біз мұны жасадық.
Есеп үшін рахмет! Тек файлдық жүйеге көшіру туралы мәселе бар. Енді сіз қашықтағы жадқа көшіруді қолдайсыз ба, мысалы, деректер орталығында сөре немесе басқа нәрсе болса?
Бұл тұжырымда бұл қиын сұрақ. Иә, біз қолдаймыз, бірақ бұл функция әлі ешбір шығарылымда жоқ. Яғни, барлық алдын ала шығарылымдар мұны қолдайды, бірақ шығарылым нұсқалары қолдамайды. Бұл функция 0.2 нұсқасында қосылды. Біз барлық белгілі қателерді түзетсек, ол жақын арада шығарылады. Бірақ дәл қазір мұны тек алдын ала шығарылымда жасауға болады. Алдын ала шығарылымда екі қате бар. WAL-E қалпына келтіру ақауы, біз оны жөндеген жоқпыз. Ал соңғы шығарылымда delta-backup туралы қате қосылды. Сондықтан біз барлығына шығарылым нұсқаларын пайдалануды ұсынамыз. Алдын ала шығарылымда қателер қалмаған соң, біз Google Cloud, S3-үйлесімді нәрселерді және файлдарды сақтауды қолдайтынымызды айта аламыз.
Сәлем, есеп үшін рахмет. Менің түсінуімше, WAL-G бармендер сияқты орталықтандырылған жүйе емес пе? Осы бағытта қозғалуды жоспарлап отырсыз ба?
Мәселе мынада, біз бұл бағыттан алыстап кеттік. WAL-G негізгі хостта, кластер хостында және кластердегі барлық хосттарда тұрады. Біз бірнеше мың кластерге көшкен кезде бізде көптеген бармен қондырғылары болды. Олардың ішінде бірдеңе ыдыраған сайын бұл үлкен мәселе. Оларды жөндеу қажет болғандықтан, қазір қандай кластерлерде сақтық көшірмелері жоқ екенін түсіну керек. Мен резервтік жүйелерге арналған физикалық аппараттық құралдар бағытында WAL-G әзірлеуді жоспарламаймын. Егер қауымдастық мұнда кейбір функционалдылықты қаласа, мен мүлдем қарсы емеспін.
Бізде сақтауға жауапты топтар бар. Біздің файлдарды қауіпсіз жерге қоятын арнайы адамдар бар болғандықтан, біз өзімізді жақсы сезінеміз. Олар файлдардың белгілі бір санының жоғалуына төтеп беру үшін онда ақылды кодтаудың барлық түрлерін жасайды. Олар желінің өткізу қабілетіне жауап береді. Сізде бармен болған кезде, сіз кенеттен трафик көп шағын дерекқорлардың бір серверде жиналғанын білуіңіз мүмкін. Сізде көп орын бар сияқты, бірақ қандай да бір себептермен бәрі желі арқылы сәйкес келмейді. Бұл керісінше болуы мүмкін. Онда көптеген желілер бар, процессордың ядролары бар, бірақ мұнда дискілер жоқ. Біз бір нәрсені жонглерлік ету қажеттілігінен шаршадық және біз деректерді сақтау - бұл бөлек арнайы адамдар жауапты болатын бөлек қызмет екеніне көштік.
PS Жаңа нұсқасы шықты , онда әдепкі бойынша postgres үй каталогында орналасқан .walg.json конфигурация файлын пайдалануға болады. Bash сценарийлерінен бас тартуға болады. .walg.json мысалы осы шығарылымда
Бейне:
Ақпарат көзі: www.habr.com