Өз баяндамасында Андрей Бородин сизге байланыш пулаторун долбоорлоодо PgBouncer масштабын кеңейтүү тажрыйбасын кантип эске алышканын айтып берет , Алар аны өндүрүшкө киргизген. Мындан тышкары, биз жаңы версияларда тарткычтын кандай функцияларын көргүбүз келерин талкуулайбыз: бул биз үчүн керектөөлөрүбүздү канааттандыруу гана эмес, колдонуучулар коомчулугун өнүктүрүү үчүн маанилүү. .
Videos:
Баарына салам! Менин атым Андрей.
Яндексте мен ачык булактуу маалымат базаларын иштеп чыгам. Ал эми бүгүн бизде байланыш пулузер байланыштары жөнүндө тема бар.
Эгер сиз орусча байланыш пулаторун кантип чакырууну билсеңиз, анда мага айтыңыз. Мен чындап эле техникалык адабиятта белгилениши керек болгон жакшы техникалык терминди тапкым келет.
Тема абдан татаал, анткени көптөгөн маалымат базаларында туташуу пулатору орнотулган жана ал жөнүндө билүүнүн деле кереги жок. Албетте, бардык жерде кээ бир жөндөөлөр бар, бирок Postgresте андай иштебейт. Жана параллелдүү (HighLoad++ 2019да) Николай Самохваловдун Postgres'те сурамдарды орнотуу жөнүндө отчету бар. Мен түшүнгөндөй, бул жерге өз сурамдарын эң сонун конфигурациялаган адамдар келишкен жана булар тармакка жана ресурстарды колдонууга байланыштуу системалык сейрек кездешүүчү көйгөйлөргө туш болгон адамдар. Ал эми кээ бир жерлерде проблемалар ачык-айкын эмес деген мааниде абдан кыйын болушу мүмкүн.
Яндексте Postgres бар. Көптөгөн Yandex кызматтары Yandex.Cloud'та жашайт. Ал эми бизде Postgresте секундасына кеминде миллион суроону жараткан бир нече петабайт маалыматтар бар.
Жана биз бардык кызматтар үчүн кыйла стандарттуу кластерди камсыздайбыз - бул түйүндүн негизги негизги түйүнү, кадимки эки реплика (синхрондуу жана асинхрондуу), резервдик көчүрүү, репликада окуу сурамдарын масштабдоо.
Ар бир кластер түйүнү Postgres болуп саналат, анда Postgres жана мониторинг тутумдарынан тышкары, байланыш пулатору орнотулган. Connection pooler тосмо үчүн жана анын негизги максаты үчүн колдонулат.
Connection poolerдин негизги максаты эмнеде?
Postgres маалымат базасы менен иштөөдө процесс моделин кабыл алат. Бул бир туташуу бир процесс, бир Postgres backend экенин билдирет. Жана бул бэкэндде ар кандай кэштер бар, аларды ар кандай байланыштар үчүн ар кандай кылуу абдан кымбат.
Мындан тышкары, Postgres кодунда procArray деп аталган массив бар. Бул тармак байланыштары жөнүндө негизги маалыматтарды камтыйт. Жана дээрлик бардык procArray иштетүү алгоритмдери сызыктуу татаалдыкка ээ; алар тармактык байланыштардын бардык массивинде иштейт. Бул абдан тез цикл, бирок көбүрөөк кирүүчү тармак байланыштары менен нерселер бир аз кымбатыраак болот. Ал эми нерселер бир аз кымбаттаганда, сиз көптөгөн тармактык байланыштар үчүн абдан кымбат бааны төлөй аласыз.
3 мүмкүн болгон ыкмалар бар:
- Колдонмо тарапта.
- Маалымат базасы тарабында.
- Жана ортосунда, башкача айтканда, ар кандай комбинациялар.
Тилекке каршы, орнотулган пулдаткыч учурда иштелип чыгууда. Биздин PostgreSQL Professionalдагы досторубуз муну көбүнчө жасашат. Качан пайда болорун алдын ала айтуу кыйын. Ал эми чындыгында, бизде архитектор үчүн эки чечим бар. Булар колдонмо тараптагы бассейн жана прокси бассейн.
Колдонмо тараптагы бассейн эң оңой жолу. Жана дээрлик бардык кардар драйверлери сизге бир жолду сунушташат: миллиондогон байланыштарыңызды маалымат базасына бир нече ондогон байланыштар түрүндө код менен көрсөтүңүз.
Пайда болгон көйгөй, белгилүү бир учурда сиз серверди масштабдагыңыз келсе, аны көптөгөн виртуалдык машиналарга жайылтууну каалайсыз.
Андан кийин сизде дагы бир нече жеткиликтүүлүк зоналары, бир нече маалымат борборлору бар экенин түшүнөсүз. Ал эми кардар тарапты бириктирүү ыкмасы көп санга алып келет. Ирилери 10 000ге жакын байланышты түзөт. Бул нормалдуу иштей турган чети.
Эгерде прокси-пулерлер жөнүндө сөз кыла турган болсок, анда көп нерсени жасай алган эки пулчу бар. Алар жөн гана бассейнчилер эмес. Алар бассейндер + дагы сонун функциялар. Бул и .
Бирок, тилекке каршы, бул кошумча функция бардыгына керек эмес. Жана бул пулерлердин сеанстарды бириктирүүнү гана колдошуна алып келет, б.а. бир кирүүчү кардар, маалымат базасына бир чыгуучу кардар.
Бул биздин максаттарыбыз үчүн анча ылайыктуу эмес, андыктан транзакцияларды бириктирүүнү ишке ашырган PgBouncerти колдонобуз, б.а. сервердик туташуулар транзакциянын узактыгы үчүн гана кардар байланыштарына дал келет.
Ал эми биздин жумушубузда бул чындык. Бирок бир нече көйгөйлөр бар.
Көйгөйлөр сиз сессияга диагноз коюуну каалаганда башталат, анткени сиздин бардык кирүүчү байланыштарыңыз жергиликтүү. Ар бир адам лупа менен келишти жана кандайдыр бир жол менен сессияны байкоо кыйын болуп калат.
Албетте, application_name_add_host колдоно аласыз. Бул Bouncer тарабында application_name'ге IP дарегин кошуунун жолу. Бирок application_name кошумча туташуу аркылуу орнотулган.
Бул графикте сары сызык чыныгы суроо-талаптар, ал эми көк сызык маалымат базасына учкан суроо-талаптар. Жана бул айырма так приложения_name орнотуу болуп саналат, ал издөө үчүн гана керек, бирок ал такыр бекер эмес.
Кошумчалай кетсек, Bouncerде сиз бир бассейнди, башкача айтканда, белгилүү бир колдонуучуга, белгилүү бир маалымат базасына маалымат базасына туташуулар санын чектей албайсыз.
Бул эмнеге алып келет? Сизде C++ тилинде жазылган жүктөлгөн кызмат жана жакын жерде маалымат базасы менен эч кандай коркунучтуу нерсе кылбаган түйүндө кичинекей кызмат бар, бирок анын драйвери жинди болуп калат. Ал 20 000 байланышты ачат, калганынын баары күтөт. Жада калса сиздин кодуңуз нормалдуу.
Биз, албетте, Bouncer үчүн чакан патч жаздык, ал бул жөндөөнү кошкон, б.а. бассейнге кардарларды чектөө.
Муну Postgres тарабында кылса болот, б.а., маалымат базасындагы ролдорду байланыштардын саны менен чектейт.
Бирок анда эмне үчүн серверге эч кандай байланышыңыз жок экенин түшүнүү мүмкүнчүлүгүн жоготосуз. PgBouncer туташуу катасын чыгарбайт, ал ар дайым ошол эле маалыматты кайтарып берет. Жана сиз түшүнө албайсыз: балким сиздин паролуңуз өзгөргөн, балким, маалымат базасы жаңы эле жоголуп кеткендир, балким, бир нерсе туура эмес. Бирок эч кандай диагноз жок. Сеанс түзүлбөсө, анда эмне үчүн аны түзүү мүмкүн эмес экенин билбей каласыз.
Белгилүү бир учурда, сиз колдонмонун графиктерин карап, колдонмо иштебей жатканын көрөсүз.
Жогору жагын караңыз жана Bouncer бир жиптүү экенин көрүңүз. Бул кызматтын жашоосундагы бурулуш учур. Сиз бир жарым жылдын ичинде маалымат базасын кеңейтүүгө даярданып жатканыңызды түшүндүңүз жана бассейнди масштабдашыңыз керек.
Биз көбүрөөк PgBouncers керек деген жыйынтыкка келдик.
Bouncer бир аз жаңыланган.
Жана алар муну TCP портун кайра колдонуу менен бир нече Bouncers көтөрүлө тургандай кылып жасашкан. Ал эми операциялык система автоматтык түрдө алардын ортосундагы TCP байланыштарын тегерек-робин аркылуу өткөрүп берет.
Бул кардарлар үчүн ачык, башкача айтканда, сизде бир Bouncer бар окшойт, бирок сизде Bouncers иштеткендердин ортосунда бош байланыштар бар.
Жана белгилүү бир учурда сиз бул 3 Bouncer ар бири өз өзөгүн 100% жеп жатканын байкасаңыз болот. Сизге бир нече Bouncer керек. Неге?
Анткени сизде TLS бар. Сизде шифрленген байланыш бар. Эгер сиз Postgres'ти TLS менен жана TLSсиз салыштырып көрсөңүз, шифрлөө иштетилгенде орнотулган байланыштардын саны дээрлик эки даражага азайганын көрөсүз, анткени TLS кол алышуусу CPU ресурстарын керектейт.
Ал эми жогору жагында сиз кирүүчү байланыштардын толкуну болгондо аткарылуучу бир нече криптографиялык функцияларды көрө аласыз. Биздин негизги жеткиликтүүлүк зоналарынын ортосунда которушу мүмкүн болгондуктан, кирүүчү байланыштардын толкуну - бул кыйла типтүү жагдай. Башкача айтканда, кандайдыр бир себептерден улам эски баштапкы жеткиликсиз болуп, бүт жүк башка маалымат борборуна жөнөтүлгөн. Алардын баары бир эле учурда TLS менен салам айтууга келишет.
Көптөгөн TLS кол алышуулары мындан ары Bouncer менен саламдашпай калышы мүмкүн, бирок анын кекиртегин кысып калат. Тайм-ауттан улам, кирүүчү байланыштардын толкуну өчүп калышы мүмкүн. Эгерде сиз базага экспоненциалдык артка чегинбестен кайра аракет кылсаңыз, алар когеренттүү толкунда кайра-кайра келбейт.
Бул жерде 16 өзөктү 16% жүктөй турган 100 PgBouncers мисалы.
Биз PgBouncer каскадына келдик. Бул Bouncer менен жүктөй турган эң жакшы конфигурация. Биздин тышкы Bouncers TCP кол алышуу үчүн колдонулат, ал эми ички Bouncers тышкы байланыштарды өтө көп үзгүлтүккө учуратпоо үчүн, чыныгы бириктирүү үчүн колдонулат.
Бул конфигурацияда жылмакай кайра баштоо мүмкүн. Сиз бул 18 Боунсердин баарын бирден кайра иштете аласыз. Бирок мындай конфигурацияны сактоо абдан кыйын. Системалык башкаруучулар, DevOps жана чындыгында бул сервер үчүн жооптуу адамдар бул макулдашууга анча ыраазы болушпайт.
Биздин бардык жакшыртуубузду ачык булакка илгерилетүү мүмкүн окшойт, бирок Bouncer анча жакшы колдоого алынбайт. Мисалы, бир портто бир нече PgBouncers иштетүү мүмкүнчүлүгү бир ай мурун жасалган. Бул функция менен тартуу өтүнүчү бир нече жыл мурун болгон.
Же дагы бир мисал. Postgres'те сиз сырды керексиз аутентификациясыз башка туташууга жөнөтүү менен аткарылып жаткан сурамды жокко чыгара аласыз. Бирок кээ бир кардарлар жөн гана TCP баштапкы абалга келтирүүнү жөнөтүшөт, б.а. алар тармак байланышын үзүшөт. Bouncer эмне кылат? Ал эч нерсе кылбайт. Ал өтүнүчтү аткарууну улантат. Эгер сиз кичинекей суроо-талаптар менен маалымат базасын түзгөн көп сандагы байланыштарды алган болсоңуз, анда Bouncerден туташууну жөн эле ажыратып коюу жетишсиз болот, ошондой эле маалымат базасында иштеп жаткан сурамдарды аягына чыгарышыңыз керек.
Бул такталган жана бул көйгөй азырынча Bouncer's upstream менен бириктирилген эмес.
Ошентип, биз өзүбүздүн байланыш пулаторубуз керек деген тыянакка келдик, ал иштелип чыгат, түзүлөт, анда көйгөйлөр тез арада оңдолот жана, албетте, көп жиптүү болушу керек.
Биз негизги милдет катары көп агымды койдук. Кирүүчү TLS байланыштарынын толкунун жакшы чече билишибиз керек.
Бул үчүн биз Machinarium деп аталган өзүнчө китепкананы иштеп чыгышыбыз керек болчу, ал тармак туташуунун машиналык абалын ырааттуу код катары сүрөттөөгө арналган. Эгер сиз libpq булак кодун карасаңыз, натыйжаны кайтарып, “Мага кийинчерээк чалыңыз. Азыр менде IO бар, бирок IO жок болгондо процессорго жүк болот." Жана бул көп баскычтуу схема. Тармактык байланыш, адатта, мамлекеттик машина менен сүрөттөлөт. "Эгер мен мурда N өлчөмүндөгү пакеттин аталышын алсам, азыр N байт күтүп жатам", "Эгер мен SYNC пакетин жөнөтсөм, эми натыйжанын метаберилиштери бар пакетти күтүп жатам" сыяктуу көптөгөн эрежелер. Натыйжада лабиринт сызык скандоосуна айландырылган сыяктуу, кыйла татаал, карама-каршы код болуп саналат. Биз муну мамлекеттик машинанын ордуна программист кадимки императивдик код түрүндө өз ара аракеттенүүнүн негизги жолун сүрөттөшү үчүн жасадык. Болгону, бул императивдик кодго сиз тармактан маалыматтарды күтүп, аткаруу контекстин башка корутинге (жашыл жип) өткөрүп, аткаруу ырааттуулугу үзгүлтүккө учурашы керек болгон жерлерди киргизишиңиз керек. Бул ыкма лабиринтте эң күтүлгөн жолду катарга жазып, анан ага бутактарды кошконубузга окшош.
Натыйжада, бизде TCP кабыл алган бир жип бар жана тегерек-робин TPC байланышын көптөгөн жумушчуларга өткөрүп берет.
Бул учурда, ар бир кардар байланышы дайыма бир процессордо иштейт. Жана бул аны кэш-достук кылууга мүмкүндүк берет.
Мындан тышкары, системанын TCP стекинен бошотуу үчүн биз кичинекей пакеттерди бир чоң пакетке чогултууну бир аз жакшырттык.
Кошумчалай кетсек, биз транзакцияларды бириктирүүнү жакшырттык, анткени Odyssey конфигурацияланганда, тармак туташуусу үзгүлтүккө учураганда ЖОГОРУЛАТУУ жана КАЙТАРУУ жөнөтө алат, б.а., эгерде эч ким суроону күтпөсө, Одиссей маалымат базасына аракет кылбасын дейт. баалуу ресурстарды текке кетириши мүмкүн болгон өтүнүчтү аткаруу.
Жана мүмкүн болушунча, биз бир эле кардар менен байланышты сактап турабыз. Бул application_name_add_hostту кайра орнотууну болтурбайт. Эгер бул мүмкүн болсо, анда диагностика үчүн зарыл болгон параметрлерди кошумча баштапкы абалга келтирүүнүн кереги жок.
Биз Yandex.Cloud кызыкчылыгында иштейбиз. Эгер сиз башкарылган PostgreSQLди колдонсоңуз жана туташуу пулатору орнотулган болсо, сиз логикалык репликацияны сыртка түзө аласыз, б.а., эгер кааласаңыз, логикалык репликацияны колдонуу менен бизди калтырыңыз. Bouncer сырттан логикалык репликация агымын чыгарбайт.
Бул логикалык репликацияны орнотуунун мисалы.
Мындан тышкары, биз сырткы физикалык кайталоо үчүн колдоо бар. Булутта, албетте, бул мүмкүн эмес, анткени анда кластер өзү жөнүндө өтө көп маалымат берет. Бирок орнотууларыңызда, эгер сизге Одиссейдеги туташуу пулатору аркылуу физикалык репликация керек болсо, бул мүмкүн.
Odyssey PgBouncer менен толук шайкеш мониторингге ээ. Бизде дээрлик бардык бирдей буйруктарды аткарган бир эле консол бар. Эгер бир нерсе жок болсо, тартуу өтүнүчүн жөнөтүңүз, же жок эле дегенде, GitHub боюнча маселени жөнөтүңүз, биз керектүү буйруктарды аткарабыз. Бирок бизде PgBouncer консолунун негизги функциялары бар.
Жана, албетте, бизде каталарды жөнөтүү бар. Биз маалымат базасы кабарлаган катаны кайтарып беребиз. Сиз эмне үчүн базага кирбей калганыңыз тууралуу маалымат аласыз, бирок сиз ага кирбейсиз.
PgBouncer менен 100% шайкештик керек болсо, бул функция өчүрүлгөн. Биз жөн гана коопсуз тарапта болуу үчүн, Bouncer сыяктуу эле мамиле кыла алабыз.
дизайн
Одиссей булак коду жөнүндө бир нече сөз.
Мисалы, "Пауза / Улантуу" буйруктары бар. Алар көбүнчө маалымат базасын жаңыртуу үчүн колдонулат. Эгер сиз Postgresти жаңыртышыңыз керек болсо, анда аны туташуу пулаторунда тындырып, pg_upgrade кылып, андан кийин улантсаңыз болот. Ал эми кардар тарабынан бул маалымат базасы жөн эле жайлап жаткандай көрүнөт. Бул функцияны бизге коомчулуктун адамдары алып келишкен. Ал дагы эле тоңгон жок, бирок жакында баары болот. (Тоңуп калган)
- уже тоңуп калган
Кошумчалай кетсек, PgBouncerдеги жаңы функциялардын бири - бул SCRAM аутентификациясын колдоо, аны бизге Yandex.Cloud'та иштебеген адам алып келген. Экөө тең татаал функция жана маанилүү.
Ошондуктан, мен сизге Одиссей эмнеден жасалганын айткым келет, эгер сиз да азыр бир аз код жазгыңыз келсе.
Сизде эки негизги китепканага таянган Odyssey булак базасы бар. Kiwi китепкана Postgres билдирүү протоколунун ишке ашыруу болуп саналат. Башкача айтканда, Postgresтин жергиликтүү прото 3 - бул алдыңкы жана арткы аягы алмаша турган стандарттык билдирүүлөр. Алар киви китепканасында ишке ашырылат.
Machinarium китепканасы жипти ишке ашыруу китепканасы. Бул машинанын кичинекей фрагменти ассемблер тилинде жазылган. Бирок кооптонбогула, болгону 15 сап бар.
Одиссей архитектурасы. Корутиндер иштеп жаткан негизги машина бар. Бул машина келген TCP байланыштарын кабыл алып, жумушчулардын арасында бөлүштүрөт.
Бир нече кардарлар үчүн иштеткич бир жумушчунун ичинде иштей алат. Негизги жип ошондой эле консолду иштетет жана бассейнде кереги жок болгон байланыштарды жок кылуу үчүн крон тапшырмаларын иштетет.
Odyssey стандарттуу Postgres тест топтомун колдонуу менен сыналган. Биз жөн гана Bouncer жана Odyssey аркылуу орнотуу-текшерүүнү иштетебиз, биз нөлдүк div алабыз. Датаны форматтоого байланыштуу бир нече тесттер бар, алар Bouncer менен Одиссейде так бирдей өтпөйт.
Мындан тышкары, көптөгөн айдоочулар өздөрүнүн тестирлөөсү бар. Жана биз Одиссеяны сыноо үчүн алардын тесттерин колдонобуз.
Мындан тышкары, каскаддык конфигурациябыздан улам, биз ар кандай таңгактарды сынап көрүшүбүз керек: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, эгерде Одиссей каскаддын кайсы бир бөлүгүндө болсо, ал дагы деле иштейт деп ишенүү үчүн. биз күткөндөй.
Рейк
Биз өндүрүштө Odyssey колдонобуз. Анан баары эле иштейт деп айтсам калыстык болбойт. Жок, ооба, бирок дайыма эмес. Мисалы, өндүрүштө баары жөн эле иштеди, андан кийин PostgreSQL Professionalдан биздин досторубуз келип, эс тутумдун агып кетишин айтышты. Алар чындап эле, биз аларды оңдодук. Бирок бул жөнөкөй эле.
Андан кийин биз байланыш пулаторунун кирүүчү TLS байланыштары жана чыгуучу TLS байланыштары бар экенин аныктадык. Жана туташуулар кардар тастыктамаларын жана сервер сертификаттарын талап кылат.
Bouncer жана Odyssey серверинин сертификаттары алардын pcache тарабынан кайра окулат, бирок кардар сертификаттарын pcache'ден кайра окуунун кереги жок, анткени масштабдуу Odyssey акырында бул сертификатты окуу тутумунун иштешине кирет. Бул биз үчүн күтүүсүз болду, анткени ага каршы турууга көп убакыт талап кылынган жок. Башында ал сызыктуу масштабдуу болгон, бирок 20 000 кирген бир эле учурда байланыштардан кийин бул көйгөй өзүн көрсөттү.
Pluggable Authentication Method - бул орнотулган Lunux куралдарын колдонуу менен аутентификациялоо мүмкүнчүлүгү. PgBouncerде ал PAMдан жооп күтө турган өзүнчө жип бар жана учурдагы туташууну тейлеген негизги PgBouncer жип бар жана алардан PAM жипинде жашоону сурай тургандай ишке ашырылат.
Биз муну бир жөнөкөй себеп менен ишке ашырган жокпуз. Бизде жиптер көп. Бул бизге эмне үчүн керек?
Бул акыр аягында көйгөйлөрдү жаратышы мүмкүн, анткени сизде PAM аутентификациясы жана PAM эмес аутентификация болсо, анда PAM аутентификациясынын чоң толкуну PAM эмес аутентификацияны олуттуу кечеңдетет. Бул биз оңдой элек нерселердин бири. Бирок, эгер сиз аны оңдоону кааласаңыз, муну кыла аласыз.
Дагы бир тырмоо, бизде бардык кирүүчү байланыштарды кабыл алган бир жип бар. Анан алар TLS кол алышуу боло турган жумушчу бассейнине которулат.
Жыйынтыктап айтканда, эгер сизде 20 000 тармактык туташуунун когеренттүү толкуну болсо, алардын баары кабыл алынат. Ал эми кардар тарабында libpq тайм-ауттарды билдире баштайт. Демейки боюнча бул 3 секунд окшойт.
Эгерде алардын баары бир эле учурда маалымат базасына кире албаса, анда алар маалымат базасына кире алышпайт, анткени мунун бардыгы экспоненциалдык эмес кайра аракет менен камтылат.
Биз PgBouncerден схеманы көчүрүп алдык деген жыйынтыкка келдик, анткени биз кабыл алган TCP туташууларынын санын азайттык.
Эгер биз туташууларды кабыл алып жатканыбызды көрсөк, бирок алар кол алышууга убакыт жок болсо, анда CPU ресурстарын текке кетирбөө үчүн аларды кезекке коёбуз. Бул бир эле учурда кол алышуу бардык келген байланыштар үчүн аткарылбай калышына алып келет. Бирок, жок эле дегенде, кимдир бирөө маалымат базасына кирет, жүк абдан оор болсо да.
жол картасы
Одиссейде келечекте эмнени көргүңүз келет? Биз өзүбүздү өнүктүрүүгө эмне даярбыз жана коомчулуктан эмнени күтөбүз?
2019-жылдын августуна карата.
Август айында Одиссей жол картасы ушундай болгон:
- Биз SCRAM жана PAM аутентификациясын каалаганбыз.
- Биз окуу сурамдарын күтүү режимине жөнөткүбүз келди.
- Мен онлайн кайра баштоону каалайм.
- Жана серверде тыныгуу мүмкүнчүлүгү.
Бул жол картасынын жарымы бүттү, биз тараптан эмес. Бул дагы жакшы. Анда эмне калганын талкуулап, дагы кошумчалайлы.
? Бизде сурамдарды аткарбастан эле абаны жылыта турган репликалар бар. Аларды иштен чыгарууну жана которууну камсыз кылуу учун бизге керек. Маалымат борборлорунун биринде көйгөйлөр жаралса, мен аларды пайдалуу иш менен алгым келет. Анткени биз бир эле борбордук процессорлорду, бир эле эстутумду башкача конфигурациялай албайбыз, анткени антпесе репликация иштебейт.
Негизи, Postgresте 10дон баштап, туташуу учурунда session_attrs көрсөтүүгө болот. Туташуудагы бардык база хостторун тизмелеп, эмне үчүн маалымат базасына бара жатканыңызды айта аласыз: жазыңыз же окуу гана. Ал эми айдоочу өзү тизмеден эң жакшы көргөн, session_attrs талаптарын аткарган биринчи хостту тандап алат.
Бирок бул ыкманын көйгөйү репликациянын артта калышын көзөмөлдөбөйт. Сизде кызматыңыз үчүн кабыл алынгыс убакыттан артта калган кээ бир реплика болушу мүмкүн. Репликада окуу сурамдарын толук функциялуу аткарууну иштетүү үчүн, биз негизинен Одиссейдин окулбай калганда иштебей турган жөндөмүн колдоого алышыбыз керек.
Одиссей мезгил-мезгили менен маалымат базасына кирип, негизгиден репликация аралыкты сурашы керек. Ал эми чектик мааниге жеткен болсо, маалымат базасына жаңы суроо-талаптарга жол бербеңиз, кардарга байланыштарды кайра баштоо керек экендигин айтыңыз жана, балким, суроо-талаптарды аткаруу үчүн башка хостту тандаңыз. Бул маалымат базасына репликациянын артта калышын тез калыбына келтирүүгө жана сурам менен жооп берүү үчүн кайра кайтып келүүгө мүмкүндүк берет.
Бул ачык булак болгондуктан, ишке ашыруу үчүн мөөнөт берүү кыйын. Бирок, PgBouncerдеги кесиптештерим сыяктуу 2,5 жыл эмес деп үмүттөнөм. Бул мен Одиссеяда көргүм келген өзгөчөлүк.
. Эми сиз эки жол менен даярдалган билдирүү түзө аласыз. Биринчиден, сиз SQL буйругун аткара аласыз, тактап айтканда "даярдалган". Бул SQL буйругун түшүнүү үчүн, биз Bouncer тарабында SQLди түшүнүүнү үйрөнүшүбүз керек. Бул ашыкча болмок, анткени бул ашыкча, анткени бизге бүт талдоочу керек. Биз ар бир SQL буйругун талдай албайбыз.
Бирок proto3 боюнча билдирүү протоколунун деңгээлинде даярдалган билдирүү бар. Жана бул жерде даярдалган билдирүү түзүлүп жаткандыгы тууралуу маалымат структураланган формада келет. Жана биз кандайдыр бир сервердик байланышта кардар даярдалган билдирүүлөрдү түзүүнү суранганын түшүнө алабыз. Жана транзакция жабылса дагы, биз сервер менен кардар ортосундагы байланышты сактап турушубуз керек.
Бирок бул жерде диалогдо дал келбестик пайда болот, анткени кимдир бирөө сиз кардар кандай даярдалган билдирүүлөрдү түзгөнүн түшүнүшүңүз керек жана бул сервердик байланышты түзгөн бардык кардарлардын ортосунда сервердик байланышты бөлүшүү керек дейт, б.а., мындай даярдалган билдирүүнү түзгөн.
Андрес Фрейнд эгер сизге башка сервер байланышында ушундай даярдалган билдирүүнү түзгөн кардар келсе, анда аны ал үчүн түзүңүз. Бирок кардардын ордуна маалымат базасында суроо-талаптарды аткаруу бир аз туура эмес окшойт, бирок маалымат базасы менен өз ара аракеттенүү үчүн протоколду жазган иштеп чыгуучунун көз карашы боюнча, ага жөн эле тармак туташуусу берилсе, ыңгайлуу болмок. ушундай даярдалган өтүнүч бар.
Жана дагы бир өзгөчөлүк, биз ишке ашыруу керек. Бизде азыр PgBouncer менен шайкеш мониторинг бар. Биз суроо-талаптарды аткаруунун орточо убактысын кайтара алабыз. Бирок орточо убакыт ооруканадагы орточо температура: кээ бирлери суук, кээ бирлери жылуу - орто эсеп менен бардыгы дени сак. Бул туура эмес.
Биз ресурстарды текке кетирип жаткан жай сурамдардын бар экенин көрсөтүп, мониторингди алгылыктуу кыла турган пайыздык көрсөткүчтөрдү колдоону ишке ашыруубуз керек.
Эң негизгиси, мен 1.0 версиясын каалайм (1.1 версиясы мурунтан эле чыгарылган). Чындыгында, Odyssey азыр 1.0rc версиясында, башкача айтканда, талапкерди чыгарууда. Жана мен санаган бардык көйгөйлөр, эс тутумдун агып кетишинен башка, дал ошол версия менен чечилди.
1.0 версиясы биз үчүн эмнени билдирет? Биз базаларыбызга Одиссеяны чыгарып жатабыз. Ал мурунтан эле биздин маалымат базаларыбызда иштеп жатат, бирок ал секундасына 1 000 000 суроо-талапка жеткенде, бул релиз версиясы деп айта алабыз жана бул 1.0 деп атоого болот.
Коомчулуктагы бир нече адамдар 1.0 версиясында тыныгуу жана SCRAM камтылышын сурашкан. Бирок бул биз кийинки версияны өндүрүшкө чыгарышыбыз керек дегенди билдирет, анткени SCRAM да, пауза дагы жок боло элек. Бирок, кыязы, бул маселе абдан тез чечилет.
Мен сиздин кайрылууңузду күтөм. Мен Bouncer менен кандай көйгөйлөрүңүз бар экенин уккум келет. Келгиле, аларды талкуулайлы. Балким, биз сизге керектүү функцияларды ишке ашыра алабыз.
Бул менин бөлүгүм аяктады, мен сизди уккум келет. Рахмат!
суроолор
Эгерде мен өзүмдүн колдонмомдун_атын орнотсом, ал Одиссейдеги транзакцияларды бириктирүү менен кошо туура багытталабы?
Одиссей же Боунсер?
Одиссейде. Bouncerде ал ыргытылат.
Биз комплект жасайбыз.
Ал эми менин чыныгы байланышым башка байланыштарга секирип кетсе, ал берилеби?
Биз тизмеде көрсөтүлгөн бардык параметрлердин топтомун жасайбыз. Бул тизмеде application_name бар же жок экенин айта албайм. Мен аны ошол жерден көрдүм окшойт. Биз бардык эле параметрлерди орнотобуз. Бир өтүнүч менен, топтом ишке киргизүү учурунда кардар орноткон нерселердин баарын жасайт.
Репортаж үчүн рахмат, Андрей! Жакшы отчет! Одиссей мүнөт сайын тез жана тез өнүгүп жатканына кубанычтамын. Мен ушинтип уланткым келет. Одиссей бир эле учурда ар кандай маалымат базаларына, б.а. башкы кулга туташып, андан кийин иштен чыккандан кийин жаңы мастерге автоматтык түрдө туташа алышы үчүн, биз сизден көп маалымат булагы байланышын сураганбыз.
Ооба, бул талкуу эсимде калды окшойт. Азыр бир нече кампалар бар. Бирок алардын ортосунда эч кандай алмашуу жок. Биздин тарапта, биз серверди ал дагы эле тирүү деп сурашыбыз керек жана pg_recovery деп атаган иштебей калуу болгонун түшүнүшүбүз керек. Биз агайга келген жокпуз деп менде стандарттуу түшүнүк бар. Жана каталардан кандайдыр бир жол менен түшүнүшүбүз керекпи же эмне? Айтор, идея кызыктуу, талкууланып жатат. Дагы комментарий жазыңыз. Эгерде сизде C тилин билген жумушчуларыңыз болсо, анда бул жалпысынан сонун.
Репликалар боюнча масштабдоо маселеси бизди да кызыктырат, анткени биз тиркемени иштеп чыгуучулар үчүн репликацияланган кластерлерди кабыл алууну мүмкүн болушунча жөнөкөй кылгыбыз келет. Бирок бул жерде мен дагы комментарийлерди айткым келет, башкача айтканда, аны кантип жасоо керек, кантип жакшы кылуу керек.
Суроо репликалар жөнүндө да. Көрсө, сизде мастер жана бир нече реплика бар экен. Жана алар туташуу үчүн кожоюнга караганда репликага азыраак барары анык, анткени аларда айырмачылыктар болушу мүмкүн. Сиз маалыматтардагы айырмачылык сиздин бизнесиңизди канааттандырбай тургандай болушу мүмкүн деп айттыңыз жана ал кайталанмайынча ал жакка барбайсыз. Ошол эле учурда, эгерде сиз ал жакка көпкө барбай, анан бара баштасаңыз, анда керектүү маалыматтар дароо жеткиликтүү болбойт. Башкача айтканда, биз дайыма мастерге барсак, анда кэш жылыйт, бирок репликада кэш бир аз артта калат.
Ооба бул чындык. Pcache сиз каалаган маалымат блокторуна ээ болбойт, чыныгы кэште сиз каалаган таблицалар жөнүндө маалымат болбойт, пландарда талданган сурамдар болбойт, эч нерсе болбойт.
Жана сизде кандайдыр бир кластер болгондо жана ал жерге жаңы репликаны кошсоңуз, анда ал башталганда, анда баары начар, башкача айтканда, анын кэшин көбөйтөт.
Мен идеяны алдым. Туура ыкма, биринчиден, репликада сурамдардын аз пайызын иштетүү, бул кэшти жылытат. Болжол менен айтканда, бизде устаттан 10 секунддан ашык артта калуу шарты бар. Жана бул шарт бир толкунга киргизилген эмес, бирок кээ бир кардарлар үчүн жылмакай.
Ооба, салмагын жогорулатуу.
Бул Жакшы ой. Бирок адегенде бул өчүрүүнү ишке ашыруубуз керек. Адегенде өчүрүш керек, анан кантип күйгүзүү жөнүндө ойлонобуз. Бул жылмакай иштетүү үчүн мыкты өзгөчөлүк болуп саналат.
Nginx бул параметрге ээ slowly start сервер үчүн кластерде. Жана ал бара-бара жүктү көбөйтөт.
Ооба, сонун идея, биз аны ишке ашырганыбызда аракет кылабыз.
Source: www.habr.com