ያልተሳካ ክላስተር PostgreSQL + Patroni። የትግበራ ልምድ

በጽሁፉ ውስጥ የ PostgreSQL ስህተት መቻቻልን ጉዳይ እንዴት እንደደረስን እነግርዎታለሁ ፣ ለምን ለእኛ አስፈላጊ ሆነ እና በመጨረሻ ምን እንደተፈጠረ ።

በከፍተኛ ደረጃ የተጫነ አገልግሎት አለን፡ በዓለም ዙሪያ 2,5 ሚሊዮን ተጠቃሚዎች፣ በየቀኑ 50ሺህ+ ንቁ ተጠቃሚዎች። አገልጋዮቹ በአንድ የአየርላንድ ክልል ውስጥ በአማዞን ይገኛሉ፡ 100+ የተለያዩ ሰርቨሮች በቋሚነት ስራ ላይ ናቸው፣ ከእነዚህም ውስጥ 50 የሚሆኑት የውሂብ ጎታ ያላቸው ናቸው።

ሙሉው ጀርባ ከደንበኛው ጋር የማያቋርጥ የዌብሶኬት ግንኙነትን የሚይዝ ትልቅ አሃዳዊ ሁኔታ ያለው የጃቫ መተግበሪያ ነው። ብዙ ተጠቃሚዎች በተመሳሳይ ሰሌዳ ላይ በተመሳሳይ ጊዜ ሲሰሩ, ሁሉም ለውጦችን በእውነተኛ ጊዜ ያያሉ, ምክንያቱም እያንዳንዱን ለውጥ ወደ የውሂብ ጎታ እንጽፋለን. ወደ የውሂብ ጎታችን በሰከንድ ወደ 10ሺህ የሚጠጉ ጥያቄዎች አሉን። በሬዲስ ከፍተኛ ጭነት ላይ፣ 80-100K ጥያቄዎችን በሰከንድ እንጽፋለን።

ለምን ከRedis ወደ PostgreSQL ቀይረናል።

መጀመሪያ ላይ አገልግሎታችን ሁሉንም መረጃዎች በአገልጋዩ RAM ውስጥ የሚያከማች ቁልፍ እሴት ከሆነው ሬዲስ ጋር ሰርቷል።

የRedis ጥቅሞች

1. ከፍተኛ ምላሽ ፍጥነት, ምክንያቱም ሁሉም ነገር በማህደረ ትውስታ ውስጥ ተከማችቷል;
2. የመጠባበቂያ እና የማባዛት ቀላልነት.

ለእኛ የRedis ጉዳቶች፡-

1. ምንም እውነተኛ ግብይቶች የሉም. በመተግበሪያችን ደረጃ እነሱን ለማስመሰል ሞከርን. እንደ አለመታደል ሆኖ ይህ ሁልጊዜ በደንብ አይሰራም እና በጣም ውስብስብ ኮድ መጻፍ ያስፈልገዋል.
2. የመረጃው መጠን በማህደረ ትውስታ መጠን የተገደበ ነው። የመረጃው መጠን እየጨመረ ሲሄድ ማህደረ ትውስታው እያደገ ይሄዳል, እና በመጨረሻ, በተመረጠው ምሳሌ ባህሪያት ውስጥ እንገባለን, ይህም በ AWS ውስጥ የአብነት አይነትን ለመለወጥ አገልግሎታችንን ማቆምን ይጠይቃል.
3. ዝቅተኛ የመዘግየት ደረጃን ያለማቋረጥ ማቆየት አስፈላጊ ነው, ምክንያቱም. በጣም ብዙ የጥያቄዎች ብዛት አለን። ለእኛ በጣም ጥሩው የመዘግየት ደረጃ 17-20 ሚሴ ነው። በ30-40 ሚሴ ደረጃ፣ ከኛ ማመልከቻ እና የአገልግሎቱ ውድቅነት ለሚቀርቡ ጥያቄዎች ረጅም ምላሾች እናገኛለን። እንደ አለመታደል ሆኖ፣ ይህ በእኛ ላይ በሴፕቴምበር 2018 ደርሶናል፣ ከRedis ጋር በአንድ ምክንያት በሆነ ምክንያት ከ2 ጊዜ በላይ መዘግየት ሲቀበል። ችግሩን ለመፍታት በቀን አጋማሽ ላይ አገልግሎቱን ላልተያዘለት ጥገና አቁመን ችግር ያለበትን 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 ጥፋትን መቻቻል ዘዴን እንደሚከተለው ገንብተናል፡ ሁሉም የመተግበሪያ ሰርቨሮች የኔትወርክ ሎድ ባላንስን ያገኛሉ፣ ከኋላው ሁለት PgBouncers አሉ። እያንዳንዱ PgBouncer የእያንዳንዱን ሻርድ ተመሳሳይ የ PostgreSQL ዋናን ይመለከታል። የAWS ምሳሌ ብልሽት እንደገና ከተከሰተ፣ ሁሉም ትራፊክ ወደ ሌላ PgBouncer ይዘዋወራል። የአውታረ መረብ ጭነት ሚዛን አለመሳካት የቀረበው በAWS ነው።

ይህ እቅድ አዲስ PgBouncer አገልጋዮችን ማከል ቀላል ያደርገዋል።

የ PostgreSQL ያልተሳካ ክላስተር ይፍጠሩ

ይህንን ችግር በሚፈታበት ጊዜ የተለያዩ አማራጮችን ግምት ውስጥ አስገብተናል-በራስ የተጻፈ አለመሳካት ፣ repmgr ፣ AWS RDS ፣ Patroni።

በራሳቸው የተጻፉ ስክሪፕቶች

እነሱ የጌታውን ስራ መከታተል እና ውድቀት ቢከሰት ቅጂውን ወደ ጌታው ያስተዋውቁ እና የ PgBouncer ውቅርን ያዘምኑ።

የዚህ አቀራረብ ጥቅሞች ከፍተኛው ቀላልነት ናቸው, ምክንያቱም እርስዎ እራስዎ ስክሪፕቶችን ይጽፋሉ እና በትክክል እንዴት እንደሚሰሩ ይገነዘባሉ.

Cons:

• ጌታው አልሞተም ፣ ይልቁንም የአውታረ መረብ ብልሽት ተከስቷል። ያልተሳካለት, ይህንን ሳያውቅ, ቅጂውን ወደ ጌታው ያስተዋውቃል, አሮጌው ጌታ ግን መስራቱን ይቀጥላል. በውጤቱም, በመምህርነት ሚና ውስጥ ሁለት አገልጋዮችን እናገኛለን እና ከነሱ ውስጥ የትኛው የቅርብ ጊዜ ወቅታዊ መረጃ እንዳለው አናውቅም. ይህ ሁኔታ የተከፈለ-አንጎል ተብሎም ይጠራል;
• ምንም ምላሽ ሳናገኝ ቀረን። በእኛ ውቅር ውስጥ፣ ማስተር እና አንድ ቅጂ፣ ከተቀያየርን በኋላ፣ ቅጂው ወደ ጌታው ይንቀሳቀሳል እና ከአሁን በኋላ ቅጂዎች የሉንም፣ ስለዚህ አዲስ ቅጂ በእጅ መጨመር አለብን።
• 12 PostgreSQL ሻርዶች እያለን ስለ ውድቀት ኦፕሬሽን ተጨማሪ ክትትል እንፈልጋለን፣ ይህ ማለት 12 ክላስተሮችን መከታተል አለብን ማለት ነው። የሻርዶች ቁጥር እየጨመረ በመምጣቱ ያልተሳካውን ማዘመንዎን ማስታወስ አለብዎት.

በራስ የተጻፈ አለመሳካት በጣም የተወሳሰበ ይመስላል እና ቀላል ያልሆነ ድጋፍ ይፈልጋል። በአንድ የ PostgreSQL ዘለላ ይህ በጣም ቀላሉ አማራጭ ይሆናል ነገር ግን አይለካም ስለዚህ ለእኛ ተስማሚ አይደለም.

Repmgr

የPostgreSQL ዘለላዎች ማባዛት አስተዳዳሪ፣ የPostgreSQL ክላስተር ስራን ማስተዳደር ይችላል። በተመሳሳይ ጊዜ, ከሳጥኑ ውስጥ አውቶማቲክ ውድቀት የለውም, ስለዚህ ለስራ በተጠናቀቀው መፍትሄ ላይ የራስዎን "ማሸጊያ" መጻፍ ያስፈልግዎታል. ስለዚህ ሁሉም ነገር በራስ ከተፃፉ ስክሪፕቶች የበለጠ የተወሳሰበ ሊሆን ይችላል ፣ ስለሆነም እኛ Repmgrን እንኳን አልሞከርንም።

AWS RDS

የሚያስፈልገንን ነገር ሁሉ ይደግፋል፣ ምትኬዎችን እንዴት እንደሚሰራ ያውቃል እና የግንኙነቶችን ገንዳ ያቆያል። አውቶማቲክ መቀያየር አለው: ጌታው ሲሞት, ቅጂው አዲስ ጌታ ይሆናል, እና AWS የዲ ኤን ኤስ መዝገብ ወደ አዲሱ ማስተር ይለውጣል, ቅጂዎቹ በተለያዩ AZs ውስጥ ሊገኙ ይችላሉ.

ጉዳቶቹ ጥሩ ማስተካከያዎች አለመኖርን ያካትታሉ. እንደ ጥሩ ማስተካከያ ምሳሌ፡ የእኛ አጋጣሚዎች ለ 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 ላይ የምንጭ ኮድን ለማስተዳደር የፓይቶን አብነት ነው።

የ Patroni ጥቅሞች:

• እያንዳንዱ የውቅረት መለኪያ ይገለጻል, እንዴት እንደሚሰራ ግልጽ ነው;
• አውቶማቲክ ውድቀት ከሳጥኑ ውስጥ ይሠራል;
• በፓይቶን የተፃፈ ፣ እና እኛ እራሳችን በፓይቶን ውስጥ ብዙ ስለፃፍን ፣ ችግሮችን ለመቋቋም እና ምናልባትም የፕሮጀክቱን ልማት ለማገዝ ቀላል ይሆንልናል ።
• PostgreSQLን ሙሉ በሙሉ ያስተዳድራል፣ በሁሉም የክላስተር ኖዶች ላይ ያለውን ውቅረት በአንድ ጊዜ እንዲቀይሩ ይፈቅድልዎታል፣ እና ክላስተር አዲሱን ውቅር ለመተግበር እንደገና መጀመር ካለበት፣ ይህ Patroni በመጠቀም እንደገና ሊከናወን ይችላል።

Cons:

• ከ PgBouncer ጋር እንዴት በትክክል መስራት እንደሚቻል ከሰነዶቹ ውስጥ ግልጽ አይደለም. ምንም እንኳን ተቀንሶ ለመጥራት አስቸጋሪ ቢሆንም, ምክንያቱም የፓትሮኒ ተግባር PostgreSQL ን ማስተዳደር ነው, እና ከፓትሮኒ ጋር ያለው ግንኙነት እንዴት እንደሚሄድ ቀድሞውኑ የእኛ ችግር ነው;
• በትልልቅ ጥራዞች ላይ የፔትሮኒ አተገባበር ጥቂት ምሳሌዎች አሉ, ከባዶ የመተግበር ብዙ ምሳሌዎች አሉ.

በውጤቱም, ያልተሳካ ክላስተር ለመፍጠር Patroni ን መርጠናል.

Patroni ትግበራ ሂደት

ከፓትሮኒ በፊት፣ 12 PostgreSQL ሻርዶች በአንድ ማስተር ውቅር እና አንድ ቅጂ ባልተመሳሰል ድግግሞሽ ነበረን። አፕሊኬሽኑ ሰርቨሮች የመረጃ ቋቱን የደረሱት በኔትወርክ ሎድ ባላንስ በኩል ሲሆን ከኋላቸው ከ PgBouncer ጋር ሁለት አጋጣሚዎች ነበሩ እና ከኋላቸው ሁሉም የ PostgreSQL አገልጋዮች ነበሩ።


Patroni ን ለመተግበር የተከፋፈለ የማከማቻ ክላስተር ውቅረትን መምረጥ ያስፈልገናል። Patroni እንደ ወዘተd ፣ Zookeeper ፣ ቆንስል ካሉ ከተከፋፈሉ የውቅር ማከማቻ ስርዓቶች ጋር ይሰራል። ከቮልት ጋር በጥምረት የሚሰራ እና ከአሁን በኋላ የማንጠቀምበት የተሟላ የቆንስል ክላስተር በገበያ ላይ አለን:: ቆንስልን ለታለመለት አላማ መጠቀም ለመጀመር ጥሩ ምክንያት።

Patroni ከቆንስል ጋር እንዴት እንደሚሰራ

ሶስት አንጓዎችን ያቀፈ የቆንስል ክላስተር አለን እና ፓትሮኒ ክላስተር መሪ እና ቅጂ (በፓትሮኒ ውስጥ ጌታው የክላስተር መሪ ይባላል እና ባሪያዎቹ ቅጂዎች ይባላሉ)። እያንዳንዱ የPatroni ክላስተር ምሳሌ ስለ ክላስተር ሁኔታ ያለማቋረጥ ወደ ቆንስል ይልካል። ስለዚህ፣ ከቆንስል ሁል ጊዜ የፔትሮኒ ክላስተር የአሁኑን ውቅር እና በአሁኑ ጊዜ መሪ ማን እንደሆነ ማወቅ ይችላሉ።

Patroniን ከቆንስላ ጋር ለማገናኘት ከቆንስል ጋር በምንሰራበት መንገድ እና በግንኙነቱ እቅድ ላይ በመመስረት በ 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 }}

ይህ ግን አይሰራም። በሚነሳበት ጊዜ Patroni ከቆንስል ጋር መገናኘት አይችልም፣ ምክንያቱም በ http በኩል ለማለፍ ይሞክራል።

የ Patroni ምንጭ ኮድ ችግሩን ለመቋቋም ረድቷል. በፓይቶን መጻፉ ጥሩ ነው። የአስተናጋጁ ግቤት በምንም መንገድ አልተተነተነም ፣ እና ፕሮቶኮሉ በእቅድ ውስጥ መገለጽ አለበት። ከቆንስል ጋር አብሮ ለመስራት የሚሰራው የውቅር ማገጃ ለእኛ እንደዚህ ይመስላል።

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

ቆንስል-አብነት

ስለዚህ, ለማዋቀር ማስቀመጫውን መርጠናል. አሁን በፓትሮኒ ክላስተር ውስጥ መሪን ሲቀይሩ PgBouncer እንዴት አወቃቀሩን እንደሚቀይር መረዳት አለብን. በሰነዱ ውስጥ ለዚህ ጥያቄ ምንም መልስ የለም, ምክንያቱም. እዚያ, በመርህ ደረጃ, ከ PgBouncer ጋር መስራት አልተገለጸም.

መፍትሄን ለመፈለግ, ሱንሱል-አብነት PgBouncer እና Patroniን በማጣመር ብዙ እንደረዳ የተጻፈበት አንድ ጽሑፍ አገኘን (በሚያሳዝን ሁኔታ ርዕሱን አላስታውስም)። ይህ ኮንሰል-ቴምፕሌት እንዴት እንደሚሰራ እንድንመረምር አነሳሳን።

ቆንስል አብነት በቆንስል ውስጥ ያለውን የ PostgreSQL ክላስተር ውቅር በቋሚነት እንደሚከታተለው ታወቀ። መሪው ሲቀየር, የ PgBouncer ውቅረትን ያዘምናል እና እንደገና ለመጫን ትዕዛዝ ይልካል.

አብነት ትልቅ ፕላስ እንደ ኮድ መከማቸቱ ነው፣ ስለዚህ አዲስ ሸርተቴ ሲጨመር አዲስ ቃል መግባቱ እና አብነቱን በራስ ሰር ማዘመን በቂ ነው፣ መሠረተ ልማትን እንደ ኮድ መርህ ይደግፋል።

ከፓትሮኒ ጋር አዲስ ሥነ ሕንፃ

በውጤቱም, የሚከተለውን የስራ እቅድ አግኝተናል.


ሁሉም የመተግበሪያ አገልጋዮች ሚዛኑን ይደርሳሉ → ከጀርባው ሁለት የ PgBouncer አጋጣሚዎች አሉ → በእያንዳንዱ አጋጣሚ ኮንሰል-ቴምፕሌት ተጀምሯል, የእያንዳንዱን የፔትሮኒ ክላስተር ሁኔታ የሚከታተል እና የ PgBouncer ውቅረትን አስፈላጊነት የሚከታተል ሲሆን ይህም ለአሁኑ መሪ ጥያቄዎችን ይልካል. የእያንዳንዱ ዘለላ.

በእጅ መሞከር

ይህንን እቅድ በትንሽ የሙከራ አካባቢ ከመጀመርዎ በፊት እናሰራለን እና በራስ-ሰር የመቀያየርን አሠራር አረጋግጠናል ። ሰሌዳውን ከፍተው ተለጣፊውን አንቀሳቅሰዋል እና በዚያን ጊዜ የክላስተር መሪውን "ገደሉት". በAWS ውስጥ ይህ በኮንሶል በኩል ምሳሌውን እንደ መዝጋት ቀላል ነው።

ተለጣፊው በ10-20 ሰከንድ ውስጥ ተመልሶ ተመለሰ፣ እና ከዚያ እንደገና በመደበኛነት መንቀሳቀስ ጀመረ። ይህ ማለት የፓትሮኒ ክላስተር በትክክል ሰርቷል፡ መሪውን ለውጦ መረጃውን ወደ ሱንሱል ላከ እና ሱንሱል-አብነት ወዲያውኑ ይህንን መረጃ አነሳ፣ የ PgBouncer ውቅረትን ተክቶ እንደገና እንዲጫን ትዕዛዙን ላከ።

በከፍተኛ ጭነት ውስጥ እንዴት እንደሚተርፉ እና የእረፍት ጊዜን በትንሹ እንዲቆዩ ማድረግ?

ሁሉም ነገር በትክክል ይሰራል! ግን አዳዲስ ጥያቄዎች አሉ-በከፍተኛ ጭነት እንዴት እንደሚሰራ? በምርት ውስጥ ሁሉንም ነገር በፍጥነት እና በአስተማማኝ ሁኔታ እንዴት ማውጣት እንደሚቻል?

የጭነት ሙከራን የምንመራበት የሙከራ አካባቢ የመጀመሪያውን ጥያቄ እንድንመልስ ይረዳናል. በሥነ ሕንፃ ውስጥ ከምርት ጋር ሙሉ በሙሉ ተመሳሳይ ነው እና በድምጽ መጠን ከአምራች ጋር እኩል የሆነ የሙከራ መረጃን አምጥቷል። በፈተናው ወቅት ከPostgreSQL ጌቶች አንዱን "ለመግደል" እና ምን እንደሚፈጠር ለማየት እንወስናለን። ነገር ግን ከዚያ በፊት, አውቶማቲክ ማሽከርከርን ማረጋገጥ አስፈላጊ ነው, ምክንያቱም በዚህ አካባቢ ላይ ብዙ የ PostgreSQL ሸርተቴዎች አሉን, ስለዚህ ከማምረትዎ በፊት የውቅረት ስክሪፕቶችን በጣም ጥሩ ሙከራ እናገኛለን.

ሁለቱም ተግባራት የሥልጣን ጥመኞች ይመስላሉ፣ እኛ ግን PostgreSQL 9.6 አለን። ወዲያውኑ ወደ 11.2 ማሻሻል እንችላለን?

በ 2 ደረጃዎች ለማድረግ እንወስናለን-መጀመሪያ ወደ 11.2 አሻሽል, ከዚያም Patroni አስነሳ.

PostgreSQL ዝማኔ

የ PostgreSQL ሥሪትን በፍጥነት ለማዘመን፣ አማራጩን ይጠቀሙ -k, በየትኛው ደረቅ ማገናኛዎች በዲስክ ላይ እንደሚፈጠሩ እና ውሂብዎን መቅዳት አያስፈልግም. በ 300-400 ጊባ መሰረት, ዝመናው 1 ሰከንድ ይወስዳል.

ብዙ ሻርዶች አሉን ፣ ስለዚህ ዝመናው በራስ-ሰር መከናወን አለበት። ይህንን ለማድረግ አጠቃላይ የማሻሻያ ሂደቱን ለእኛ የሚያስተናግድ ሊቻል የሚችል የመጫወቻ መጽሐፍ ጽፈናል፡-

/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 መጀመሪያ ሲጀምሩ አዲስ የውሂብ ጎታ የማስጀመር ሃላፊነት አለበት። ነገር ግን አስቀድሞ የተዘጋጀ የውሂብ ጎታ ስላለን፣ ይህን ክፍል በቀላሉ ከማዋቀሩ ውስጥ አስወግደነዋል።

Patroni ቀድሞ በነበረው የ PostgreSQL ክላስተር ላይ መጫን ስንጀምር እና እሱን ማስኬድ ስንጀምር፣ አዲስ ችግር አጋጠመን፡ ሁለቱም አገልጋዮች እንደ መሪ ጀመሩ። Patroni ስለ ክላስተር መጀመሪያ ሁኔታ ምንም የሚያውቀው ነገር የለም እና ሁለቱንም አገልጋዮች ተመሳሳይ ስም ያላቸው እንደ ሁለት የተለያዩ ዘለላዎች ለመጀመር ይሞክራል። ይህንን ችግር ለመፍታት ማውጫውን በባሪያው ላይ ባለው መረጃ መሰረዝ ያስፈልግዎታል

rm -rf /var/lib/postgresql/

ይህ በባሪያው ላይ ብቻ መደረግ አለበት!

ንጹህ ቅጂ ሲገናኝ Patroni የመሠረት ባክአፕ መሪን ይሠራል እና ወደ ቅጂው ይመልሳል እና በዋል ሎግስ መሠረት አሁን ያለውን ሁኔታ ይይዛል።

ሌላው ያጋጠመን ችግር ሁሉም የPostgreSQL ስብስቦች በነባሪ ዋና መሰየማቸው ነው። እያንዳንዱ ዘለላ ስለሌላው ምንም የማያውቅ ከሆነ ይህ የተለመደ ነው። ነገር ግን Patroni ለመጠቀም ሲፈልጉ ሁሉም ስብስቦች ልዩ ስም ሊኖራቸው ይገባል. መፍትሄው በ PostgreSQL ውቅር ውስጥ የክላስተር ስም መቀየር ነው።

የጭነት ሙከራ

በቦርዶች ላይ የተጠቃሚን ልምድ የሚያስመስል ሙከራ ጀምረናል። ጭነቱ አማካኝ ዕለታዊ እሴታችን ላይ ሲደርስ፣ ተመሳሳይ ሙከራን ደግመናል፣ አንድ ምሳሌ ከPostgreSQL መሪ ጋር አጥፍተናል። አውቶማቲክ አለመሳካቱ እንደጠበቅነው ሰርቷል፡ Patroni መሪውን ለውጦ፣ ኮንሰል-አብነት የPgBouncer ውቅረትን አዘምኖ እንደገና እንዲጫን ትእዛዝ ልኳል። በግራፋና ውስጥ በግራፍቶቻችን መሰረት ከ20-30 ሰከንድ መዘግየቶች እና ከመረጃ ቋቱ ጋር ካለው ግንኙነት ጋር በተያያዙ አገልጋዮች ላይ አነስተኛ መጠን ያላቸው ስህተቶች እንዳሉ ግልጽ ነበር። ይህ የተለመደ ሁኔታ ነው ፣ እንደዚህ ያሉ እሴቶች ለድክመታችን ተቀባይነት ያላቸው እና በእርግጠኝነት ከአገልግሎት መስጫ ጊዜ የተሻሉ ናቸው።

Patroni ወደ ምርት ማምጣት

በውጤቱም, የሚከተለውን እቅድ አውጥተናል.

• ቆንስላ አብነት ወደ PgBouncer አገልጋዮች አሰማር እና አስነሳ;
• የ PostgreSQL ዝማኔዎች ወደ ስሪት 11.2;
• የክላስተር ስም ይቀይሩ;
• የ Patroni ክላስተር በመጀመር ላይ።

በተመሳሳይ ጊዜ የእኛ እቅድ በማንኛውም ጊዜ ማለት ይቻላል የመጀመሪያውን ነጥብ እንድናውቅ ያስችለናል ፣ እያንዳንዱን PgBouncer በተራው ከስራው እናስወግድ እና በላዩ ላይ ቆንስላ አብነት ማሰማራት እንችላለን ። ስለዚህ አደረግን።

ለፈጣን ማሰማራት፣ ሁሉንም የመጫወቻ መጽሐፍት በሙከራ አካባቢ ላይ ስለሞከርን እና የሙሉ ስክሪፕቱ የማስፈጸሚያ ጊዜ ለእያንዳንዱ ሻርድ ከ1,5 እስከ 2 ደቂቃ ነበር። አገልግሎታችንን ሳናቋርጥ ሁሉንም ነገር በየተራ ወደ እያንዳንዱ ሸርተቴ ልንዘረጋ እንችላለን፣ ግን እያንዳንዱን PostgreSQL ለብዙ ደቂቃዎች ማጥፋት አለብን። በዚህ አጋጣሚ ውሂባቸው በዚህ ሸርተቴ ላይ ያሉ ተጠቃሚዎች በዚህ ጊዜ ሙሉ በሙሉ መስራት አልቻሉም፣ እና ይህ ለእኛ ተቀባይነት የለውም።

ከዚህ ሁኔታ መውጫው በየ 3 ወሩ የሚካሄደው የታቀደው ጥገና ነበር. አገልግሎታችንን ሙሉ በሙሉ ዘግተን የውሂብ ጎታ ክፍሎቻችንን ስናሻሽል ይህ ለታቀደለት ሥራ መስኮት ነው። የሚቀጥለው መስኮት ሊቀረው አንድ ሳምንት ቀርቷል፣ እና ዝም ብለን ለመጠበቅ እና ተጨማሪ ለማዘጋጀት ወሰንን። በተጠባባቂው ጊዜ፣ እራሳችንን በተጨማሪነት አስጠብቀናል፡ ለእያንዳንዱ PostgreSQL ሸርተቴ፣ የቅርብ ጊዜውን መረጃ መያዝ ካልተሳካ ትርፍ ቅጂ አነሳን እና ለእያንዳንዱ ሻርድ አዲስ ምሳሌ ጨምረናል፣ ይህም በፓትሮኒ ክላስተር ውስጥ አዲስ ቅጂ መሆን አለበት። መረጃን ለመሰረዝ ትዕዛዝ ላለመፈጸም . ይህ ሁሉ የስህተት አደጋን ለመቀነስ ረድቷል.


አገልግሎታችንን እንደገና አስጀምረናል፣ ሁሉም ነገር እንደ ሚገባው ሰርቷል፣ ተጠቃሚዎች መስራታቸውን ቀጥለዋል፣ ነገር ግን በግራፍዎቹ ላይ በቆንስል አገልጋዮች ላይ ያልተለመደ ከፍተኛ ጭነት እንዳለ አስተውለናል።


ለምን በፈተና አካባቢ ይህንን አላየንም? ይህ ችግር መሠረተ ልማትን እንደ ኮድ መርህ መከተል እና አጠቃላይ መሠረተ ልማቶችን ከሙከራ አከባቢ እስከ ምርት ማጥራት እንደሚያስፈልግ በሚገባ ያሳያል። ያለበለዚያ ያገኘነውን ችግር ማግኘት በጣም ቀላል ነው። ምን ሆነ? ቆንስል በመጀመሪያ በምርት ላይ ታየ ፣ እና በሙከራ አከባቢዎች ፣ በውጤቱም ፣ በሙከራ አከባቢዎች ፣ የቆንስሉ እትም ከምርት የበለጠ ነበር። ልክ ከተለቀቁት በአንዱ ውስጥ፣ ከቆንስላ አብነት ጋር ሲሰራ የሲፒዩ መፍሰስ ተፈቷል። ስለዚህ፣ በቀላሉ ቆንስልን አዘምነናል፣ በዚህም ችግሩን ፈታን።

የ Patroni ስብስብን እንደገና ያስጀምሩ

ሆኖም ግን አዲስ ችግር ገጥሞናል፣ ምንም እንኳን ያልጠረጠርነው። ቆንስልን ስናዘምን በቀላሉ የቆንስላ ፈቃድ ትዕዛዝ → 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>

የPatroni ክላስተር ስለ ክላስተር መረጃ ማምጣት አልቻለም እና እንደገና ጀምሯል።

መፍትሄ ለማግኘት፣ በgithub ላይ ባለ ጉዳይ የ Patroni ደራሲዎችን አግኝተናል። በማዋቀር ፋይሎቻችን ላይ ማሻሻያዎችን ጠቁመዋል፡-

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

ችግሩን በሙከራ አካባቢ ላይ መድገም ችለናል እና እነዚህን አማራጮች እዚያ ሞክረናል፣ ግን በሚያሳዝን ሁኔታ እነሱ አልሰሩም።

ችግሩ አሁንም አልተፈታም. የሚከተሉትን መፍትሄዎች ለመሞከር አቅደናል:

• በእያንዳንዱ የ Patroni ክላስተር ምሳሌ ላይ የቆንስል ወኪልን ይጠቀሙ።
• በኮዱ ውስጥ ያለውን ችግር ያስተካክሉ።

ስህተቱ የት እንደተከሰተ እንረዳለን፡ ችግሩ ምናልባት በማዋቀር ፋይሉ ያልተሻረው ነባሪ ጊዜ ማብቂያ አጠቃቀም ነው። የመጨረሻው የቆንስል አገልጋይ ከክላስተር ሲወገድ አጠቃላይ የቆንስል ክላስተር ከአንድ ሰከንድ በላይ ይቆማል፣ በዚህ ምክንያት ፓትሮኒ የክላስተርን ሁኔታ ማግኘት አልቻለም እና ሙሉውን ስብስብ እንደገና ያስጀምራል።

እንደ እድል ሆኖ፣ ምንም ተጨማሪ ስህተቶች አላጋጠመንም።

Patroni መጠቀም ውጤቶች

ፓትሮኒ በተሳካ ሁኔታ ከተጀመረ በኋላ በእያንዳንዱ ዘለላ ውስጥ ተጨማሪ ቅጂ አክለናል። አሁን በእያንዳንዱ ክላስተር ውስጥ የምልአተ ጉባኤው አምሳያ አለ፡ አንድ መሪ ​​እና ሁለት ቅጂዎች፣ ሲቀይሩ አንጎል ከተሰነጠቀ ለሴፍቲኔት።


ፓትሮኒ በማምረት ላይ ከሦስት ወራት በላይ እየሰራ ነው. በዚህ ጊዜ እርሱ እኛን ለመርዳት ቀድሞውንም ቢሆን ችሏል። በቅርቡ፣ የአንዱ ዘለላ መሪ በAWS ውስጥ ሞተ፣ አውቶማቲክ ውድቀት ሰርቷል እና ተጠቃሚዎች መስራታቸውን ቀጥለዋል። ፓትሮኒ ዋና ሥራውን አሟልቷል.

የ Patroni አጠቃቀም ትንሽ ማጠቃለያ፡-

• የውቅረት ለውጦች ቀላልነት። በአንድ ምሳሌ ላይ አወቃቀሩን መቀየር በቂ ነው እና እስከ ሙሉ ክላስተር ድረስ ይሳባል. አዲሱን ውቅር ለመተግበር ዳግም ማስጀመር ካስፈለገ Patroni ያሳውቅዎታል። Patroni ሙሉውን ክላስተር በአንድ ትዕዛዝ እንደገና ማስጀመር ይችላል፣ ይህ ደግሞ በጣም ምቹ ነው።
• በራስ-ሰር አለመሳካት ይሰራል እና እኛን ለመርዳት አስቀድሞ ችሏል።
• የ PostgreSQL ዝማኔ ያለ የመተግበሪያ ማቆያ ጊዜ። መጀመሪያ ቅጂዎቹን ወደ አዲሱ ስሪት ማዘመን አለብዎት፣ ከዚያ በ Patroni ክላስተር ውስጥ ያለውን መሪ ይለውጡ እና የድሮውን መሪ ያዘምኑ። በዚህ ሁኔታ, አውቶማቲክ ውድቀት አስፈላጊው ሙከራ ይከሰታል.

ምንጭ: hab.com