Мен сизге Андрей Сальниковдун 2016-жылдын башындагы отчетунун стенограммасын окуп чыгууну сунуштайм "Postgresqlде шишикке алып келген тиркемелердеги типтүү каталар"
Бул отчетто мен тиркемелердин кодун долбоорлоо жана жазуу стадиясында пайда болгон колдонмолордогу негизги каталарды талдайм. Мен Postgresqlде шишикке алып келген каталарды гана алам. Эреже катары, бул сиздин тутумуңуздун бүтүндөй иштешинин аякташынын башталышы, бирок башында бул үчүн эч кандай өбөлгөлөр көрүнгөн эмес.
Баарын тосуп алганыма кубанычтамын! Бул баяндама менин кесиптешимден мурункудай техникалык эмес. Бул отчет негизинен системаны иштеп чыгуучуларга багытталган, анткени бизде кардарлардын саны абдан көп. Жана алардын бардыгы бирдей каталарды кетиришет. Мен сага алар жөнүндө айтып берейин. Мен бул каталар эмнеге алып келе турган өлүмгө алып келерин түшүндүрөм.
Эмне үчүн каталар кетирилет? Алар эки себеп менен жасалат: кокусунан, балким, ал ишке ашат жана маалымат базасы менен тиркеменин ортосундагы деңгээлде, ошондой эле маалымат базасынын өзүндө пайда болгон кээ бир механизмдерди билбегендиктен.
Мен силерге жаман нерселердин кандай коркунучтуу сүрөттөрү менен үч мисал келтирем. Мен ал жерде эмне механизми жөнүндө кыскача айтып берейин. Жана алар менен кантип күрөшүү керек, алар качан болгон жана каталарды болтурбоо үчүн кандай профилактикалык ыкмаларды колдонуу керек. Мен сизге жардамчы куралдар жөнүндө айтып берем жана пайдалуу шилтемелерди берем.
Мен эки үстөл болгон тест базасын колдондум. Бир табак кардарлардын эсептери менен, экинчисинде бул эсептер боюнча транзакциялар. Жана кээ бир жыштык менен биз бул эсептердеги калдыктарды жаңыртабыз.
Пластинанын баштапкы маалыматтары: ал абдан кичинекей, 2 МБ. Маалыматтар базасына жана өзгөчө белгиге жооп берүү убактысы да абдан жакшы. Ал эми бир кыйла жакшы жүк - табак боюнча секундасына 2 операциялар.
Жана бул отчет аркылуу мен сизге эмне болуп жатканын так түшүнүү үчүн графиктерди көрсөтөм. Ар дайым графиктери бар 2 слайд болот. Биринчи слайд - серверде жалпысынан эмне болуп жатат.
Жана бул жагдайда биз чындап эле кичинекей белги бар экенин көрөбүз. Индекс кичинекей, 2 МБ. Бул сол жактагы биринчи график.
Серверде орточо жооп берүү убактысы да туруктуу жана кыска. Бул жогорку оң график.
Төмөнкү сол график эң узун транзакцияларды көрсөтөт. Биз транзакциялар тез аяктаганын көрүп жатабыз. Ал эми автовакуум бул жерде азырынча иштебейт, анткени бул башталгыч сыноо болгон. Ал мындан ары да иштей берет жана бизге пайдалуу болот.
Экинчи слайд дайыма текшерилип жаткан плитага арналат. Мындай кырдаалда биз кардардын эсебинин балансын дайыма жаңыртып турабыз. Жана биз жаңыртуу операциясынын орточо жооп берүү убактысы бир миллисекунддан аз экенин көрүп жатабыз. Биз процессордун ресурстары (бул жогорку оң жактагы график) да бир калыпта жана өтө аз сарпталарын көрүп жатабыз.
Төмөнкү оң диаграммада биз каалаган линияны жаңыртуудан мурун издөө үчүн канча операциялык жана диск эстутумунан өткөнүбүздү көрсөтөт. Ал эми белги боюнча операциялардын саны мен башында айткандай секундасына 2.
Эми бизде трагедия бар. Эмнегедир көптөн бери унутулуп калган бүтүм бар. Себептери, адатта, баналдык болуп саналат:
- Эң кеңири таралган нерселердин бири - биз колдонмо кодундагы тышкы кызматка кире баштадык. Ал эми бул кызмат бизге жооп бербейт. Башкача айтканда, транзакция ачып, базага өзгөртүү киргизип, тиркемеден почтаны окууга же биздин инфраструктуранын ичиндеги башка кызматка өтүп кеттик, эмнегедир ал бизге жооп бербей жатат. Ал эми сессиябыз качан чечилери белгисиз абалга кептелди.
- Экинчи жагдай, кандайдыр бир себептерден улам биздин кодубузда өзгөчө кырдаал болгон. Ал эми өзгөчө учурда биз бүтүмдү жабууну иштеткен жокпуз. Ал эми биз ачык бүтүм менен асма сессиясы менен аяктады.
- Ал эми акыркысы да абдан кеңири таралган учур. Бул сапаты төмөн код. Кээ бир алкактар транзакцияны ачат. Ал илинип турат жана сиз тиркемеде анын илинип турганын билбешиңиз мүмкүн.
Мындай нерселер кайда алып барат?
Биздин таблицаларыбыз жана индекстерибиз кескин өсө баштайт. Бул так ошол эле шишик таасири. Маалыматтар базасы үчүн бул маалымат базасынын жооп берүү убактысы абдан кескин көбөйөт жана маалымат базасынын серверине жүктөм көбөйөт дегенди билдирет. Натыйжада биздин арызыбыз жабыркайт. Себеби, эгер сиз кодуңузга 10 миллисекундду маалымат базасына суроо-талапка жумшасаңыз, логикаңызга 10 миллисекунд жумшасаңыз, анда сиздин функцияңыз бүтүшү үчүн 20 миллисекунд талап кылынган. Эми сенин абалың абдан кейиштүү болот.
Анан эмне болорун карап көрөлү. Төмөнкү сол график бизде узакка созулган транзакция бар экенин көрсөтүп турат. Ал эми жогорку сол графикти карасак, столубуздун көлөмү күтүлбөгөн жерден эки мегабайттан 300 мегабайтка чейин секирип кеткенин көрөбүз. Ошол эле учурда, таблицадагы маалыматтардын көлөмү өзгөргөн жок, башкача айтканда, ал жерде таштандынын бир кыйла чоң көлөмү бар.
Сервердин орточо жооп берүү убактысына байланыштуу жалпы абал дагы бир нече даражага өзгөрдү. Башкача айтканда, сервердеги бардык суроо-талаптар толугу менен түшө баштады. Ошол эле учурда, ички Postgres процесстери автовакуум түрүндө ишке киргизилди, алар бир нерсе кылууга аракет кылып, ресурстарды жалмап жатышат.
Биздин белги эмне болуп жатат? Ошол эле. Белгиге ылайык биздин орточо жооп берүү убакытыбыз бир нече даражага көтөрүлдү. Тактап айтканда, керектелген ресурстар боюнча, биз процессорго жүк абдан көбөйгөнүн көрөбүз. Бул жогорку оң график. Жана ал көбөйдү, анткени процессор керектүүсүн издөө үчүн бир топ пайдасыз сызыктарды иргеп алышы керек. Бул төмөнкү оң диаграмма. Натыйжада, биздин чалуулардын саны секундасына абдан азая баштады, анткени маалымат базасы бирдей сандагы суроо-талаптарды иштеп чыгууга үлгүрбөй калган.
Биз жашоого кайтып келишибиз керек. Биз интернетке кирип, узак транзакциялар көйгөйлөргө алып келерин билебиз. Биз бул транзакцияны таап, өлтүрөбүз. Ал эми биз үчүн баары кадимкидей болуп баратат. Баары керек болуп иштейт.
Биз тынчтанып калдык, бирок бир аз убакыт өткөндөн кийин биз колдонмо өзгөчө кырдаалга чейинкидей иштебей турганын байкай баштайбыз. Сурамдар дагы эле жайыраак жана кыйла жайыраак иштетилет. Менин мисалымда бир жарым-эки эсе жайыраак. Сервердеги жүк дагы кырсыкка чейинкиге караганда жогору.
Жана суроо: "Азыркы учурда база эмне болуп жатат?" Ал эми база менен төмөнкү жагдай пайда болот. транзакция диаграммасында ал токтоп калганын жана чындап эле узак мөөнөттүү бүтүмдөр жок экенин көрө аласыз. Бирок кырсык учурунда белгинин көлөмү чоңойгон. Ошондон бери алар азайган жок. Базадагы орточо убакыт турукташкан. Ал эми жооптор биз үчүн алгылыктуу ылдамдыкта адекваттуу келип жаткансыйт. Автовакуум активдешип, белги менен бир нерсе кыла баштады, анткени ал көбүрөөк маалыматтарды электен өткөрүү керек.
Тактап айтканда, биз балансты өзгөрткөн эсептер менен тесттик пластинкага ылайык: суроо-талапка жооп берүү убактысы нормалдуу болуп калды окшойт. Бирок чындыгында ал бир жарым эсе жогору.
Ал эми процессорго жүктөлгөн жүктөн биз процессордогу жүк кырсыкка чейин керектүү мааниге кайтып келбегенин көрөбүз. Ал эми себептери так төмөнкү оң диаграммада жатат. Ал жерде белгилүү бир көлөмдөгү эстутум изделип жатканын көрүүгө болот. Башкача айтканда, талап кылынган линияны табуу үчүн, биз пайдасыз маалыматтарды сорттоодо маалымат базасы серверинин ресурстарын текке кетиребиз. секундасына транзакциялардын саны турукташты.
Жалпысынан жакшы, бирок абал мурдагыдан да начар. Бул маалымат базасы менен иштеген колдонмобуздун натыйжасы катары базанын начарлашын тазалаңыз.
Ал эми ал жерде эмне болуп жатканын түшүнүү үчүн, эгерде сиз мурунку баяндамада болбосоңуз, анда бир аз теорияны алалы. Ички процесс жөнүндө теория. Эмне үчүн унаа чаң соргуч жана ал эмне кылат?
Сөзмө-сөз кыскача түшүнүү үчүн. Кайсы бир убакта үстөлүбүз бар. Бизде таблицада катарлар бар. Бул линиялар активдүү, жандуу жана азыр бизге керек болушу мүмкүн. Алар сүрөттө жашыл түс менен белгиленген. Ал эми буга чейин иштелип чыккан, жаңыланган жана жаңы жазуулар пайда болгон өлүк сызыктар бар. Жана алар базага мындан ары кызыксыз деп белгиленет. Бирок алар Postgres өзгөчөлүгүнөн улам үстөлдө.
Эмне үчүн сизге унаа чаң соргуч керек? Кайсы бир убакта автовакуум келип, маалымат базасына кирип, андан сурайт: "Мага азыркы учурда маалымат базасында ачык турган эң эски транзакциянын идентификаторун бериңизчи." Маалымат базасы бул идентификаторду кайтарат. Ал эми автовакуум ага таянып, таблицадагы сызыктарды иреттейт. Ал эми кээ бир сызыктар бир топ эски транзакциялар менен өзгөртүлгөнүн көрсө, анда ал аларды жаңы маалыматтарды жазып, келечекте кайра колдоно турган сызыктар катары белгилөөгө укуктуу. Бул фон процесси.
Учурда биз маалымат базасы менен иштөөнү улантып, таблицага бир аз өзгөртүүлөрдү киргизүүнү улантып жатабыз. Жана биз кайра колдоно турган бул саптарга биз жаңы маалыматтарды жазабыз. Ошентип, биз цикл алабыз, башкача айтканда, ар дайым ал жерде кээ бир өлүк эски сызыктар пайда болот, алардын ордуна биз керектүү жаңы саптарды жазабыз. Жана бул PostgreSQL иштеши үчүн нормалдуу абал.
Кырсык учурунда эмне болду? Ал жерде бул процесс кандайча ишке ашты?
Бизде кандайдыр бир шартта белги бар болчу, кээ бирлери тирүү, кээ бирлери өлүк сызыктар. Машинанын вакууму келди. Ал базадан биздин эң эски транзакциябыз жана анын id деген эмне экенин сурады. Мен бул идентификаторду алдым, ал көп саат мурун, балким он мүнөт мурун болушу мүмкүн. Бул сиздин базаңыздагы жүктүн канчалык оор экенине жараша болот. Жана ал кайра колдонулган деп белгилей турган сызыктарды издеп кетти. А мен биздин таблицадан мындай саптарды тапкан жокмун.
Бирок бул учурда биз үстөл менен иштөөнү улантабыз. Биз анда бир нерсе жасайбыз, аны жаңыртабыз, маалыматтарды өзгөртөбүз. Бул учурда маалымат базасы эмне кылышы керек? Ал учурдагы таблицанын аягына жаңы саптарды кошуудан башка аргасы жок. Ошентип биздин дасторконубуздун көлөмү көбөйө баштайт.
Иш жүзүндө бизге жашыл сызыктар керек. Бирок, мындай көйгөй учурунда, жашыл сызыктардын пайызы бүткүл столдо өтө төмөн экени көрүнүп турат.
Ал эми биз суроону аткарганда, маалымат базасы бардык сызыктардан өтүшү керек: кызыл жана жашыл, каалаган сызыкты табуу үчүн. Ал эми үстөлдү пайдасыз маалыматтар менен толтуруунун эффектиси "блоат" деп аталат, ал да биздин диск мейкиндигин жеп салат. Эсиңизде болсун, ал 2 МБ болчу, 300 МБ болуп калдыбы? Эми мегабайттарды гигабайтка өзгөртсөңүз, сиз бардык диск ресурстарыңызды тез жоготосуз.
Биз үчүн кандай кесепеттер болушу мүмкүн?
- Менин мисалымда таблица жана индекс 150 эсе өстү. Кээ бир кардарларыбызда диск мейкиндиги түгөнүп калганда өлүмгө дуушар болгон учурлар көп болгон.
- Столдордун көлөмү эч качан азайбайт. Автовакуум кээ бир учурларда, эгерде өлүк сызыктар болсо, үстөлдүн куйругун кесип алат. Бирок тынымсыз айлануу болгондуктан, бир жашыл сызык аягында тоңуп, жаңыланбай калышы мүмкүн, ал эми калгандарынын баары табактын башында бир жерге жазылып калат. Бирок бул күтүлбөгөн окуя, ошондуктан сиздин үстөлүңүздүн көлөмү кичирейет, андыктан ага үмүттөнбөшүңүз керек.
- Берилиштер базасы керексиз линиялардын бүтүндөй тобун иреттөө керек. Ал эми биз диск ресурстарын ысырап кылабыз, процессордун ресурстарын жана электр энергиясын ысырап кылабыз.
- Жана бул биздин колдонмобузга түздөн-түз таасирин тийгизет, анткени башында биз суроо-талапка 10 миллисекунд, кодубузга 10 миллисекунд жумшаган болсок, анда авария учурунда биз суроо-талапка бир секунд жана кодго 10 миллисекунд жумшай баштадык, б.а. колдонмонун натыйжалуулугунун көлөмү төмөндөдү. Ал эми кырсык чечилгенден кийин биз суроо-талапка 20 миллисекунд, кодго 10 миллисекунд корото баштадык. Бул биз эмгек ендурумдуулугун дагы эле бир жарым эсеге темендеп жаткандыгыбызды билдирет. Мунун баары бир транзакциянын айынан, балким биздин күнөөбүздөн улам.
- Ал эми суроо: "Кантип баарын кайтарып алсак болот?" Бизде баары жакшы жана өтүнүчтөр кырсыкка чейинкидей тез келип түшүшөт.
Бул үчүн аткарылып жаткан иштин белгилүү бир цикли бар.
Адегенде биз шишип кеткен көйгөйлүү үстөлдөрдү табышыбыз керек. Кээ бир таблицаларда жазуу активдүүрөөк, башкаларында азыраак экенин түшүнөбүз. Бул үчүн биз кеңейтүүнү колдонобуз . Бул кеңейтүүнү орнотуу менен, сиз абдан толгон таблицаларды табууга жардам бере турган суроолорду жаза аласыз.
Бул таблицаларды тапкандан кийин, аларды кысуу керек. Бул үчүн мурунтан эле аспаптар бар. Биздин компанияда биз үч куралды колдонобуз. Биринчиси - орнотулган ВАКУМ ФУЛЛ. Ал таш боор, катаал жана ырайымсыз, бирок кээде абдан пайдалуу. и - Бул үстөлдөрдү кысуу үчүн үчүнчү тараптын утилиталары. Жана алар маалымат базасына кылдат мамиле кылышат.
Алар сиз үчүн ыңгайлуураак болгонуна жараша колдонулат. Бирок мен бул жөнүндө эң аягында айтып берем. Эң негизгиси, үч курал бар. Тандоо үчүн көп нерсе бар.
Биз бардыгын оңдоп, баары жакшы экенине ынангандан кийин, келечекте бул кырдаалды алдын алууну билишибиз керек:
- Аны оңой эле алдын алса болот. Мастер сервердеги сеанстардын узактыгын көзөмөлдөшүңүз керек. Өзгөчө коркунучтуу сеанстар транзакция абалында иштебей турат. Булар жөн гана транзакцияны ачып, бир нерсе кылып таштап кеткендер, же жөн эле асылып, коддон адашып калгандар.
- Жана сиз үчүн, иштеп чыгуучулар, бул жагдайлар пайда болгондо кодуңузду сынап көрүү маанилүү. Бул кыйын эмес. Бул пайдалуу текшерүү болот. Сиз узак транзакциялар менен байланышкан көптөгөн "балалык" көйгөйлөрдөн качасыз.
Бул графиктерде мен бул учурда VACUUM FULL менен белгиден өткөндөн кийин маалымат базасынын белгиси жана жүрүм-туруму кандай өзгөргөнүн көрсөткүм келди. Бул мен үчүн өндүрүш эмес.
Столдун көлөмү дароо эле бир нече мегабайтка чейин кадимки иштөө абалына кайтып келди. Бул сервердин орточо жооп берүү убактысына чоң таасирин тийгизген жок.
Бирок биз эсептин баланстарын жаңырткан тесттик белги үчүн, белгидеги маалыматтарды жаңыртуу өтүнүчүнө орточо жооп берүү убактысы өзгөчө кырдаалга чейинки деңгээлге чейин кыскарганын көрөбүз. Бул өтүнүчтү аткаруу үчүн процессор сарптаган ресурстар да кыйроого чейинки деңгээлге чейин төмөндөдү. Ал эми ылдыйкы оң диаграммада биз стол кысылганга чейин болгон өлүк сызыктардын үймөгүн аралап өтпөстөн, бизге керектүү сызыкты дароо таап жатканыбызды көрсөтүп турат. Ал эми суроо-талаптын орточо убактысы болжол менен бирдей деңгээлде калды. Бирок, бул жерде, тескерисинче, менин аппараттык ката бар.
Бул жерде биринчи окуя аяктайт. Бул эң кеңири таралган. Бул кардардын тажрыйбасына жана программисттердин квалификациясына карабастан, ар бир адамда болот. Эртеби-кечпи бул болот.
Экинчи окуя, анда биз жүктөөнү бөлүштүрөбүз жана сервер ресурстарын оптималдаштырабыз
- Биз чоңоюп, олуттуу жигит болуп калдык. Жана бизде реплика бар экенин түшүнөбүз жана жүктү тең салмактаганыбыз жакшы болмок: Устатка жазыңыз жана репликадан окуңуз. Ал эми, адатта, бул жагдай кээ бир отчетторду же ETL даярдоону каалаганда пайда болот. Ал эми бизнес буга абдан ыраазы. Ал чындап эле көптөгөн татаал аналитика менен ар кандай отчетторду каалайт.
- Отчеттор көп саатты талап кылат, анткени татаал аналитиканы миллисекунд менен эсептөө мүмкүн эмес. Биз, эр жүрөк жигиттерге окшоп, код жазабыз. Кыстаруу тиркемесинде биз мастерде жазууну жасайбыз жана репликада отчетторду аткарабыз.
- Жүктү бөлүштүрүү.
- Баары кемчиликсиз иштейт. Биз сонунбуз.
Жана бул жагдай кандай көрүнөт? Тактап айтканда, бул графиктерде мен транзакциянын узактыгы үчүн репликадан транзакциялардын узактыгын коштум. Бардык башка графиктер Мастер серверге гана тиешелүү.
Бул убакта менин отчеттук тактам чоңоюп калган. Алардын саны дагы көп. Биз сервердин орточо жооп берүү убактысы туруктуу экенин көрөбүз. Репликада бизде 2 саатка созулган узакка созулган транзакция бар экенин көрүп жатабыз. Өлгөн линияларды иштеткен автовакуумдун тынч иштешин көрүп жатабыз. Жана бизде баары жакшы.
Тактап айтканда, сыналган пластинкага ылайык, биз ал жердеги эсептин калдыктарын жаңыртууну улантабыз. Ошондой эле бизде суроо-талаптарга туруктуу жооп берүү убактысы, туруктуу ресурстарды керектөө бар. Бизде баары жакшы.
Бул отчеттор репликация менен кагылышуудан улам кайра күйө баштаганга чейин баары жакшы. Жана алар белгилүү аралыкта кайра ок чыгарышат.
Биз интернетке кирип, эмне үчүн мындай болуп жатканын окуй баштайбыз. Жана биз бир чечим табабыз.
Биринчи чечим - репликациянын кечигүү убактысын көбөйтүү. Биздин отчетубуз 3 саатка созуларын билебиз. Биз репликациянын кечиктирилишин 3 саатка койдук. Биз бардыгын ишке киргизип жатабыз, бирок бизде дагы эле кээде отчеттор жокко чыгарылып жаткан көйгөйлөр бар.
Биз бардыгы кемчиликсиз болушун каалайбыз. Биз андан ары көтөрүлөбүз. Ал эми биз Интернеттен сонун жөндөөнү таптык - hot_standby_feedback. Аны күйгүзөлү. Hot_standby_feedback бизге Мастердеги автовакуумду кармап турууга мүмкүндүк берет. Ошентип, биз репликация конфликттеринен толугу менен кутулабыз. Жана бардыгы биз үчүн отчеттор менен жакшы иштейт.
Ал эми азыркы учурда Мастер сервер менен эмне болуп жатат? Ал эми биз Мастер сервер менен көйгөйгө туш болдук. Эми бул эки жөндөө тең иштетилгенде, биз графиктерди көрүп жатабыз. Биздин репликадагы сессия кандайдыр бир жол менен Master сервердеги кырдаалга таасир эте баштаганын көрүп жатабыз. Анын таасири бар, анткени ал өлүк сызыктарды тазалаган автовакуумду тындырды. Биздин дасторконубуздун көлөмү кайрадан асмандап кетти. Бүткүл маалымат базасында сурамдарды аткаруунун орточо убактысы да асмандап кетти. Автовакуумдар бир аз бекемделди.
Тактап айтканда, биздин табактан биз андагы маалыматтардын жаңыртуулары да асманга секиргенин көрөбүз. CPU керектөө ушу сыяктуу эле абдан көбөйдү. Биз кайрадан көп сандагы өлүк, керексиз линиялардан өтүп жатабыз. Ал эми бул белгиге жооп берүү убактысы жана транзакциялардын саны кыскарды.
Мурда эмне жөнүндө айтып жатканымды билбесек, ал кандай болот?
- Биз көйгөйлөрдү издей баштайбыз. Эгерде биз биринчи бөлүктө көйгөйлөргө туш болсок, бул узак транзакциядан улам болушу мүмкүн экенин билебиз жана Мастерге кайрылабыз. Бизде Мастер боюнча көйгөй бар. Ага колбаса. Ал ысыйт, анын орточо жүктөмү жүзгө жакын.
- Ал жерде суроо-талаптар жай, бирок биз ал жерде эч кандай узакка созулган транзакцияларды көргөн жокпуз. Анан эмне болуп жатканын түшүнбөй жатабыз. Кайдан издешибизди түшүнбөй жатабыз.
- Биз сервердик жабдууларды текшеребиз. Балким биздин рейдибиз кыйрап калгандыр. Балким биздин эс тутумубуз күйүп калгандыр. Ооба, баары болушу мүмкүн. Бирок жок, серверлер жаңы, баары жакшы иштейт.
- Баары иштеп жатат: администраторлор, иштеп чыгуучулар жана директор. Эч нерсе жардам бербейт.
- Анан кандайдыр бир убакта баары күтүлбөгөн жерден оңоло баштайт.
Бул учурда биздин репликадагы өтүнүч иштелип чыгып, калтырылды. Биз отчет алдык. Бизнес дагы деле бактылуу. Көрүнүп тургандай, биздин белги кайра чоңоюп, кичирейбей жатат. Сеанстар бар графикте мен бул узак транзакциянын бир бөлүгүн репликадан калтырдым, андыктан кырдаал турукташканга чейин канча убакыт талап кылынарын эсептей аласыз.
Сессия аяктады. Жана бир нече убакыт өткөндөн кийин гана сервер аздыр-көптүр иретте келет. Ал эми Мастер сервердеги суроо-талаптарга орточо жооп берүү убактысы нормалдуу абалга келет. Анткени, акырында, автовакуумда бул өлүк сызыктарды тазалоо жана белгилөө мүмкүнчүлүгү бар. Жана ал өз ишин жасай баштады. Анан ал муну канчалык тез аткарса, биз тез эле тартипке келебиз.
Сыналган планшетке ылайык, биз эсептин калдыктарын жаңыртабыз, биз дал ошол эле сүрөттү көрөбүз. Орточо эсеп жаңыртуу убактысы да акырындык менен нормалдашууда. Процессор керектеген ресурстар да азаят. Ал эми секундасына бүтүмдөрдүн саны нормалдуу кайтып келет. Бирок биз кайрадан кадимки абалга келдик, кырсыкка чейинкидей эмес.
Кандай болгон күндө да, биз биринчи учурдагыдай эле, бир жарым-эки эсеге, кээде андан да көп көрсөткүчтөргө ээ болобуз.
Биз баарын туура кылдык окшойбуз. Жүктү бөлүштүрүү. Жабдуулар бош туруп калган эмес. Суранычтарды акылыбызга жараша бөлдүк, бирок баары бир жаман болуп чыкты.
- hot_standby_feedback иштетилбейби? Ооба, өзгөчө күчтүү себептерсиз аны күйгүзүү сунушталбайт. Анткени бул бурма түздөн-түз Master серверге таасирин тийгизет жана ал жердеги автовакуумдун ишин токтотот. Аны кандайдыр бир репликада иштетип, аны унутуп коюу менен, сиз Мастерди өлтүрүп, тиркемеде чоң көйгөйлөргө туш боло аласыз.
- Максималдуу_күтүү_агымынын_кечигүүсү көбөйтүлсүнбү? Ооба, кабарлар үчүн бул чындык. Эгер сизде үч сааттык отчет бар болсо жана анын репликация карама-каршылыгынан улам бузулушун каалабасаңыз, анда жөн гана кечиктирүүнү көбөйтүңүз. Узак мөөнөттүү отчет эч качан маалымат базасына азыр түшкөн маалыматтарды талап кылбайт. Эгер сизде үч саат бар болсо, анда сиз аны эски маалымат мезгили үчүн иштетип жатасыз. Ал эми силер үчүн үч сааттык кечигүү болобу же алты сааттык кечигүү эч кандай айырмасы жок, бирок сиз отчетторду ырааттуу алып турасыз жана алардын кулашы менен эч кандай көйгөй болбойт.
- Албетте, сиз репликалардагы узак сеанстарды көзөмөлдөшүңүз керек, өзгөчө репликада hot_standby_feedback иштетүүнү чечсеңиз. Анткени баары болушу мүмкүн. Биз бул репликаны иштеп чыгуучуга бердик, ал суроолорду сынап көрүшү үчүн. Ал жинди суроо жазган. Ал аны ишке киргизип, чай ичкени жөнөдү, биз устатты алдык. Же ал жерге туура эмес тиркемени киргизип коюшубуз мүмкүн. Кырдаалдар ар түрдүү. Репликалардагы сессиялар Мастердегидей кылдаттык менен көзөмөлдөнүшү керек.
- Ал эми репликалар боюнча тез жана узак сурооңуз болсо, анда бул учурда жүктү бөлүштүрүү үчүн аларды бөлүү жакшы. Бул streaming_delay шилтемеси. Ыкчам репликалар үчүн репликация аз кечигүү менен бир репликага ээ болуңуз. Узакка созулган отчеттук суроо-талаптар үчүн 6 саатка же бир суткага артта калышы мүмкүн болгон репликага ээ болуңуз. Бул таптакыр нормалдуу абал.
Биз кесепеттерин ошол эле жол менен жок кылабыз:
- Биз шишип столдорду табабыз.
- А биз аны өзүбүзгө ылайыктуу эң ыңгайлуу курал менен кысып алабыз.
Экинчи окуя ушул жерден бүтөт. Үчүнчү окуяга өтөлү.
Миграция кылган биз үчүн да кеңири таралган.
- Ар кандай программалык продукт өсүп жатат. Ага коюлган талаптар өзгөрүүдө. Кандай болгон күндө да биз өнүгүп келебиз. Жана биз таблицадагы маалыматтарды жаңыртышыбыз керек болот, тактап айтканда, биз иштеп чыгуунун бир бөлүгү катары киргизип жаткан жаңы функция үчүн миграциябыз боюнча жаңыртууну ишке ашыруу үчүн.
- Эски маалымат форматы канааттандырарлык эмес. Эми экинчи таблицага кайрылалы дейли, анда менде бул эсептер боюнча операциялар бар. Жана алар рублинде болгон деп коёлу, жана биз тактыгын жогорулатуу жана Kopecks менен эмне кылууну чечтик. Жана бул үчүн биз жаңылоону жасашыбыз керек: транзакциянын суммасы менен талааны жүзгө көбөйтүңүз.
- Азыркы дүйнөдө биз маалымат базасынын версиясын башкаруунун автоматташтырылган куралдарын колдонобуз. Айталы . Миграциябызды ошол жакка каттайбыз. Биз аны сыноо базабызда сынап жатабыз. Баары жакшы. Жаңыртуу жүрүп жатат. Бул ишти бир азга бөгөттөйт, бирок биз жаңыртылган маалыматтарды алабыз. Жана биз бул боюнча жаңы функцияларды ишке киргизе алабыз. Баары текшерилип, текшерилди. Баары тастыкталды.
- Пландуу иштерди аткарып, миграцияны жүргүздүк.
Бул жерде сиздин алдыңызда көрсөтүлгөн жаңыртуу менен көчүү. Бул менин эсептик операцияларым болгондуктан, табак 15 ГБ болгон. Жана биз ар бир сапты жаңырткандыктан, жаңыртуу менен жадыбалдын өлчөмүн эки эсеге көбөйттүк, анткени биз ар бир сапты кайра жаздык.
Миграция учурунда биз бул табак менен эч нерсе кыла алган жокпуз, анткени ага бардык сурамдар кезекке туруп, бул жаңыртуу аяктаганга чейин күттүк. Бирок бул жерде мен сиздин көңүлүңүздү вертикалдык огунда турган сандарга бургум келет. Башкача айтканда, бизде миграцияга чейинки орточо суроо-талап убактысы 5 миллисекунд жана процессордун жүктөлүшүнө ээ, диск эстутумун окуу үчүн блоктук операциялардын саны 7,5тен аз.
Миграцияны ишке ашырып, кайра көйгөйлөргө туш болдук.
Миграция ийгиликтүү болду, бирок:
- Эски функцияны аягына чыгаруу үчүн эми көбүрөөк убакыт талап кылынат.
- Стол кайрадан чоңойду.
- Сервердеги жүк мурункуга караганда көбүрөөк болду.
- Анан, албетте, биз дагы эле жакшы иштеген функционалдык менен алектенип жатабыз, аны бир аз жакшырттык.
Бул дагы бир жолу биздин жашообузду бузат.
Бул жерде мен үстөл, мурунку эки учурда сыяктуу эле, мурунку өлчөмдөрүнө кайтып келбейт деп көрсөтөм. Орточо сервер жүктөмү адекваттуу окшойт.
Ал эми эсептер менен таблицага кайрылсак, бул таблица үчүн суроо-талаптын орточо убактысы эки эсеге көбөйгөнүн көрөбүз. Процессорго жүктөм жана эстутумда иреттелген саптардын саны 7,5тен жогору секирип, бирок андан төмөн болгон. Ал эми процессорлордо 2 эсеге, блоктук операцияларда 1,5 эсеге секирип кетти, б.а. сервердин иштеши начарлап кетти. Натыйжада - биздин колдонмонун иштешинин начарлашы. Ошол эле учурда чалуулардын саны болжол менен бирдей деңгээлде калган.
Ал эми бул жерде эң негизгиси, мындай миграцияны кантип туура жасоо керектигин түшүнүү. Жана алар аткарылышы керек. Биз бул миграцияны ырааттуу түрдө жасайбыз.
- Мындай чоң миграция өзүнөн өзү боло бербейт. Алар ар дайым көзөмөлдө болушу керек.
- Билимдүү адамдын көзөмөлү талап кылынат. Эгерде сиздин командаңызда DBA бар болсо, анда DBA аны аткарсын. Анын иши. Болбосо, анда эң тажрыйбалуу, маалымат базалары менен иштегенди билген адам жасасын.
- Берилиштер базасынын жаңы схемасы, бир тилкени жаңырткан күндө да, биз ар дайым этап менен даярдайбыз, башкача айтканда, тиркеменин жаңы версиясы чыкканга чейин:
- Биз жаңыртылган маалыматтарды жаза турган жаңы талаалар кошулду.
- Биз эски талаадан жаңы талаага майда бөлүктөр менен маалыматтарды өткөрөбүз. Эмне үчүн биз муну кылып жатабыз? Биринчиден, биз бул процесстин процессин ар дайым көзөмөлдөйбүз. Биз буга чейин ушунча партияны өткөрүп бергенибизди жана бизде ушунча партия калганын билебиз.
- Ал эми экинчи оң натыйжа - бул ар бир партиянын ортосунда транзакцияны жаап, жаңысын ачабыз, бул автовакуумга пластинка боюнча иштөөгө, кайра колдонуу үчүн өлүк сызыктарды белгилөөгө мүмкүндүк берет.
- Тиркеме иштеп жатканда пайда боло турган саптар үчүн (бизде дагы эле эски колдонмо иштеп жатат), биз жаңы талааларга жаңы маанилерди жаза турган триггерди кошобуз. Биздин учурда бул эски маанинин жүзгө көбөйтүлүшү.
- Эгерде биз толугу менен өжөр болсок жана бир эле талааны кааласак, анда бардык көчүрүү аяктагандан кийин жана тиркеменин жаңы версиясын чыгаруудан мурун, биз талаалардын атын жөн эле өзгөртөбүз. Эскилерине кандайдыр бир ойлоп табылган аталыштар берилет, ал эми жаңы талаалар эскилерге кайра аталат.
- Ошондон кийин гана биз тиркеменин жаңы версиясын ишке киргизебиз.
Жана ошол эле учурда биз шишип кетпейбиз жана аткаруу жагынан кыйналбайбыз.
Үчүнчү окуя ушул жерден бүтөт.
Эми мен биринчи окуяда айткан куралдар жөнүндө бир аз көбүрөөк маалымат.
Bloat издөөдөн мурун, сиз кеңейтүүнү орнотуу керек .
Суроолор менен келбешиңиз үчүн, биз бул суроолорду ишибизде мурунтан эле жазганбыз. Сиз аларды колдоно аласыз. Бул жерде эки өтүнүч бар.
- Биринчиси иштөө үчүн бир топ убакытты талап кылат, бирок ал сизге таблицадан так шишикти көрсөтөт.
- Экинчиси тезирээк иштейт жана таблицага ылайык шишик бар же жок экенин тез баалоо керек болгондо абдан эффективдүү. Ошондой эле сиз Postgres таблицасында шишик ар дайым бар экенин түшүнүшүңүз керек. Бул анын MVCC моделинин өзгөчөлүгү.
- Ал эми 20% шишик көпчүлүк учурларда столдор үчүн нормалдуу болуп саналат. Башкача айтканда, сиз тынчсызданбаңыз жана бул үстөлдү кысуу керек.
Биз пайдасыз маалыматтар менен шишип кеткен таблицаларды кантип аныктоону чечтик.
Эми шишикти кантип оңдоо керектиги жөнүндө:
- Эгерде бизде кичинекей планшет жана жакшы дисктер болсо, башкача айтканда, гигабайтка чейинки планшетте, VACUUM FULL колдонууга толук мүмкүн. Ал бир нече секундага үстөлдүн үстүндө сизден эксклюзивдүү кулпуну алат жана макул, бирок ал баарын тез жана катаал кылат. VACUUM FULL эмне кылат? Ал үстөлдүн өзгөчө кулпусун алып, эски таблицалардан жаңы таблицага жандуу саптарды кайра жазат. Анан акырында аларды алмаштырат. Ал эски файлдарды жок кылат жана эскилерин жаңылары менен алмаштырат. Бирок, анын ишинин узактыгы үчүн, ал үстөлгө өзгөчө кулпусун алат. Бул сиз бул таблица менен эч нерсе кыла албайсыз дегенди билдирет: ага жазуу да, окуу да, өзгөртүү да болбойт. Жана VACUUM FULL маалымат жазуу үчүн кошумча диск мейкиндигин талап кылат.
- Кийинки курал . Өзүнүн принцибинде ал VACUUM FULLге абдан окшош, анткени ал ошондой эле эски файлдардан маалыматтарды жаңысына кайра жазат жана аларды таблицага алмаштырат. Бирок, ошол эле учурда, ал өзүнүн ишинин эң башында үстөлгө эксклюзивдүү кулпусун албайт, бирок файлдарды алмаштыруу үчүн дайын маалыматтары бар учурда гана алат. Анын диск ресурсуна талаптар VACUUM FULL талаптарына окшош. Сизге кошумча диск мейкиндиги керек жана терабайт таблицаларыңыз болсо, бул кээде өтө маанилүү. Жана ал процессорго абдан муктаж, анткени ал I/O менен активдүү иштейт.
- Үчүнчү утилита болуп саналат . Бул ресурстарга этиятыраак мамиле кылат, анткени ал бир аз башкача принциптерге ылайык иштейт. pgcompacttableдин негизги идеясы - бул таблицадагы жаңыртууларды колдонуу менен бардык жандуу саптарды таблицанын башына жылдыруу. Анан бул столдо боштук иштейт, анткени биз башында жандуу саптар жана аягында өлүк катарлар бар экенин билебиз. Ал эми вакуум өзү бул куйругун кесип, башкача айтканда, көп кошумча диск мейкиндигин талап кылбайт. Жана ошол эле учурда, ал дагы эле ресурстар жагынан кысылышы мүмкүн.
Бардык куралдар менен.
Эгер сизди тереңирээк изилдөө жагынан кызыктуу тема тапсаңыз, бул жерде кээ бир пайдалуу шилтемелер бар:
- - Бул менин кесиптешимдин отчету. Постгрестин мейкиндиги анын жумушу жана жашоосу учурунда кайда баратат. Жана маалымат базасынын администраторлору үчүн bloat жөнүндө абдан чоң жана деталдуу техникалык бөлүгү бар.
- – бул биздин репозиторийге шилтеме, анда биз маалымат базасынын абалын текшерүү үчүн бир топ пайдалуу скрипттерди сактайбыз. Ал жерден bloat издөө үчүн скрипттерди таба аласыз.
- и белгилерин кыскартууга жардам бере турган куралдарга шилтемелер.
- – бул менин кесиптешимдин билдирүүсү. Ал жерде администраторлорго жакын деңгээлде олуттуу жана техникалык жактан деталдуу талдоо жүргүзөт.
Мен иштеп чыгуучулар үчүн коркунучтуу окуяны көрсөтүүгө көбүрөөк аракет кылдым, анткени алар биздин маалымат базаларынын түз кардарлары жана эмнеге жана эмнеге алып келерин түшүнүшү керек. Мен ийгиликке жеттим деп үмүттөнөм. Конул бурганын учун рахмат!
суроолор
Баяндама үчүн рахмат! Сиз көйгөйлөрдү кантип аныктоого болорун айттыңыз. Аларды кантип эскертсе болот? Башкача айтканда, менде суроо-талаптар кээ бир тышкы кызматтарга киргендиктен эле илинип турган жагдай болгон. Булар жапайы кошулмалар эле. Кээ бир кичинекей, зыянсыз өтүнүчтөр бир күн бою илип, анан кандайдыр бир маанисиз иштерди кыла баштады. Башкача айтканда, сиз сүрөттөгөн нерсеге абдан окшош. Муну кантип көзөмөлдөө керек? Кайсы сурам тыгылып калганын тынбай карап отуруңуз? Муну кантип алдын алса болот?
Бул учурда, бул DBA үчүн эмес, сиздин компанияңыздын администраторлору үчүн тапшырма.
Мен администратормун.
PostgreSQLдин pg_stat_activity деп аталган көрүнүшү бар, ал илинип турган суроолорду көрсөтөт. Ал жерде канчага чейин илинип турганын көрүүгө болот.
Ар бир 5 мүнөт сайын кирип карап турушум керекпи?
Cron орнотуп, текшериңиз. Эгерде сизде узак мөөнөттүү өтүнүч болсо, кат жазыңыз жана бүттү. Башкача айтканда, көз менен кароонун кереги жок, аны автоматташтырууга болот. Сиз кат аласыз, ага реакция жасайсыз. Же автоматтык түрдө тарта аласыз.
Мунун эмне үчүн ачык-айкын себептери барбы?
Мен айрымдарын тизмектеп койдум. Башка татаал мисалдар. Анан көпкө чейин сүйлөшүү болушу мүмкүн.
Баяндама үчүн рахмат! Мен pg_repack утилитасы жөнүндө тактагым келди. Эгер ал эксклюзивдүү кулпу жасабаса, анда...
Ал эксклюзивдүү кулпу жасайт.
... анда мен маалыматты жоготуп алышым мүмкүн. Бул убакыттын ичинде менин арызым эч нерсе жаздырбашы керекпи?
Жок, ал үстөл менен бир калыпта иштейт, б.а. pg_repack адегенде бар болгон бардык жандуу линияларды өткөрүп берет. Албетте, таблицага кандайдыр бир кирүү ошол жерде болот. Ал жөн эле бул ат куйругун ыргытып жатат.
Башкача айтканда, ал, чынында эле, аягында муну кылат?
Акыр-аягы, ал бул файлдарды алмаштыруу үчүн эксклюзивдүү кулпу алат.
VACUUM FULL караганда тезирээк болобу?
VACUUM FULL, ал иштей баштаганда дароо эксклюзивдүү кулпусун алды. Ал баарын кылмайынча, аны коё бербейт. Жана pg_repack эксклюзивдүү кулпуну файлды алмаштыруу учурунда гана алат. Бул учурда сиз ал жакка жазбайсыз, бирок маалыматтар жоголбойт, баары жакшы болот.
Салам! Сиз машина вакуумунун иштеши жөнүндө айттыңыз. Кызыл, сары жана жашыл жазуу клеткалары бар график бар болчу. Башкача айтканда, сары түстөрдү - өчүрүлгөн деп белгиледи. Натыйжада, аларга жаңы нерсе жазууга болот?
Ооба. Postgres саптарды жок кылбайт. Анын мындай өзгөчөлүгү бар. Эгерде биз сапты жаңырткан болсок, эскисин жок кылынган деп белгилегенбиз. Бул сапты өзгөрткөн транзакциянын id ошол жерде пайда болот жана биз жаңы сапты жазабыз. Жана бизде аларды окуй турган сессиялар бар. Бир убакта алар бир топ карып калышат. Ал эми автовакуумдун кандай иштээринин маңызы бул сызыктар аркылуу өтүп, аларды керексиз деп белгилейт. Жана сиз ошол жерде маалыматтарды үстүнө жаза аласыз.
Мен түшүндүм. Бирок суроо ушунда эмес. Мен бүтүргөн жокмун. Бизде үстөл бар дейли. Анын өзгөрүлмө өлчөмдөгү талаалары бар. Жана жаңы бир нерсе киргизем десем, ал жөн эле эски уячага батпай калышы мүмкүн.
Жок, кандай болгон күндө да бардык линия ошол жерде жаңыртылды. Postgres эки маалымат сактоо моделине ээ. Ал маалымат түрүнөн тандайт. Түздөн-түз таблицада сакталган маалыматтар бар, ошондой эле tos маалыматтары бар. Бул чоң көлөмдөгү маалыматтар: текст, json. Алар өзүнчө пластинкаларда сакталат. Жана бул таблеткаларга ылайык, шишик менен бир эле окуя болот, б.а. баары бирдей. Алар жөн гана өзүнчө тизмеленген.
Баяндама үчүн рахмат! Узактыгын чектөө үчүн билдирүү күтүү убакытынын сурамдарын колдонуу алгылыктуубу?
Абдан алгылыктуу. Биз муну бардык жерде колдонобуз. Ал эми өзүбүздүн кызматтарыбыз жок болгондуктан, биз алыстан колдоо көрсөтөбүз, кардарларыбыз абдан көп. Жана бардыгы буга толук канааттанышат. Башкача айтканда, бизде текшерүүчү cron жумуштары бар. Сеанстардын узактыгы жөн гана кардар менен макулдашылат, ага чейин биз макул эмеспиз. Бул бир мүнөт болушу мүмкүн, 10 мүнөт болушу мүмкүн. Бул базанын жүгүнө жана анын максатына жараша болот. Бирок баарыбыз pg_stat_activity колдонобуз.
Баяндама үчүн рахмат! Мен сиздин баяндамаңызды колдонмолорума колдонууга аракет кылып жатам. Жана биз транзакцияны бардык жерде баштайбыз жана аны бардык жерде так бүтүрөбүз. Эгер кандайдыр бир өзгөчөлүк бар болсо, анда артка кайтаруу дагы деле болот. Анан ойлонуп баштадым. Анткени, бүтүм ачык башталбашы мүмкүн. Бул кызга ишарат болсо керек. Эгер мен жөн гана жазууну жаңырсам, транзакция PostgreSQLде башталып, байланыш үзүлгөндө гана бүтөбү?
Эгер сиз азыр колдонмо деңгээли жөнүндө айтып жатсаңыз, анда ал сиз колдонуп жаткан драйверден, колдонулуп жаткан ORMден көз каранды. Ал жерде көптөгөн орнотуулар бар. Эгер сизде автомилдеттөө иштетилген болсо, транзакция ошол жерден башталат жана дароо жабылат.
Башкача айтканда, ал жаңыртылгандан кийин дароо жабылат?
Бул орнотуулардан көз каранды. Мен бир жөндөөнү атадым. Бул автоматтык түрдө ишке киргизүү. Бул абдан кеңири таралган. Эгер ал иштетилген болсо, анда транзакция ачылды жана жабылды. Эгер сиз "транзакцияны баштоо" жана "транзакцияны аяктоо" деп ачык айтпасаңыз, бирок жөн гана сессияга суроо-талапты киргизгенсиз.
Салам! Баяндама үчүн рахмат! Келгиле, бизде шишип, шишип жаткан маалымат базасы бар деп элестетип көрөлү, анан сервердеги боштук түгөнөт. Бул абалды оңдоо үчүн кандайдыр бир аспаптар барбы?
Сервердеги мейкиндикти туура көзөмөлдөө керек.
Мисалы, DBA чайга барды, курортто болду, ж.б.
Файл системасы түзүлгөндө, маалыматтар жазылбаган жерде жок дегенде кандайдыр бир резервдик мейкиндик түзүлөт.
Ал толугу менен нөлдөн төмөн болсочу?
Ал жерде ал резервдик мейкиндик деп аталат, башкача айтканда, аны бошотууга болот жана ал канчалык чоң түзүлгөнүнө жараша, бош орун аласыз. Демейки боюнча мен канча экенин билбейм. Ал эми башка учурда, дисктерди реконструкциялоо операциясын жүргүзүүгө орун берүү үчүн жеткириңиз. Сиз керек болбой турган кээ бир таблицаны жок кылсаңыз болот.
Башка куралдар барбы?
Ал ар дайым колго жасалган. Ал эми жергиликтүү деңгээлде ал жерде эмне кылуу эң жакшы экендиги айкын болуп калат, анткени кээ бир маалыматтар маанилүү, кээ бирлери критикалык эмес. Ал эми ар бир маалымат базасы жана аны менен иштеген тиркеме үчүн бул бизнестен көз каранды. Бул ар дайым жергиликтүү чечилет.
Баяндама үчүн рахмат! Менин эки суроом бар. Биринчиден, сиз транзакциялар токтоп калганда, таблица мейкиндиги да, индекс өлчөмү да өсөөрүн көрсөткөн слайддарды көрсөттүңүз. Андан ары отчетто планшетти таңгактаган бир топ коммуналдык кызматтар бар болчу. Индекс жөнүндө эмне айтууга болот?
Аларды да таңып коюшат.
Бирок вакуум индекске таасир этпейби?
Кээ бирлери индекс менен иштешет. Мисалы, pg_rapack, pgcompacttable. Вакуум индекстерди кайра жаратат жана аларга таасирин тийгизет. VACUUM FULL менен бардык нерсенин үстүнөн жазуу идеясы бар, б.а. баары менен иштейт.
Жана экинчи суроо. Репликалар жөнүндө отчеттор эмне үчүн репликациянын өзүнөн көз каранды экенин түшүнбөйм. Мага отчёттор окулуп, репликация жазылып жаткандай сезилди.
Кайталоо конфликтинин себеби эмнеде? Бизде процесстер жүрүп жаткан Устат бар. Бизде машинаны вакуумдоо иштери жүрүп жатат. Автовакуум чындыгында эмне кылат? Ал кээ бир эски сызыктарды кесип жатат. Эгерде ушул убакта бизде ушул эски саптарды окуган репликага суроо-талап бар болсо жана Мастерде автовакуум бул саптарды кайра жазуу үчүн мүмкүн болушунча белгилеп койгон жагдай пайда болсо, анда биз аларды кайра жаздык. Жана биз маалымат пакетин алдык, репликада сурам керек болгон саптарды кайра жазышыбыз керек болгондо, репликация процесси сиз конфигурациялаган күтүү убактысын күтөт. Анан PostgreSQL ага эмне маанилүүрөөк экенин чечет. Ал үчүн сурамга караганда репликация маанилүү жана ал репликага бул өзгөртүүлөрдү киргизүү үчүн сурамды тартат.
Андрей, менин суроом бар. Презентация учурунда көрсөткөн бул сонун графиктер, бул сиздин кандайдыр бир пайдалуу ишиңиздин натыйжасыбы? Графиктер кандайча түзүлдү?
Бул кызмат .
Бул коммерциялык продуктпу?
Ооба. Бул коммерциялык продукт.
Source: www.habr.com