Failover Cluster PostgreSQL + Patroni. Хэрэгжүүлэх туршлага

Нийтлэлд би PostgreSQL-ийн алдааг тэсвэрлэх асуудалд хэрхэн хандсан, энэ нь яагаад бидний хувьд чухал болсон, эцэст нь юу болсныг танд хэлэх болно.

Бид маш их ачаалалтай үйлчилгээтэй: дэлхий даяар 2,5 сая хэрэглэгч, өдөр бүр 50 мянга гаруй идэвхтэй хэрэглэгчид. Серверүүд нь Ирландын нэг бүс нутгийн Амазон хотод байрладаг: 100 гаруй өөр серверүүд байнга ажиллаж байгаагийн бараг 50 нь мэдээллийн сантай байдаг.

Бүхэл бүтэн backend нь үйлчлүүлэгчтэй байнгын вэбсокет холболтыг хадгалдаг том цул төлөвтэй Java програм юм. Хэд хэдэн хэрэглэгч нэг самбар дээр нэгэн зэрэг ажиллахад бид өөрчлөлт бүрийг мэдээллийн санд бичдэг тул тэд бүгд бодит цаг хугацаанд өөрчлөлтийг хардаг. Манай мэдээллийн санд секундэд 10 мянга орчим хүсэлт ирдэг. Redis-ийн хамгийн их ачаалалтай үед бид секундэд 80-100K хүсэлт бичдэг.

Бид яагаад Redis-аас PostgreSQL рүү шилжсэн бэ?

Эхэндээ манай үйлчилгээ серверийн RAM-д бүх өгөгдлийг хадгалдаг Redis-тэй хамтран ажиллаж байсан.

Redis-ийн давуу талууд:

1. Өндөр хариу хурд, учир нь бүх зүйл санах ойд хадгалагддаг;
2. Нөөцлөх, хуулбарлахад хялбар.

Redis-ийн бидний хувьд сул талууд:

1. Бодит гүйлгээ байхгүй. Бид тэдгээрийг програмынхаа түвшинд дуурайх гэж оролдсон. Харамсалтай нь энэ нь үргэлж сайн ажилладаггүй бөгөөд маш нарийн төвөгтэй код бичих шаардлагатай болдог.
2. Өгөгдлийн хэмжээ нь санах ойн хэмжээгээр хязгаарлагддаг. Өгөгдлийн хэмжээ нэмэгдэхийн хэрээр санах ой нэмэгдэж, эцэст нь бид сонгосон жишээний шинж чанаруудтай танилцах болно, энэ нь AWS-д инстанцийн төрлийг өөрчлөхийн тулд үйлчилгээгээ зогсоохыг шаарддаг.
3. Учир нь хоцрогдлын бага түвшинг байнга хадгалах шаардлагатай байдаг. бидэнд маш олон тооны хүсэлт байна. Бидний хувьд хамгийн оновчтой саатлын түвшин нь 17-20 мс байна. 30-40 мс-ийн түвшинд бид аппликешн болон үйлчилгээний доройтлоос ирсэн хүсэлтүүдэд урт хугацааны хариулт авдаг. Харамсалтай нь энэ нь 2018 оны 2-р сард бидэнд тохиолдсон бөгөөд Редистэй холбоотой тохиолдлуудын нэг нь ямар нэг шалтгаанаар ердийнхөөс XNUMX дахин их хоцрогдолтой болсон. Асуудлыг шийдвэрлэхийн тулд бид төлөвлөгөөт бус засвар үйлчилгээ хийх зорилгоор өдрийн дундуур үйлчилгээг зогсоож, асуудалтай Redis-ийг сольсон.
4. Кодын өчүүхэн алдаатай байсан ч өгөгдлийн үл нийцэх байдлыг олж авах нь амархан бөгөөд дараа нь энэ өгөгдлийг засахын тулд код бичихэд маш их цаг зарцуулдаг.

Бид сул талуудыг харгалзан үзсэн бөгөөд бид илүү тохиромжтой, ердийн гүйлгээ, хоцролтоос бага хамааралтай зүйл рүү шилжих хэрэгтэй гэдгийг ойлгосон. Судалгаа хийж, олон хувилбарт дүн шинжилгээ хийж, PostgreSQL-ийг сонгосон.

Бид 1,5 жилийн турш шинэ мэдээллийн сан руу шилжсэн бөгөөд өгөгдлийн багахан хэсгийг шилжүүлсэн тул одоо Redis болон PostgreSQL-тэй нэгэн зэрэг ажиллаж байна. Өгөгдлийн сангийн хооронд өгөгдөл шилжүүлэх, шилжүүлэх үе шатуудын талаархи дэлгэрэнгүй мэдээллийг энд бичсэн болно миний хамтрагчийн нийтлэл.

Биднийг анх хөдөлж эхлэхэд манай программ мэдээллийн сантай шууд ажиллаж, мастер Redis болон PostgreSQL-д хандсан. PostgreSQL кластер нь мастер болон асинхрон хуулбартай хуулбараас бүрддэг. Өгөгдлийн сангийн схем дараах байдалтай байсан.

PgBouncer-ийг хэрэгжүүлж байна

Биднийг хөдөлж байх хооронд бүтээгдэхүүн бас хөгжиж байв: хэрэглэгчдийн тоо болон PostgreSQL-тэй ажилладаг серверүүдийн тоо нэмэгдэж, бид холболтгүй болж эхэлсэн. PostgreSQL нь холболт бүрт тусдаа процесс үүсгэж, нөөцийг зарцуулдаг. Та холболтын тоог тодорхой цэг хүртэл нэмэгдүүлэх боломжтой, эс тэгвээс мэдээллийн баазын оновчтой гүйцэтгэлийг авах боломжтой. Ийм нөхцөлд хамгийн тохиромжтой сонголт бол суурийн урд байрлах холболтын менежерийг сонгох явдал юм.

Бидэнд холболтын менежерийн хоёр сонголт байсан: Pgpool болон PgBouncer. Гэхдээ эхнийх нь мэдээллийн сантай ажиллах гүйлгээний горимыг дэмждэггүй тул бид PgBouncer-ийг сонгосон.

Бид дараах ажлын схемийг тохируулсан: манай програм нэг PgBouncer-д ханддаг бөгөөд үүний ард PostgreSQL мастерууд байдаг бөгөөд мастер бүрийн ард асинхрон хуулбартай нэг хуулбар байдаг.


Үүний зэрэгцээ бид PostgreSQL-д өгөгдлийг бүхэлд нь хадгалах боломжгүй байсан бөгөөд өгөгдлийн сантай ажиллах хурд нь бидний хувьд чухал байсан тул PostgreSQL-ийг хэрэглээний түвшинд хувааж эхэлсэн. Дээр дурдсан схем нь үүнд харьцангуй тохиромжтой: шинэ PostgreSQL хэлтэрхий нэмэх үед PgBouncer тохиргоог шинэчлэхэд хангалттай бөгөөд програм нь шинэ хэлтэрхийтэй шууд ажиллах боломжтой.

PgBouncer-ийн алдаа

Энэ схем нь цорын ганц PgBouncer тохиолдол нас барах хүртэл ажилласан. Бид AWS-д байгаа бөгөөд бүх инстанцууд нь үе үе унадаг техник хангамж дээр ажилладаг. Ийм тохиолдолд жишээ нь шинэ техник хангамж руу шилжиж, дахин ажилладаг. Энэ нь PgBouncer-д тохиолдсон боловч боломжгүй болсон. Энэ намрын үр дүн нь манай үйлчилгээ 25 минутын турш ажиллахгүй байсан. AWS нь тухайн үед манай улсад хэрэгжээгүй ийм нөхцөл байдалд хэрэглэгчийн талын нөөцийг ашиглахыг зөвлөж байна.

Үүний дараа бид PgBouncer болон PostgreSQL кластеруудын алдааг тэсвэрлэх чадварын талаар нухацтай бодож үзсэн, учир нь үүнтэй төстэй нөхцөл байдал манай AWS акаунтын аль ч тохиолдолд тохиолдож болно.

Бид PgBouncer-ийн алдааг тэсвэрлэх схемийг дараах байдлаар бүтээсэн: бүх програмын серверүүд Сүлжээний ачаалал тэнцвэржүүлэгчид ханддаг бөгөөд үүний ард хоёр PgBouncer байдаг. PgBouncer бүр хэлтэрхий бүрийн ижил PostgreSQL мастерийг хардаг. Хэрэв AWS инстанцийн эвдрэл дахин гарвал бүх урсгал өөр PgBouncer-ээр дамждаг. Сүлжээний ачаалал тэнцвэржүүлэгчийг AWS хангадаг.

Энэ схем нь шинэ PgBouncer сервер нэмэхэд хялбар болгодог.

PostgreSQL Failover Cluster үүсгэх

Энэ асуудлыг шийдэхдээ бид өөр өөр хувилбаруудыг авч үзсэн: өөрөө бичсэн failover, repmgr, AWS RDS, Patroni.

Өөрөө бичсэн скриптүүд

Тэд мастерийн ажлыг хянаж, амжилтгүй болсон тохиолдолд хуулбарыг мастер руу сурталчилж, PgBouncer тохиргоог шинэчлэх боломжтой.

Энэ аргын давуу тал нь хамгийн энгийн байдал юм, учир нь та өөрөө скрипт бичиж, яг хэрхэн ажилладагийг ойлгодог.

Нөхцөл байдал:

• Мастер үхээгүй байж магадгүй, оронд нь сүлжээний доголдол гарсан байж магадгүй. Үүнийг мэдээгүй алдаа нь хуулбарыг мастерт сурталчлах бөгөөд хуучин мастер үргэлжлүүлэн ажиллах болно. Үүний үр дүнд бид мастерын дүрд хоёр сервер авах бөгөөд тэдгээрийн аль нь хамгийн сүүлийн үеийн өгөгдөлтэй болохыг бид мэдэхгүй. Энэ нөхцөл байдлыг мөн хуваагдмал тархи гэж нэрлэдэг;
• Бид хариу өгөхгүй хоцорсон. Манай тохиргоонд мастер болон нэг хуулбарыг шилжүүлсний дараа хуулбар нь мастер руу шилжиж, хуулбар байхгүй тул бид гараар шинэ хуулбар нэмэх шаардлагатай болно;
• Бидэнд 12 PostgreSQL-ийн хэлтэрхийнүүд байгаа бөгөөд энэ нь 12 кластерт хяналт тавих ёстой гэсэн үг. Хэргийн тоо нэмэгдэхийн хэрээр та бүтэлгүйтлийг шинэчлэхээ санах хэрэгтэй.

Өөрөө бичсэн алдаа нь маш төвөгтэй харагддаг бөгөөд өчүүхэн бус дэмжлэг шаарддаг. Ганц PostgreSQL кластертай бол энэ нь хамгийн хялбар сонголт байх болно, гэхдээ энэ нь масштабтай биш тул энэ нь бидний хувьд тохиромжгүй юм.

Repmgr

PostgreSQL кластерын ажиллагааг удирдах боломжтой PostgreSQL кластерт зориулсан хуулбарлах менежер. Үүний зэрэгцээ, энэ нь хайрцагнаас автоматаар солигддоггүй тул ажлын хувьд та бэлэн шийдэл дээр өөрийн "боодол" бичих хэрэгтэй болно. Тиймээс бүх зүйл өөрөө бичсэн скриптээс ч илүү төвөгтэй болж хувирах тул бид Repmgr-ийг туршиж үзээгүй.

AWS RDS

Бидэнд хэрэгтэй бүх зүйлийг дэмжиж, нөөцлөлтийг хэрхэн хийхээ мэддэг, холболтын санг хадгалдаг. Энэ нь автомат шилжүүлэлттэй: мастер нас барахад хуулбар нь шинэ мастер болж, AWS нь dns бичлэгийг шинэ мастер болгон өөрчилдөг бол хуулбарууд нь өөр өөр AZ-д байрлаж болно.

Сул тал нь нарийн тохируулга байхгүй байна. Нарийн тохируулгын жишээ болгон: манай тохиолдлуудад tcp холболтын хязгаарлалтууд байдаг бөгөөд харамсалтай нь RDS дээр үүнийг хийх боломжгүй:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Нэмж дурдахад AWS RDS нь ердийн хувилбарын үнээс бараг хоёр дахин үнэтэй байдаг нь энэхүү шийдлээс татгалзах гол шалтгаан болсон юм.

Патрони

Энэ бол PostgreSQL-г удирдахад зориулагдсан питон загвар бөгөөд github дээрх сайн баримтжуулалт, автоматаар шилжүүлэлт болон эх кодтой.

Патронигийн давуу талууд:

• Тохиргооны параметр бүрийг тайлбарласан бөгөөд энэ нь хэрхэн ажилладаг нь тодорхой байна;
• Автомат шилжүүлэлт нь хайрцагнаас гардаг;
• Питон хэл дээр бичигдсэн бөгөөд бид өөрсдөө python хэл дээр маш их бичдэг тул асуудлыг шийдвэрлэхэд илүү хялбар байх болно, магадгүй төслийг боловсруулахад туслах болно;
• PostgreSQL-ийг бүрэн удирдаж, кластерын бүх зангилааны тохиргоог нэг дор өөрчлөх боломжийг олгодог бөгөөд хэрэв шинэ тохиргоог ашиглахын тулд кластерыг дахин эхлүүлэх шаардлагатай бол Patroni ашиглан үүнийг дахин хийж болно.

Нөхцөл байдал:

• PgBouncer-тэй хэрхэн зөв ажиллах нь баримт бичигт тодорхойгүй байна. Хэдийгээр үүнийг хасах гэж нэрлэхэд хэцүү ч Патронигийн даалгавар бол PostgreSQL-ийг удирдах явдал бөгөөд Патронитэй холбогдох нь бидний асуудал юм;
• Патронийг их хэмжээгээр хэрэгжүүлсэн жишээ цөөн байдаг бол эхнээс нь хэрэгжүүлсэн олон жишээ байдаг.

Үүний үр дүнд бид бүтэлгүйтлийн кластер үүсгэхийн тулд Patroni-г сонгосон.

Patroni хэрэгжүүлэх үйл явц

Патронигийн өмнө бид нэг мастер болон асинхрон хуулбартай нэг хуулбарын тохиргоонд 12 PostgreSQL хэлтэрхийтэй байсан. Хэрэглээний серверүүд нь Network Load Balancer-ээр дамжуулан мэдээллийн санд ханддаг байсан бөгөөд үүний ард PgBouncer-тай хоёр тохиолдол байсан бөгөөд тэдгээрийн ард бүх PostgreSQL серверүүд байсан.


Patroni-г хэрэгжүүлэхийн тулд бид хуваарилагдсан хадгалалтын кластерийн тохиргоог сонгох хэрэгтэй болсон. Патрони нь etcd, Zookeeper, Consul зэрэг хуваарилагдсан тохиргооны хадгалах системтэй ажилладаг. Бид зүгээр л зах зээл дээр бүрэн эрхт консулын кластертай бөгөөд энэ нь Vault-тай хамтран ажилладаг бөгөөд бид үүнийг ашиглахаа больсон. Консулыг зориулалтын дагуу ашиглаж эхлэх сайхан шалтгаан.

Патрони консултай хэрхэн ажилладаг

Бидэнд гурван зангилаанаас бүрдэх Консул кластер, удирдагч, хуулбараас бүрдэх Патрони кластер (Патронид мастерыг кластерийн удирдагч, боолуудыг хуулбар гэж нэрлэдэг) бий. Патрони кластерын тохиолдол бүр нь кластерын төлөв байдлын талаарх мэдээллийг консул руу байнга илгээдэг. Тиймээс Консулаас та Патрони кластерын одоогийн тохиргоо, яг одоо хэн тэргүүлж байгааг олж мэдэх боломжтой.

Патронийг консултай холбохын тулд Консултай хэрхэн ажилладаг, холболтын схемээс хамааран http эсвэл https форматаар хостыг зааж өгөх шаардлагатай гэсэн албан ёсны баримт бичгийг судлахад хангалттай.

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Энэ нь энгийн мэт харагдах боловч эндээс алдаанууд эхэлдэг. Консулын тусламжтайгаар бид https-ээр дамжуулан аюулгүй холболтоор ажилладаг бөгөөд бидний холболтын тохиргоо дараах байдалтай байна.

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Гэхдээ энэ нь болохгүй байна. Эхлэх үед Патрони Консултай холбогдож чадахгүй, учир нь тэр ямар ч байсан http-ээр нэвтрэхийг оролддог.

Патронигийн эх код нь асуудлыг шийдвэрлэхэд тусалсан. Энэ нь python дээр бичигдсэн нь сайн хэрэг. Энэ нь хост параметрийг ямар ч байдлаар задлан шинжилдэггүй бөгөөд протоколыг схемд зааж өгөх ёстой. Консултай ажиллах ажлын тохиргооны блок нь бидний хувьд иймэрхүү харагдаж байна.

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

консулын загвар

Тиймээс бид тохиргоонд зориулж хадгалах санг сонгосон. Одоо бид Patroni кластер дахь удирдагчийг өөрчлөх үед PgBouncer тохиргоогоо хэрхэн өөрчлөхийг ойлгох хэрэгтэй. Баримт бичигт энэ асуултын хариулт байхгүй, учир нь. Тэнд зарчмын хувьд PgBouncer-тэй ажиллах талаар тайлбарлаагүй болно.

Шийдэл хайж байхдаа бид Консулын загвар нь PgBouncer болон Patroni-г хослуулахад маш их тусалсан гэж бичсэн нийтлэлийг (харамсалтай нь гарчгийг нь санахгүй байна) олсон. Энэ нь биднийг Консулын загвар хэрхэн ажилладаг талаар судлахад түлхэц болсон.

Consul-template нь Консул дахь PostgreSQL кластерын тохиргоог байнга хянаж байдаг нь тогтоогдсон. Удирдагч өөрчлөгдөхөд PgBouncer тохиргоог шинэчилж, дахин ачаалах тушаал илгээдэг.

Загварын том давуу тал нь код хэлбэрээр хадгалагддаг тул шинэ хэлтэрхий нэмэх үед Дэд бүтцийг кодын зарчмаар дэмжиж, шинэ амлалт хийж, загварыг автоматаар шинэчлэхэд хангалттай.

Патронитай шинэ архитектур

Үүний үр дүнд бид дараах ажлын схемийг авсан.


Бүх програмын серверүүд тэнцвэржүүлэгч рүү ханддаг → үүний ард PgBouncer-ийн хоёр тохиолдол байдаг → тохиолдол бүр дээр Консул-загвар ажиллаж байгаа бөгөөд энэ нь Patroni кластер бүрийн статусыг хянаж, PgBouncer тохиргооны хамаарлыг хянадаг бөгөөд энэ нь одоогийн удирдагч руу хүсэлт илгээдэг. кластер бүрийн.

Гарын авлагын туршилт

Бид энэ схемийг жижиг туршилтын орчинд ажиллуулахын өмнө ажиллуулж, автомат сэлгэн залгах ажиллагааг шалгасан. Тэд самбарыг онгойлгож, наалтыг хөдөлгөж, тэр үед кластерын удирдагчийг "алав". AWS-д энэ нь консолоор дамжуулан жишээг унтраахтай адил хялбар юм.

Наалт 10-20 секундын дотор буцаж буцаж, дараа нь дахин хэвийн хөдөлж эхлэв. Энэ нь Патрони кластер зөв ажилласан гэсэн үг юм: тэр удирдагчаа сольж, мэдээллийг Консул руу илгээж, Консул-загвар тэр даруй энэ мэдээллийг авч, PgBouncer тохиргоог сольж, дахин ачаалах командыг илгээсэн.

Хэрхэн их ачаалалтай байж, зогсолтыг хамгийн бага байлгах вэ?

Бүх зүйл төгс ажилладаг! Гэхдээ шинэ асуултууд байна: Энэ нь өндөр ачаалалтай үед хэрхэн ажиллах вэ? Үйлдвэрлэлд байгаа бүх зүйлийг хэрхэн хурдан, найдвартай гаргах вэ?

Бидний ачааллын туршилт хийдэг туршилтын орчин нь эхний асуултанд хариулахад тусалдаг. Энэ нь архитектурын хувьд үйлдвэрлэлтэй бүрэн ижил бөгөөд үйлдвэрлэлийн хэмжээтэй ойролцоогоор тэнцүү хэмжээний туршилтын өгөгдлийг бий болгосон. Туршилтын үеэр бид PostgreSQL мастеруудын аль нэгийг нь "алах" шийдвэр гаргаж, юу болсныг харах болно. Гэхдээ үүнээс өмнө автомат гулсалтыг шалгах нь чухал, учир нь энэ орчинд бид хэд хэдэн PostgreSQL хэлтэрхийнүүдтэй тул үйлдвэрлэхээс өмнө тохиргооны скриптүүдийг маш сайн туршиж үзэх болно.

Хоёр даалгавар хоёулаа амбицтай харагдаж байгаа ч бидэнд PostgreSQL 9.6 байна. Бид 11.2 руу нэн даруй шинэчилж чадах уу?

Бид үүнийг 2 алхамаар хийхээр шийдсэн: эхлээд 11.2 хүртэл шинэчлээд дараа нь Patroni-г ажиллуул.

PostgreSQL шинэчлэлт

PostgreSQL хувилбарыг хурдан шинэчлэхийн тулд сонголтыг ашиглана уу -k, дискэн дээр хатуу холбоосууд үүсгэгддэг бөгөөд таны өгөгдлийг хуулах шаардлагагүй. 300-400 ГБ-ын үндсэн дээр шинэчлэлт нь 1 секунд болно.

Бидэнд маш олон хэлтэрхий байгаа тул шинэчлэлтийг автоматаар хийх шаардлагатай. Үүнийг хийхийн тулд бид бүх шинэчлэлтийн үйл явцыг зохицуулдаг Ansible тоглоомын ном бичсэн:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

Шинэчлэлтийг эхлүүлэхийн өмнө та үүнийг параметрээр гүйцэтгэх ёстой гэдгийг энд анхаарах нь чухал юм --шалгашинэчлэх боломжтой эсэхийг шалгахын тулд. Манай скрипт нь шинэчлэлтийн хугацаанд тохируулгын орлуулалт хийдэг. Манай скриптийг 30 секундэд дуусгасан нь маш сайн үр дүн юм.

Patroni-г ажиллуул

Хоёр дахь асуудлыг шийдэхийн тулд Patroni тохиргоог хараарай. Албан ёсны репозитор нь initdb-тэй жишээ тохиргоотой бөгөөд энэ нь таныг Patroni-г анх эхлүүлэхэд шинэ мэдээллийн санг эхлүүлэх үүрэгтэй. Гэхдээ бидэнд аль хэдийн бэлэн мэдээллийн сан байгаа тул бид энэ хэсгийг тохиргооноос хассан.

Бид аль хэдийн байгаа PostgreSQL кластер дээр Patroni-г суулгаж, ажиллуулж эхлэхэд бид шинэ асуудалтай тулгарсан: хоёр сервер хоёулаа удирдагч болж эхэлсэн. Патрони нь кластерын анхны төлөвийн талаар юу ч мэдэхгүй бөгөөд хоёр серверийг ижил нэртэй хоёр тусдаа кластер болгон эхлүүлэхийг оролддог. Энэ асуудлыг шийдэхийн тулд та боол дээрх өгөгдөл бүхий лавлахыг устгах хэрэгтэй.

rm -rf /var/lib/postgresql/

Үүнийг зөвхөн боол дээр хийх хэрэгтэй!

Цэвэр хуулбар холбогдсон үед Patroni үндсэн нөөцийн удирдагчийг хийж, хуулбар руугаа сэргээж, дараа нь wal логуудын дагуу одоогийн төлөвийг гүйцэлдүүлдэг.

Бидний тулгарсан өөр нэг бэрхшээл бол бүх PostgreSQL кластеруудыг анхдагчаар үндсэн гэж нэрлэдэг. Кластер бүр нөгөөгийнхөө талаар юу ч мэдэхгүй бол энэ нь хэвийн үзэгдэл юм. Гэхдээ та Patroni-г ашиглахыг хүсвэл бүх кластерууд өвөрмөц нэртэй байх ёстой. Энэ шийдэл нь PostgreSQL тохиргоонд кластерын нэрийг өөрчлөх явдал юм.

ачааллын туршилт

Бид самбар дээрх хэрэглэгчийн туршлагыг дуурайдаг туршилтыг эхлүүлсэн. Ачаалал нь бидний өдрийн дундаж утгад хүрэхэд бид яг ижил туршилтыг давтаж, PostgreSQL удирдагчтай нэг жишээг унтраасан. Автомат шилжүүлэлт нь бидний бодож байсанчлан ажилласан: Патрони удирдагчаа сольж, Консул-загвар нь PgBouncer тохиргоог шинэчилж, дахин ачаалах тушаал илгээсэн. Графана дахь бидний графикаас харахад мэдээллийн сантай холбогдохтой холбоотой серверүүдээс 20-30 секундын саатал, бага хэмжээний алдаа байгаа нь тодорхой байсан. Энэ бол хэвийн нөхцөл байдал, ийм утгууд нь бидний дампууралд хүлээн зөвшөөрөгдөхүйц бөгөөд үйлчилгээний зогсолтоос хамаагүй дээр юм.

Патронийг үйлдвэрлэлд нэвтрүүлэх

Үүний үр дүнд бид дараах төлөвлөгөөг гаргасан.

• Consul-загварыг PgBouncer серверт байрлуулж, эхлүүлэх;
• PostgreSQL-ийг 11.2 хувилбар руу шинэчлэх;
• Кластерын нэрийг өөрчлөх;
• Патрони кластерийг эхлүүлж байна.

Үүний зэрэгцээ, манай схем бидэнд эхний цэгийг бараг ямар ч үед хийх боломжийг олгодог, бид PgBouncer бүрийг ажлаас нь ээлжлэн устгаж, консулын загварыг байрлуулж, ажиллуулж болно. Бид тэгсэн.

Шуурхай байршуулахын тулд бид Ansible-г ашигласан, учир нь бид бүх тоглоомын номыг туршилтын орчинд туршиж үзсэн бөгөөд бүрэн скриптийг гүйцэтгэх хугацаа нь хэлтэрхий тус бүрт 1,5-аас 2 минутын хооронд байсан. Бид үйлчилгээгээ зогсоохгүйгээр бүх зүйлийг хэлтэрхий болгонд ээлжлэн тарааж болох боловч PostgreSQL бүрийг хэдэн минутын турш унтраах шаардлагатай болно. Энэ тохиолдолд өгөгдөл нь энэ хэлтэрхий дээр байгаа хэрэглэгчид одоогоор бүрэн ажиллах боломжгүй байгаа бөгөөд энэ нь бидний хувьд хүлээн зөвшөөрөгдөхгүй юм.

Энэ байдлаас гарах арга зам нь 3 сар тутамд хийдэг төлөвлөгөөт засвар үйлчилгээ байсан. Энэ бол бид үйлчилгээгээ бүрэн хааж, мэдээллийн баазын инстанцуудыг шинэчлэх үед хуваарьт ажил хийх цонх юм. Дараагийн цонх хүртэл нэг долоо хоног үлдсэн тул бид зүгээр л хүлээж, цаашаа бэлтгэл хийхээр шийдсэн. Хүлээж байх хугацаандаа бид нэмэлт хамгаалалт хийсэн: PostgreSQL хэлтэрхий бүрийн хувьд бид хамгийн сүүлийн үеийн өгөгдлийг хадгалахгүй байх тохиолдолд нөөц хуулбарыг гаргаж, хэлтэрхий бүрт шинэ жишээ нэмсэн бөгөөд энэ нь Patroni кластерт шинэ хуулбар болох ёстой. өгөгдлийг устгах командыг гүйцэтгэхгүйн тулд . Энэ бүхэн алдааны эрсдлийг багасгахад тусалсан.


Бид үйлчилгээгээ дахин эхлүүлж, бүх зүйл хэвийн ажиллаж, хэрэглэгчид үргэлжлүүлэн ажиллаж байсан ч график дээр Консулын серверүүд хэвийн бус ачаалалтай байгааг анзаарсан.


Бид яагаад туршилтын орчинд үүнийг хараагүй юм бэ? Энэ асуудал нь Дэд бүтцийг кодын зарчим болгон дагаж, туршилтын орчноос эхлээд үйлдвэрлэл хүртэлх бүх дэд бүтцийг боловсронгуй болгох шаардлагатайг маш сайн харуулж байна. Үгүй бол бидэнд тулгарсан асуудлыг шийдэх нь маш амархан. Юу болсон бэ? Консул эхлээд үйлдвэрлэл дээр гарч ирсэн, дараа нь туршилтын орчинд, үр дүнд нь туршилтын орчинд Консулын хувилбар нь үйлдвэрлэлээс өндөр байв. Зөвхөн нэг хувилбар дээр консулын загвартай ажиллах үед CPU-ийн алдагдлыг шийдсэн. Тиймээс бид зүгээр л Консулыг шинэчилж, асуудлыг шийдсэн.

Patroni кластерийг дахин эхлүүлнэ үү

Гэсэн хэдий ч бидний сэжиглэж байгаагүй шинэ асуудал гарч ирэв. Консулыг шинэчлэх үед бид консулыг орхих командыг ашиглан Консулын зангилааг кластераас устгана уу → Патрони өөр консулын серверт холбогдоно → бүх зүйл ажиллана. Гэвч бид Консулын кластерын сүүлчийн тохиолдол дээр хүрч консулын чөлөө өгөх тушаалыг илгээхэд бүх Патрони кластерууд зүгээр л дахин ажиллаж, бүртгэлд бид дараах алдааг олж харав.

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Патрони кластер нь кластерынхаа мэдээллийг авч чадаагүй бөгөөд дахин эхлүүлсэн.

Шийдэл олохын тулд бид github дээрх асуудлаас болж Патронигийн зохиогчидтой холбогдсон. Тэд манай тохиргооны файлуудыг сайжруулахыг санал болгосон:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Бид туршилтын орчинд асуудлыг давтаж, эдгээр сонголтыг тэнд туршиж үзсэн боловч харамсалтай нь ажиллахгүй байсан.

Асуудал шийдэгдээгүй хэвээр байна. Бид дараах шийдлүүдийг туршиж үзэхээр төлөвлөж байна.

• Patroni кластерын тохиолдол бүрт Консул-агент ашиглах;
• Код дээрх асуудлыг засна уу.

Алдаа хаана гарсныг бид ойлгож байна: асуудал нь тохиргооны файлаар дамждаггүй анхдагч хугацаа дууссантай холбоотой байж магадгүй юм. Сүүлчийн консулын серверийг кластераас хасах үед Консулын кластер бүхэлдээ нэг секундээс илүү хугацаагаар зогсдог бөгөөд үүнээс болж Патрони кластерын статусыг авч чадахгүй бөгөөд кластерыг бүхэлд нь дахин эхлүүлдэг.

Аз болоход бид дахин алдаа гаргаагүй.

Patroni ашиглах үр дүн

Патронийг амжилттай ажиллуулсны дараа бид кластер бүрт нэмэлт хуулбарыг нэмсэн. Одоо кластер болгонд нэг удирдагч, хоёр хуулбар зэрэг чуулга бий.


Патрони гурван сар гаруйн турш үйлдвэрлэл дээр ажиллаж байна. Энэ хугацаанд тэр аль хэдийн бидэнд тусалж чадсан. Саяхан нэг кластерын удирдагч AWS-д нас барж, автомат ажиллагаагүй ажиллаж, хэрэглэгчид үргэлжлүүлэн ажиллав. Патрони үндсэн үүргээ биелүүлэв.

Patroni-ийн хэрэглээний жижиг тойм:

• Тохиргоог өөрчлөхөд хялбар. Нэг жишээн дээр тохиргоог өөрчлөхөд хангалттай бөгөөд энэ нь бүхэл бүтэн кластерт татагдах болно. Хэрэв шинэ тохиргоог ашиглахын тулд дахин ачаалах шаардлагатай бол Patroni танд мэдэгдэх болно. Патрони нь нэг тушаалаар бүхэл кластерыг дахин эхлүүлэх боломжтой бөгөөд энэ нь бас маш тохиромжтой.
• Автоматаар дампууралт нь ажилладаг бөгөөд аль хэдийн бидэнд тусалж чадсан.
• PostgreSQL програмын зогсолтгүйгээр шинэчлэх. Та эхлээд хуулбарыг шинэ хувилбар руу шинэчлэх хэрэгтэй, дараа нь Patroni кластер дахь удирдагчийг сольж, хуучин удирдагчийг шинэчлэх хэрэгтэй. Энэ тохиолдолд автомат унтраалга хийх шаардлагатай туршилтыг хийдэг.

Эх сурвалж: www.habr.com