Өзінің баяндамасында Андрей Бородин қосылым пулаторын жобалау кезінде PgBouncer масштабтау тәжірибесін қалай ескергенін айтып береді. , олар оны өндіріске енгізген кезде. Сонымен қатар, біз жаңа нұсқаларда тартқыштың қандай функцияларын көргіміз келетінін талқылаймыз: бұл біз үшін тек біздің қажеттіліктерімізді қанағаттандыру ғана емес, сонымен қатар пайдаланушылар қауымдастығын дамыту үшін маңызды. .
Бейне:
Бәріңе сәлем! Менің атым Андрей.
Яндексте мен ашық бастапқы дерекқорларды әзірлеймін. Ал бүгін бізде қосылым пульері қосылымдары туралы тақырып бар.
Қосылым пульері орыс тілінде қалай шақырылатынын білсеңіз, айтыңыз. Мен техникалық әдебиетте белгіленуі керек жақсы техникалық терминді тапқым келеді.
Тақырып өте күрделі, өйткені көптеген дерекқорларда қосылым пульері кіріктірілген және бұл туралы білудің де қажеті жоқ. Әрине, барлық жерде кейбір параметрлер бар, бірақ Postgres-те олай жұмыс істемейді. Сонымен қатар (HighLoad++ 2019) Николай Самохваловтың Postgres-те сұрауларды орнату туралы есебі бар. Менің түсінуімше, мұнда өздерінің сұрауларын тамаша конфигурациялаған адамдар келді, бұл желі мен ресурстарды пайдаланумен байланысты сирек кездесетін жүйелік мәселелерге тап болған адамдар. Ал кейбір жерлерде проблемалар анық емес деген мағынада өте қиын болуы мүмкін.
Yandex-те Postgres бар. Көптеген Яндекс қызметтері Yandex.Cloud жүйесінде жұмыс істейді. Бізде Postgres-те секундына кемінде миллион сұрау жасайтын бірнеше петабайт деректер бар.
Және біз барлық қызметтер үшін жеткілікті стандартты кластерді қамтамасыз етеміз - бұл түйіннің негізгі бастапқы түйіні, әдеттегі екі реплика (синхронды және асинхронды), резервтік көшірме, репликада оқу сұраныстарын масштабтау.
Әрбір кластер түйіні Postgres болып табылады, оған Postgres және бақылау жүйелерінен басқа қосылым пульері де орнатылған. Қосылу пульері қоршау үшін және оның негізгі мақсаты үшін қолданылады.
Қосылым пулаторының негізгі мақсаты қандай?
Postgres мәліметтер қорымен жұмыс істеу кезінде процесс үлгісін қабылдайды. Бұл бір қосылым бір процесс, бір Postgres сервері екенін білдіреді. Және бұл серверде көптеген түрлі кэштер бар, оларды әртүрлі қосылымдар үшін әртүрлі ету өте қымбат.
Сонымен қатар, Postgres кодында procArray деп аталатын массив бар. Ол желілік қосылымдар туралы негізгі деректерді қамтиды. Барлық дерлік procArray өңдеу алгоритмдері сызықтық күрделілікке ие, олар желілік қосылымдардың барлық массивінде жұмыс істейді. Бұл өте жылдам цикл, бірақ кіріс желілік қосылымдар көбірек болса, заттар біршама қымбаттайды. Ал заттар сәл қымбаттаған кезде, көптеген желілік қосылымдар үшін өте жоғары баға төлеуге болады.
3 ықтимал тәсіл бар:
- Қолданба жағында.
- Дерекқор жағында.
- Және арасында, яғни комбинациялардың барлық түрлері.
Өкінішке орай, кіріктірілген пулатор қазір әзірленуде. Біздің PostgreSQL Professional-тағы достарымыз мұны негізінен жасайды. Оның қашан пайда болатынын болжау қиын. Ал шын мәнінде, бізде сәулетші таңдау үшін екі шешім бар. Бұл қолданбалық пул және прокси-пул.
Қолданбалы пул - ең оңай жол. Барлық дерлік клиент драйверлері сізге жол береді: миллиондаған қосылымдарыңызды кодта дерекқорға бірнеше ондаған қосылымдар ретінде көрсетіңіз.
Мәселе мынада: белгілі бір сәтте сіз серверді масштабтағыңыз келсе, оны көптеген виртуалды машиналарға орналастырғыңыз келеді.
Сонда сізде тағы бірнеше қолжетімділік аймақтары, бірнеше деректер орталықтары бар екенін түсінесіз. Ал клиенттік біріктіру тәсілі үлкен сандарға әкеледі. Үлкендері - шамамен 10 000 қосылым. Бұл қалыпты жұмыс істей алатын жиек.
Егер прокси-пулерлер туралы айтатын болсақ, онда көп нәрсені жасай алатын екі пулер бар. Олар тек бассейншілер емес. Олар бассейндер + керемет функционалдылық. Бұл и .
Бірақ, өкінішке орай, бұл қосымша функция барлығына қажет емес. Және бұл пулерлердің тек сеансты біріктіруді, яғни бір кіріс клиентін, дерекқорға бір шығыс клиентін қолдайтындығына әкеледі.
Бұл біздің мақсаттарымыз үшін өте қолайлы емес, сондықтан біз транзакцияны біріктіруді жүзеге асыратын PgBouncer пайдаланамыз, яғни сервер қосылымдары транзакцияның ұзақтығына ғана клиенттік қосылымдарға сәйкес келеді.
Ал біздің жұмысымызда бұл шындық. Бірақ аздаған проблемалар бар.
Мәселелер сеансты диагностикалау қажет болғанда басталады, себебі барлық кіріс қосылымдарыңыз жергілікті. Барлығы кері байланыспен келді және қандай да бір түрде сеансты қадағалау қиынға соғады.
Әрине, application_name_add_host пайдалана аласыз. Бұл қолданба_атауына IP мекенжайын қосудың Bouncer жағындағы әдіс. Бірақ application_name қосымша қосылым арқылы орнатылады.
Бұл графикте сары жол нақты сұраулар, ал көк жол дерекқорға ұшатын сұраулар болып табылады. Және бұл ерекшелік - тек қадағалау үшін қажет, бірақ ол мүлдем тегін емес application_name орнату.
Бұған қоса, Bouncer бағдарламасында бір пулды шектей алмайсыз, яғни белгілі бір пайдаланушыға, нақты дерекқорға арналған дерекқор қосылымдарының санын.
Бұл не әкеледі? Сізде C++ тілінде жазылған жүктелген қызмет және жақын жерде дерекқормен ешнәрсе жасамайтын түйінде шағын қызмет бар, бірақ оның драйвері есінен танып қалады. Ол 20 000 қосылымды ашады, қалғанының бәрі күтеді. Тіпті сіздің кодыңыз қалыпты.
Біз, әрине, Bouncer үшін шағын патч жаздык, ол осы параметрді қосқан, яғни клиенттерді бассейнге шектейтін.
Мұны Postgres жағында жасауға болады, яғни дерекқордағы рөлдерді қосылымдар санымен шектеңіз.
Бірақ содан кейін сіз неге серверге қосылымдар жоқ екенін түсіну мүмкіндігін жоғалтасыз. PgBouncer қосылым қатесін жібермейді, ол әрқашан бірдей ақпаратты қайтарады. Сіз түсіне алмайсыз: мүмкін сіздің құпия сөзіңіз өзгерді, мүмкін дерекқор жоғалып кетті, мүмкін бірдеңе дұрыс емес. Бірақ диагнозы жоқ. Сеансты орнату мүмкін болмаса, оның неге орнатылмайтынын білмейсіз.
Белгілі бір сәтте сіз қолданба графиктеріне қарап, қолданба жұмыс істемейтінін көресіз.
Жоғарғы жағына қараңыз және Bouncer бір ағынды екенін көріңіз. Бұл қызмет өміріндегі бетбұрыс. Сіз бір жарым жыл ішінде дерекқорды масштабтауға дайындалып жатқаныңызды түсінесіз және пулаторды масштабтау керек.
Бізге көбірек PgBouncers керек деген қорытындыға келдік.
Bouncer сәл түзетілді.
Және олар мұны TCP портын қайта пайдалану арқылы бірнеше Bouncers көтеруге болатындай етіп жасады. Ал операциялық жүйе кіріс TCP қосылымдарын олардың арасындағы айналымды қолдану арқылы автоматты түрде тасымалдайды.
Бұл клиенттер үшін мөлдір, яғни сізде бір Bouncer бар сияқты көрінеді, бірақ сізде жұмыс істеп тұрған Bouncers арасындағы бос байланыстардың үзіндісі бар.
Белгілі бір сәтте сіз бұл 3 Бонсердің әрқайсысы өз өзегін 100% жейтінін байқайсыз. Сізге бірнеше Бонсер қажет. Неліктен?
Өйткені сізде TLS бар. Сізде шифрланған қосылым бар. Егер сіз Postgres-ті TLS бар және онсыз салыстырсаңыз, шифрлау қосылған кезде орнатылған қосылымдар саны екі рет дерлік төмендейтінін көресіз, себебі TLS қол алысуы процессор ресурстарын тұтынады.
Ал жоғарғы жағында кіріс қосылымдарының толқыны болған кезде орындалатын бірнеше криптографиялық функцияларды көруге болады. Біздің негізгі қол жетімділік аймақтары арасында ауыса алатындықтан, кіріс қосылымдар толқыны әдеттегі жағдай болып табылады. Яғни, қандай да бір себептермен ескі бастапқы қолжетімсіз болды, бүкіл жүктеме басқа деректер орталығына жіберілді. Олардың барлығы бір уақытта TLS-ке сәлем беруге келеді.
Көптеген TLS қол алысулары бұдан былай Боунсерге сәлем айтпауы мүмкін, бірақ оның тамағын қысады. Күтуге байланысты кіріс қосылымдар толқыны сөндірілмеген болуы мүмкін. Егер сіз экспоненциалды кері қайтарусыз негізге қайта әрекет жасасаңыз, олар когерентті толқында қайта-қайта келмейді.
Мұнда 16 ядроны 16% жүктейтін 100 PgBouncer мысалы келтірілген.
Біз PgBouncer каскадына келдік. Бұл Bouncer қолданбасын жүктегенде қол жеткізуге болатын ең жақсы конфигурация. Сыртқы қосылымдарымыз TCP қол алысу үшін пайдаланылады, ал ішкі қосылғыштар сыртқы қосылымдарды тым көп бөлшектемеу үшін нақты біріктіру үшін пайдаланылады.
Бұл конфигурацияда бірқалыпты қайта іске қосуға болады. Сіз барлық осы 18 Бонсерді бір-бірден қайта іске қоса аласыз. Бірақ мұндай конфигурацияны сақтау өте қиын. Sysadmins, DevOps және осы серверге шын мәнінде жауапты адамдар бұл келісімге онша риза болмайды.
Біздің барлық жақсартуларымызды ашық бастапқы кодқа көшіруге болатын сияқты, бірақ Bouncer өте жақсы қолдау көрсетпейді. Мысалы, бір портта бірнеше PgBouncers іске қосу мүмкіндігі бір ай бұрын жасалған. Бірнеше жыл бұрын бұл мүмкіндікті тарту сұрауы болды.
Немесе тағы бір мысал. Postgres бағдарламасында құпияны қажетсіз аутентификациясыз басқа қосылымға жіберу арқылы орындалып жатқан сұраудан бас тартуға болады. Бірақ кейбір клиенттер жай ғана TCP қалпына келтіруді жібереді, яғни олар желі қосылымын үзеді. Bouncer не істейді? Ол ештеңе істемейді. Ол сұрауды орындауды жалғастырады. Егер сіз кішігірім сұраулары бар дерекқорды жасаған қосылымдардың үлкен санын алсаңыз, Bouncer-тен қосылымды ажырату жеткіліксіз болады, сонымен қатар дерекқорда іске қосылған сұрауларды аяқтау қажет.
Бұл түзетілді және бұл мәселе әлі Bouncer's upstream біріктірілген жоқ.
Осылайша, біз әзірленетін, патчталған, проблемаларды тез түзетуге болатын және, әрине, көп ағынды болуы керек болатын жеке қосылым пульері қажет деген қорытындыға келдік.
Біз негізгі міндет ретінде көп ағынды орнатуды қойдық. Біз кіріс TLS қосылымдарының толқынын жақсы басқара білуіміз керек.
Ол үшін желілік қосылымның машиналық күйлерін тізбекті код ретінде сипаттауға арналған Machinarium деп аталатын жеке кітапхананы әзірлеуге тура келді. Егер сіз libpq бастапқы кодын қарасаңыз, нәтижені қайтара алатын және: «Маған кейінірек қоңырау шалыңыз. Дәл қазір менде IO бар, бірақ IO жойылған кезде процессорға жүктеме болады». Және бұл көп деңгейлі схема. Желілік байланыс әдетте күй машинасымен сипатталады. «Егер мен бұрын N өлшемді пакет тақырыбын алсам, енді мен N байт күтемін», «Егер мен SYNC пакетін жіберсем, енді нәтиже метадеректері бар пакетті күтемін» сияқты көптеген ережелер. Нәтиже - лабиринт сызықты сканерлеуге түрлендірілгендей, өте қиын, қарама-қайшы код. Біз оны мемлекеттік машинаның орнына бағдарламашы қарапайым императивті код түрінде өзара әрекеттесудің негізгі жолын сипаттайтындай етіп жасадық. Бұл императивті кодта желіден деректерді күту, орындау контекстін басқа корутинге (жасыл ағын) беру арқылы орындау реті үзілуі керек орындарды енгізу керек. Бұл тәсіл лабиринттегі ең күтілетін жолды қатарға жазып, содан кейін оған бұтақтарды қосатынымызға ұқсас.
Нәтижесінде бізде TCP қабылдайтын және TPC қосылымын көптеген жұмысшыларға өткізетін бір ағын бар.
Бұл жағдайда әрбір клиент қосылымы әрқашан бір процессорда жұмыс істейді. Және бұл оны кэшке ыңғайлы етуге мүмкіндік береді.
Сонымен қатар, жүйе TCP стекін жеңілдету үшін біз шағын пакеттерді бір үлкен пакетке жинауды сәл жақсарттық.
Бұған қоса, біз транзакциялық біріктіруді жетілдірдік, өйткені Odyssey конфигурацияланған кезде желі қосылымы сәтсіз болған жағдайда БАС ТАРТУ және ҚАЙТҚА жіберуді жібере алады, яғни ешкім сұрауды күтпесе, Odyssey дерекқорға әрекет етпеуді айтады. бағалы ресурстарды ысырап етуі мүмкін сұранысты орындау.
Мүмкіндігінше біз бір клиентпен байланыстарды сақтаймыз. Бұл application_name_add_host қайта орнатуды болдырмайды. Егер бұл мүмкін болса, диагностика үшін қажетті параметрлерді қосымша қалпына келтірудің қажеті жоқ.
Біз Yandex.Cloud мүдделері үшін жұмыс істейміз. Егер сіз басқарылатын PostgreSQL қолдансаңыз және қосылым пульері орнатылған болса, сіз сыртқа логикалық репликация жасай аласыз, яғни логикалық репликацияны пайдаланып, қаласаңыз, бізді қалдыра аласыз. Bouncer логикалық репликация ағынын сыртқа шығармайды.
Бұл логикалық репликацияны орнатудың мысалы.
Сонымен қатар, бізде сыртқа физикалық репликацияға қолдау көрсетіледі. Бұлтта, әрине, бұл мүмкін емес, өйткені кластер сізге өзі туралы тым көп ақпарат береді. Бірақ орнатуларыңызда, егер сізге Odyssey жүйесіндегі қосылым пульері арқылы физикалық репликация қажет болса, бұл мүмкін.
Odyssey-де PgBouncer-пен толық үйлесімді мониторинг бар. Бізде бірдей пәрмендерді дерлік орындайтын бірдей консоль бар. Егер бірдеңе жетіспесе, тарту сұрауын немесе кем дегенде GitHub жүйесіндегі мәселені жіберіңіз, біз қажетті пәрмендерді орындаймыз. Бірақ бізде PgBouncer консолінің негізгі функционалдығы бар.
Және, әрине, бізде қателерді жіберу бар. Дерекқор хабарлаған қатені қайтарамыз. Сіз неге дерекқорға қосылмағаныңыз туралы ақпаратты аласыз, сонымен қатар сіз оған қосылмағансыз.
PgBouncer бағдарламасымен 100% үйлесімділік қажет болған жағдайда бұл мүмкіндік өшіріледі. Біз қауіпсіз жағында болу үшін Bouncer сияқты әрекет ете аламыз.
Даму
Одиссейдің бастапқы коды туралы бірнеше сөз.
Мысалы, «Кідірту / Жалғастыру» пәрмендері бар. Олар әдетте дерекқорды жаңарту үшін қолданылады. Егер сізге Postgres жаңарту қажет болса, оны қосылым пулаторында кідіртуге болады, pg_upgrade орындаңыз, содан кейін жалғастырыңыз. Клиент тарапынан дерекқор жай ғана баяулағандай көрінеді. Бұл функцияны бізге қауымдастықтың адамдары әкелді. Ол әлі тоңған жоқ, бірақ көп ұзамай бәрі болады. (қазірдің өзінде мұздатылған)
- қазірдің өзінде мұздатылған
Сонымен қатар, PgBouncer жаңа мүмкіндіктерінің бірі - SCRAM аутентификациясын қолдау, оны бізге Yandex.Cloud-та жұмыс істемейтін адам да әкелді. Екеуі де күрделі функционалды және маңызды.
Сондықтан мен сізге Одиссейдің неден жасалғанын айтқым келеді, егер сіз де қазір аздап код жазғыңыз келсе.
Сізде екі негізгі кітапханаға негізделген Odyssey бастапқы базасы бар. Киви кітапханасы Postgres хабарлама хаттамасын іске асыру болып табылады. Яғни, Postgres-тің 3-ші протосы - алдыңғы және артқы жақтары алмасуға болатын стандартты хабарламалар. Олар киви кітапханасында жүзеге асырылады.
Machinarium кітапханасы ағынды іске асыру кітапханасы болып табылады. Бұл машинаның шағын фрагменті ассемблер тілінде жазылған. Бірақ алаңдамаңыз, бар болғаны 15 жол бар.
Одиссея архитектурасы. Корутиндер жұмыс істейтін негізгі машина бар. Бұл құрылғы кіріс TCP қосылымдарын қабылдауды және оларды жұмысшылар арасында таратуды жүзеге асырады.
Бірнеше клиенттерге арналған өңдеуші бір жұмысшы ішінде жұмыс істей алады. Негізгі ағын сонымен қатар пулда қажет емес қосылымдарды жою үшін консольді және крон тапсырмаларын өңдеуді іске қосады.
Odyssey стандартты Postgres сынақ жинағы арқылы сыналады. Біз жай ғана Bouncer және Odyssey арқылы орнату-тексеруді іске қосамыз, біз нөлдік div аламыз. Күнді пішімдеуге қатысты бірнеше сынақтар бар, олар Bouncer және Odyssey-де бірдей өтпейді.
Сонымен қатар, өз тестілері бар көптеген жүргізушілер бар. Біз олардың сынақтарын Одиссеяны сынау үшін қолданамыз.
Сонымен қатар, біздің каскадтық конфигурацияға байланысты, егер Одиссей каскадтың кез келген бөлігінде аяқталса, ол әлі де жұмыс істейтініне сенімді болу үшін Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey әртүрлі жинақтарын сынауымыз керек. біз күткендей.
Rake
Біз өндірісте Odyssey-ді қолданамыз. Ал егер бәрі жай ғана жұмыс істейді десем, әділ болмас еді. Жоқ, иә, бірақ әрқашан емес. Мысалы, өндірісте бәрі жай ғана жұмыс істеді, содан кейін PostgreSQL Professional-тан достарымыз келіп, жадтың ағып кеткенін айтты. Олар шынымен болды, біз оларды түзеттік. Бірақ бұл қарапайым болды.
Содан кейін қосылым пулаторында кіріс TLS қосылымдары және шығыс TLS қосылымдары бар екенін анықтадық. Ал қосылымдар клиент сертификаттары мен сервер сертификаттарын талап етеді.
Bouncer және Odyssey серверінің сертификаттары олардың pcache арқылы қайта оқылады, бірақ клиент сертификаттарын pcache-ден қайта оқудың қажеті жоқ, өйткені біздің масштабталатын Odyssey сайып келгенде, осы сертификатты оқудың жүйелік өнімділігімен жұмыс істейді. Бұл біз үшін күтпеген жағдай болды, өйткені оған қарсы тұруға көп уақыт кетпеді. Алғашында ол сызықты түрде масштабталды, бірақ 20 000 кіріс бір мезгілде қосылымнан кейін бұл мәселе өзін көрсетті.
Қосылатын аутентификация әдісі – кірістірілген Lunux құралдарын пайдаланып аутентификациялау мүмкіндігі. PgBouncer-те ол PAM-дан жауапты күту үшін бөлек ағын болатындай етіп жүзеге асырылады және ағымдағы қосылымға қызмет көрсететін және PAM ағынында тұруды сұрай алатын негізгі PgBouncer ағыны бар.
Біз мұны бір қарапайым себеппен жүзеге асырмадық. Бізде жіптер көп. Бұл бізге не үшін керек?
Бұл сайып келгенде проблемаларды тудыруы мүмкін, егер сізде PAM аутентификациясы және PAM емес аутентификация болса, PAM аутентификациясының үлкен толқыны PAM емес аутентификацияны айтарлықтай кешіктіруі мүмкін. Бұл біз түзетпеген нәрселердің бірі. Бірақ егер сіз оны түзеткіңіз келсе, мұны істей аласыз.
Тағы бір рейк - бізде барлық кіріс қосылымдарды қабылдайтын бір жіп бар. Содан кейін олар TLS қол алысуы өтетін жұмысшылар пулына ауыстырылады.
Қорытындылай келе, егер сізде 20 000 желі қосылымының когерентті толқыны болса, олардың барлығы қабылданады. Ал клиент жағында libpq күту уақыты туралы есеп бере бастайды. Әдепкі бойынша бұл 3 секунд сияқты.
Егер олардың барлығы бір уақытта деректер қорына кіре алмаса, онда олар деректер базасына кіре алмайды, өйткені мұның барлығы экспоненциалды емес қайталау арқылы қамтылуы мүмкін.
Біз PgBouncer-дан схеманы көшірдік деген қорытындыға келдік, өйткені біз қабылдайтын TCP қосылымдарының санын азайтамыз.
Егер біз қосылымдарды қабылдап жатқанымызды көрсек, бірақ олардың сайып келгенде қол алысуға уақыты жоқ болса, біз оларды процессор ресурстарын ысырап етпеу үшін кезекке қоямыз. Бұл бір уақытта қол алысу барлық келген қосылымдар үшін орындалмауы мүмкін екеніне әкеледі. Бірақ, ең болмағанда, біреу жүктеме өте ауыр болса да, дерекқорға кіреді.
Жол картасы
Одиссейде болашақта не көргіңіз келеді? Біз өзімізді дамытуға дайынбыз және қоғамнан не күтеміз?
2019 жылдың тамыз айындағы жағдай бойынша.
Одиссей жол картасы тамыз айында осылай болды:
- Біз SCRAM және PAM аутентификациясын қалаймыз.
- Біз оқу сұрауларын күту режиміне жібергіміз келді.
- Мен онлайн қайта іске қосқым келеді.
- Және серверде үзіліс жасау мүмкіндігі.
Бұл жол картасының жартысы орындалды, біз емес. Бұл да жақсы. Ендеше, не қалғанын талқылап, көбірек қосайық.
? Бізде сұрауларды орындамай-ақ жай ғана ауаны жылытатын көшірмелер бар. Бізге олар ауыстыруды және ауысуды қамтамасыз ету үшін қажет. Деректер орталықтарының бірінде ақаулар туындаған жағдайда, мен оларды пайдалы жұмыспен айналысқым келеді. Өйткені біз бірдей орталық процессорларды, бір жадты басқаша конфигурациялай алмаймыз, өйткені әйтпесе репликация жұмыс істемейді.
Негізінде Postgres-те 10-нан бастап қосылу кезінде session_attrs көрсетуге болады. Қосылымдағы барлық дерекқор хосттарын тізіп, дерекқорға не үшін бара жатқаныңызды айта аласыз: жазу немесе тек оқу. Ал драйвердің өзі тізімдегі ең ұнайтын, session_attrs талаптарын орындайтын бірінші хостты таңдайды.
Бірақ бұл тәсілдің проблемасы оның репликацияның артта қалуын бақыламауында. Сізде қызмет көрсету үшін қолайсыз уақытқа артта қалған кейбір көшірме болуы мүмкін. Көшірмедегі оқу сұрауларының толық функционалды орындалуын қамтамасыз ету үшін біз негізінен Одиссейдің оқу мүмкін болмаған кезде іске қосылмау мүмкіндігін қолдауымыз керек.
Одиссей мезгіл-мезгіл дерекқорға кіріп, бастапқыдан репликация қашықтығын сұрауы керек. Егер ол шекті мәнге жеткен болса, дерекқорға жаңа сұрауларға рұқсат бермеңіз, клиентке қосылымдарды қайта бастау керек екенін айтыңыз және сұрауларды орындау үшін басқа хостты таңдауыңыз мүмкін. Бұл дерекқорға репликацияның кешігуін жылдам қалпына келтіруге және сұрауға жауап беру үшін қайта оралуға мүмкіндік береді.
Іске асыру үшін уақыт шеңберін беру қиын, себебі ол ашық бастапқы болып табылады. Бірақ, PgBouncer әріптестерім сияқты 2,5 жыл емес деп үміттенемін. Бұл мен Одиссеяда көргім келетін ерекшелік.
. Енді дайындалған мәлімдемені екі жолмен жасауға болады. Біріншіден, SQL пәрменін орындауға болады, атап айтқанда «дайындық». Бұл SQL пәрменін түсіну үшін біз Bouncer жағындағы SQL тілін түсінуді үйренуіміз керек. Бұл шамадан тыс болады, өйткені бұл артық, өйткені бізге бүкіл талдаушы қажет. Біз әрбір SQL пәрменін талдай алмаймыз.
Бірақ proto3-те хабарлама протоколы деңгейінде дайындалған мәлімдеме бар. Бұл дайындалған мәлімдеменің құрылып жатқаны туралы ақпарат құрылымдық түрде келетін орын. Біз кейбір сервер қосылымында клиент дайындалған мәлімдемелерді жасауды сұрайтынын түсінуге болады. Транзакция жабық болса да, біз әлі де сервер мен клиент арасындағы байланысты сақтауымыз керек.
Бірақ бұл жерде диалогта сәйкессіздік туындайды, өйткені біреу клиенттің қандай дайындалған мәлімдемелерді жасағанын түсіну керек және осы сервер қосылымын жасаған барлық клиенттер арасында серверлік қосылымды бөлісу керек дейді, яғни осындай дайындалған мәлімдемені жасаған.
Андрес Фрейнд, егер сізге басқа сервер қосылымында осындай дайындалған мәлімдеме жасаған клиент келсе, оны оған жасаңыз. Бірақ сұрауларды клиенттің орнына дерекқорда орындау сәл қате болып көрінеді, бірақ дерекқормен өзара әрекеттесу үшін хаттаманы жазатын әзірлеушінің көзқарасы бойынша, оған жай ғана желілік қосылым берілсе, ыңғайлы болар еді. осындай дайындалған сұрау бар.
Және тағы бір мүмкіндікті іске асыруымыз керек. Бізде PgBouncer-пен үйлесімді мониторинг бар. Орташа сұрауды орындау уақытын қайтара аламыз. Бірақ орташа уақыт - бұл ауруханадағы орташа температура: кейбіреулер суық, кейбіреулері жылы - орташа алғанда, барлығы сау. Бұл өтірік.
Біз ресурстарды ысырап ететін және бақылауды қолайлырақ ететін баяу сұраулар бар екенін көрсететін пайыздық көрсеткіштерге қолдау көрсетуіміз керек.
Ең бастысы, мен 1.0 нұсқасын қалаймын (1.1 нұсқасы шығарылған). Одиссей қазір 1.0rc нұсқасында, яғни шығарылым кандидаты. Жадтың ағып кетуін қоспағанда, мен санаған барлық мәселелер дәл сол нұсқамен түзетілді.
1.0 нұсқасы біз үшін нені білдіреді? Біз «Одиссеяны» өз базаларымызға таратып жатырмыз. Ол қазірдің өзінде біздің дерекқорларымызда жұмыс істейді, бірақ ол секундына 1 000 000 сұрау нүктесіне жеткенде, бұл шығарылым нұсқасы және бұл 1.0 деп атауға болатын нұсқа деп айта аламыз.
Қауымдастықтағы бірнеше адам 1.0 нұсқасында үзіліс пен SCRAM болуын сұрады. Бірақ бұл келесі нұсқаны өндіріске шығаруымыз керек дегенді білдіреді, өйткені SCRAM да, үзіліс те әлі жойылған жоқ. Бірақ, ең алдымен, бұл мәселе тез шешіледі.
Мен сіздің сұрауыңызды күтемін. Мен сондай-ақ Bouncer-пен қандай проблемалар бар екенін білгім келеді. Оларды талқылайық. Мүмкін біз сізге қажет функцияларды жүзеге асыра аламыз.
Осымен менің бөлімім аяқталды, мен сізді тыңдағым келеді. Рақмет сізге!
Сіздің сұрақтарыңыз
Егер мен өз қолданбаның_атын орнатсам, ол Одиссейдегі транзакцияларды біріктіру кезінде дұрыс жіберіледі ме?
Одиссей немесе Боунсер?
Одиссеяда. Bouncer-де ол лақтырылады.
Біз жиынтық жасаймыз.
Ал егер менің нақты байланысым басқа қосылымдарға секірсе, ол жіберіледі ме?
Біз тізімде көрсетілген барлық параметрлердің жинағын жасаймыз. Бұл тізімде application_name бар-жоғын айта алмаймын. Мен оны сонда көрдім деп ойлаймын. Біз барлық бірдей параметрлерді орнатамыз. Бір сұраныспен жиынтық іске қосу кезінде клиент орнатқанның барлығын орындайды.
Рақмет, Андрей, есеп үшін! Жақсы есеп! Мен Одиссейдің минут сайын жылдам және жылдам дамып келе жатқанына қуаныштымын. Мен осылай жалғастырғым келеді. Біз сізден Odyssey бір уақытта әртүрлі дерекқорларға, яғни негізгі құлға қосыла алатындай, содан кейін істен шыққаннан кейін жаңа мастерге автоматты түрде қосыла алатындай көп деректер көзі қосылымын сұрадық.
Иә, бұл талқылау есімде қалған сияқты. Қазір бірнеше қоймалар бар. Бірақ олардың арасында ауысу жоқ. Біздің тарапымыздан біз серверден оның әлі тірі екенін сұрауымыз керек және pg_recovery деп аталатын қате орын алғанын түсінуіміз керек. Менде шеберге келмегенімізді түсінудің стандартты тәсілі бар. Қателерден қандай да бір жолмен түсіну керек пе немесе не? Яғни, идея қызық, талқыланып жатыр. Көбірек пікірлер жазыңыз. Егер сізде C тілін білетін қызметкерлер болса, бұл өте жақсы.
Көшірмелер бойынша масштабтау мәселесі де бізді қызықтырады, өйткені біз репликацияланған кластерлерді қабылдауды қолданбаларды әзірлеушілер үшін мүмкіндігінше қарапайым еткіміз келеді. Бірақ бұл жерде мен көбірек түсініктеме алғым келеді, яғни мұны қалай жасау керек, қалай жақсы істеу керек.
Сұрақ репликалар туралы да. Сізде шебер және бірнеше көшірме бар екен. Және олар қосылымдар үшін шеберге қарағанда репликаға жиі баратыны анық, өйткені олардың айырмашылықтары болуы мүмкін. Сіз деректердегі айырмашылық сіздің бизнесіңізді қанағаттандырмайтындай болуы мүмкін және ол қайталанбайынша ол жерге бармайсыз деп айттыңыз. Сонымен қатар, егер сіз ол жерге ұзақ уақыт бармай, содан кейін бара бастасаңыз, қажетті деректер бірден қол жетімді болмайды. Яғни, егер біз үнемі шеберге баратын болсақ, онда кэш қызады, бірақ репликада кэш сәл артта қалады.
Иә бұл шындық. pcache-де сіз қалаған деректер блоктары болмайды, нақты кэште сіз қалаған кестелер туралы ақпарат болмайды, жоспарларда талданған сұраулар болмайды, мүлдем ештеңе болмайды.
Ал сізде қандай да бір кластер болған кезде және сіз оған жаңа көшірмені қосқанда, ол іске қосылғанда, онда бәрі нашар болады, яғни ол кэшті арттырады.
Мен идеяны алдым. Дұрыс тәсіл алдымен көшірмедегі сұраулардың шағын пайызын орындау болады, бұл кэшті жылытады. Дөрекі сөзбен айтқанда, бізде шеберден 10 секундтан аспау керек деген шарт бар. Және бұл жағдай бір толқынға кірмейді, бірақ кейбір клиенттер үшін тегіс.
Иә, салмақты арттырыңыз.
Бұл жақсы идея болып табылады. Бірақ алдымен осы өшіруді жүзеге асыруымыз керек. Алдымен біз өшіруіміз керек, содан кейін қалай қосу керектігін ойлаймыз. Бұл біркелкі қосу үшін тамаша мүмкіндік.
Nginx-те бұл опция бар slowly start серверге арналған кластерде. Және ол жүктемені бірте-бірте арттырады.
Иә, тамаша идея, оны қолға алған кезде қолданып көреміз.
Ақпарат көзі: www.habr.com