የኦዲሴይ የመንገድ ካርታ፡ ከግንኙነት ገንዳ ሌላ ምን እንፈልጋለን። አንድሬ ቦሮዲን (2019)

በሪፖርቱ ውስጥ ፣አንድሬ ቦሮዲን የግንኙነት ገንዳውን ሲነድፉ PgBouncer የመለጠጥ ልምድን እንዴት እንደወሰዱ ይነግርዎታል። የተጓተተውወደ ምርት ሲዘዋወሩ። በተጨማሪም ፣ በአዲሱ ስሪቶች ውስጥ ምን ዓይነት የመጎተቻ ተግባራትን ማየት እንደምንፈልግ እንነጋገራለን-ፍላጎታችንን ማሟላት ብቻ ሳይሆን የተጠቃሚውን ማህበረሰብ ማዳበር ለእኛ አስፈላጊ ነው ። ኦዲሲ.

ቪዲዮ

ሰላም ሁላችሁም! ስሜ አንድሪው ነው።

በ Yandex ውስጥ የክፍት ምንጭ የውሂብ ጎታዎችን እዘጋጃለሁ። እና ዛሬ ስለ የግንኙነት ፑለር ግንኙነቶች ርዕስ አለን.

በሩሲያኛ የግንኙነት ፑልለርን እንዴት እንደሚደውሉ ካወቁ ከዚያ ይንገሩኝ። በቴክኒካል ስነ-ጽሑፍ ውስጥ መመስረት ያለበት ጥሩ ቴክኒካዊ ቃል ለማግኘት በእውነት እፈልጋለሁ.

ርዕሱ በጣም የተወሳሰበ ነው ፣ ምክንያቱም በብዙ የውሂብ ጎታዎች ውስጥ የግንኙነት ገንዳው አብሮገነብ ነው እና ስለሱ ማወቅ እንኳን አያስፈልግዎትም። በእርግጥ, በሁሉም ቦታ አንዳንድ ቅንብሮች አሉ, ነገር ግን በ Postgres ውስጥ እንደዚያ አይሰራም. እና በትይዩ (በሃይሎድ++ 2019) በ Postgres ውስጥ መጠይቆችን ስለማዘጋጀት በኒኮላይ ሳሞክቫሎቭ የቀረበ ዘገባ አለ። እና እኔ እንደተረዳሁት፣ ጥያቄዎቻቸውን በትክክል ያዋቀሩ ሰዎች ወደዚህ መጡ፣ እና እነዚህ ከአውታረ መረብ እና ከንብረት አጠቃቀም ጋር በተያያዙ በጣም አልፎ አልፎ የስርዓት ችግሮች ያጋጠሟቸው ሰዎች ናቸው። እና በአንዳንድ ቦታዎች ችግሮቹ ግልጽ ስላልሆኑ በጣም አስቸጋሪ ሊሆን ይችላል.

Yandex Postgres አለው። ብዙ የ Yandex አገልግሎቶች በ Yandex.Cloud ውስጥ ይኖራሉ። እና በፖስትግሬስ ውስጥ ቢያንስ አንድ ሚሊዮን ጥያቄዎችን በሰከንድ የሚያመነጭ በርካታ petabytes ውሂብ አለን።

እና ለሁሉም አገልግሎቶች ትክክለኛ ደረጃውን የጠበቀ ዘለላ እናቀርባለን - ይህ የመስቀለኛ መንገድ ዋና ዋና መስቀለኛ መንገድ ነው ፣ የተለመደው ሁለት ቅጂዎች (የተመሳሰለ እና ያልተመሳሰለ) ፣ ምትኬ ፣ የንባብ ጥያቄዎችን በማባዛቱ ላይ።

እያንዳንዱ የክላስተር መስቀለኛ መንገድ Postgres ነው፣ በዚህ ላይ ከፖስትግሬስ እና የክትትል ስርዓቶች በተጨማሪ የግንኙነት ገንዳ ተጭኗል። Connection pooler ለአጥር እና ለዋና ዓላማው ጥቅም ላይ ይውላል.

የግንኙነት ገንዳ ዋና ዓላማ ምንድነው?

Postgres ከዳታቤዝ ጋር ሲሰራ የሂደቱን ሞዴል ይቀበላል። ይህ ማለት አንድ ግንኙነት አንድ ሂደት ነው, አንድ Postgres backend. እና በዚህ ጀርባ ውስጥ ብዙ የተለያዩ መሸጎጫዎች አሉ, ይህም ለተለያዩ ግንኙነቶች የተለየ ለማድረግ በጣም ውድ ነው.

በተጨማሪም የፖስትግሬስ ኮድ procArray የሚባል ድርድር አለው። ስለ አውታረ መረብ ግንኙነቶች መሰረታዊ መረጃ ይዟል. እና ሁሉም ማለት ይቻላል የፕሮካሬይ ማቀነባበሪያ ስልተ ቀመሮች የመስመር ውስብስብነት አላቸው ፣ እነሱ በጠቅላላው የአውታረ መረብ ግንኙነቶች ላይ ይሰራሉ። በጣም ቆንጆ ፈጣን ዑደት ነው፣ ነገር ግን ብዙ ገቢ ባላቸው የአውታረ መረብ ግንኙነቶች ነገሮች ትንሽ የበለጠ ውድ ይሆናሉ። እና ነገሮች ትንሽ የበለጠ ውድ ሲሆኑ፣ ለብዙ የአውታረ መረብ ግንኙነቶች በጣም ከፍተኛ ዋጋ መክፈል ይችላሉ።

3 ሊሆኑ የሚችሉ ዘዴዎች አሉ-

• በማመልከቻው በኩል.
• በመረጃ ቋቱ በኩል።
• እና በመካከል, ማለትም, ሁሉም አይነት ጥምሮች.

እንደ አለመታደል ሆኖ አብሮ የተሰራው ገንዳ በአሁኑ ጊዜ በመገንባት ላይ ነው። በ PostgreSQL ፕሮፌሽናል ያሉ ጓደኞቻችን ይህንን በአብዛኛው ያደርጉታል። መቼ እንደሚታይ ለመተንበይ አስቸጋሪ ነው። እና በእውነቱ, አርክቴክት ለመምረጥ ሁለት መፍትሄዎች አሉን. እነዚህ የመተግበሪያ-ጎን ገንዳ እና ተኪ ገንዳ ናቸው።

የመተግበሪያ-ጎን ገንዳ ቀላሉ መንገድ ነው. እና ሁሉም ማለት ይቻላል የደንበኛ ነጂዎች መንገድ ይሰጡዎታል፡ በሚሊዮኖች የሚቆጠሩ ግንኙነቶችዎን በኮድ ውስጥ እንደ በርካታ ደርዘን ግንኙነቶች ከመረጃ ቋቱ ጋር ያቅርቡ።

የሚፈጠረው ችግር በአንድ የተወሰነ ነጥብ ላይ የጀርባውን መጠን ለመለካት ይፈልጋሉ, ወደ ብዙ ምናባዊ ማሽኖች ማሰማራት ይፈልጋሉ.

ከዚያ ብዙ ተጨማሪ ተደራሽነት ዞኖች፣ በርካታ የመረጃ ማዕከሎች እንዳሉዎት ይገነዘባሉ። እና የደንበኛው ጎን የመዋሃድ አቀራረብ ወደ ብዙ ቁጥሮች ይመራል. ትላልቆቹ ወደ 10 የሚጠጉ ግንኙነቶች ናቸው። ይህ በመደበኛነት ሊሠራ የሚችል ጠርዝ ነው.

ስለ ፕሮክሲ ፑልለርስ ከተነጋገርን ብዙ ነገር ሊያደርጉ የሚችሉ ሁለት ፑልተሮች አሉ። ገንዳዎች ብቻ አይደሉም። እነሱ ገንዳዎች + የበለጠ ጥሩ ተግባራት ናቸው። ይህ ፒግፑል и ክራንቺ-ተኪ.

ግን በሚያሳዝን ሁኔታ, ሁሉም ሰው ይህን ተጨማሪ ተግባር አይፈልግም. እና ገንዳዎች የክፍለ ጊዜ መዋሃድን ብቻ ​​ይደግፋሉ፣ ማለትም አንድ ገቢ ደንበኛ፣ አንድ ወጪ ደንበኛ ወደ ዳታቤዝ።

ይህ ለእኛ ዓላማዎች በጣም ተስማሚ አይደለም, ስለዚህ የግብይት ማሰባሰብን የሚተገበረውን PgBouncer እንጠቀማለን, ማለትም የአገልጋይ ግንኙነቶች ከደንበኛ ግንኙነቶች ጋር የሚዛመዱት ለግብይቱ ጊዜ ብቻ ነው.

እና በእኛ የሥራ ጫና, ይህ እውነት ነው. ግን ጥቂት ችግሮች አሉ.

ችግሮቹ የሚጀምሩት ክፍለ ጊዜን ለመመርመር ሲፈልጉ ነው፣ ምክንያቱም ሁሉም ገቢ ግንኙነቶችዎ አካባቢያዊ ናቸው። ሁሉም ሰው ተመልሶ መጣ እና እንደምንም ክፍለ ጊዜውን መከታተል አስቸጋሪ ይሆናል።

በእርግጥ አፕሊኬሽን_ስም_አድድ_ሆስትን መጠቀም ትችላለህ። ይህ በ Bouncer በኩል የአይፒ አድራሻን ወደ መተግበሪያ_ስም ለመጨመር የሚያስችል መንገድ ነው። ግን አፕሊኬሽኑ_ስም በተጨማሪ ግንኙነት ተቀናብሯል።

በዚህ ግራፍ ላይ፣ ቢጫው መስመር እውነተኛ ጥያቄዎች በሆነበት፣ እና ሰማያዊው መስመር ወደ ዳታቤዝ የሚበሩ ጥያቄዎች ባሉበት። እና ይህ ልዩነት በትክክል የመተግበሪያ_ስም ጭነት ነው ፣ ይህም ለመከታተል ብቻ የሚያስፈልገው ግን በጭራሽ ነፃ አይደለም።

በተጨማሪም, Bouncer ውስጥ አንድ ገንዳ መገደብ አይችሉም, ማለትም በአንድ የተወሰነ ተጠቃሚ የውሂብ ጎታ ግንኙነቶች ብዛት, በአንድ የተወሰነ የውሂብ ጎታ.

ይህ ወደ ምን ይመራል? በC++ የተፃፈ የተጫነ አገልግሎት አለህ እና በአቅራቢያህ ያለ ትንሽ አገልግሎት በመስቀለኛ ቋቱ ላይ ምንም አይነት አስፈሪ ነገር በመረጃ ቋቱ የማይሰራ ነገር ግን ሾፌሩ አብዷል። 20 ግንኙነቶችን ይከፍታል እና ሁሉም ነገር ይጠብቃል. የእርስዎ ኮድ እንኳን የተለመደ ነው።

እኛ፣ በእርግጥ፣ ይህን ቅንብር የሚያክል ትንሽ ፕላስተር ለ Bouncer ጻፍን፣ ማለትም ደንበኞችን ወደ ገንዳው መገደብ።

ይህንን በ Postgres በኩል ማድረግ ይቻል ይሆናል, ማለትም, በመረጃ ቋቱ ውስጥ ያሉትን ሚናዎች በግንኙነቶች ብዛት ይገድቡ.

ግን ለምን ከአገልጋዩ ጋር ምንም ግንኙነት እንደሌለዎት የመረዳት ችሎታ ያጣሉ. PgBouncer የግንኙነት ስህተት አይጥልም, ሁልጊዜ ተመሳሳይ መረጃን ይመልሳል. እና እርስዎ ሊረዱት አይችሉም: ምናልባት የይለፍ ቃልዎ ተቀይሯል, ምናልባት የውሂብ ጎታው አሁን ጠፍቶ ሊሆን ይችላል, ምናልባት የሆነ ችግር አለ. ነገር ግን ምንም ዓይነት ምርመራ የለም. አንድ ክፍለ ጊዜ መመስረት ካልተቻለ ለምን ሊቋቋም እንደማይችል አታውቁም.

በአንድ የተወሰነ ነጥብ ላይ የመተግበሪያውን ግራፎች ይመለከታሉ እና አፕሊኬሽኑ እየሰራ እንዳልሆነ ይመለከታሉ.

ከላይ ይመልከቱ እና Bouncer ነጠላ-ክር መሆኑን ይመልከቱ። ይህ በአገልግሎቱ ሕይወት ውስጥ ትልቅ ለውጥ ነው. በአንድ ዓመት ተኩል ውስጥ የውሂብ ጎታውን ለመለካት እየተዘጋጁ እንደነበር ይገነዘባሉ፣ እና ገንዳውን መመዘን ያስፈልግዎታል።

ተጨማሪ PgBouncers ያስፈልገናል የሚል መደምደሚያ ላይ ደርሰናል።

https://lwn.net/Articles/542629/

Bouncer ትንሽ ተስተካክሏል።

እና ብዙ Bouncers የ TCP ወደብን እንደገና በመጠቀም እንዲነሱ አደረጉ። እና ስርዓተ ክወናው ክብ-ሮቢን በመጠቀም በመካከላቸው የሚመጡ የ TCP ግንኙነቶችን በራስ-ሰር ያስተላልፋል።

ይህ ለደንበኞች ግልጽ ነው፣ ይህ ማለት አንድ Bouncer ያለህ ይመስላል፣ ነገር ግን Bouncersን በማሄድ መካከል ያለ ስራ ፈት ግንኙነቶች መቆራረጥ አለብህ።

እና በተወሰነ ቅጽበት እነዚህ 3 Bouncers እያንዳንዳቸው በ 100% አንኳራቸውን እንደሚበሉ ሊያስተውሉ ይችላሉ። በጣም ጥቂት Bouncers ያስፈልግዎታል። ለምን?

ምክንያቱም TLS አለህ። የተመሰጠረ ግንኙነት አለህ። እና Postgresን ከTLS ጋር እና ያለሱ ካመረመሩት የተመሰረቱ ግንኙነቶች ቁጥር ምስጠራ ከነቃ በሁለት ቅደም ተከተሎች በሚጠጋ መጠን ቀንሷል ፣ ምክንያቱም የቲኤልኤስ መጨባበጥ የሲፒዩ ሀብቶችን ስለሚበላ።

እና ከላይ የገቢ ግንኙነቶች ማዕበል በሚኖርበት ጊዜ የሚከናወኑትን በጣም ጥቂት ምስጢራዊ ተግባራትን ማየት ይችላሉ። የእኛ ዋና በተገኝነት ዞኖች መካከል መቀያየር ስለሚችል፣ የገቢ ግንኙነቶች ማዕበል በጣም የተለመደ ሁኔታ ነው። ያም ማለት በሆነ ምክንያት የድሮው ዋና ቦታ አይገኝም, ሙሉው ጭነት ወደ ሌላ የውሂብ ማዕከል ተልኳል. ሁሉም በተመሳሳይ ጊዜ ለቲኤልኤስ ሰላም ለማለት ይመጣሉ።

እና ብዙ ቁጥር ያለው የቲኤልኤስ መጨባበጥ ለ Bouncer ሰላም ማለት ላይሆን ይችላል፣ ግን ጉሮሮውን ይጨምቃል። በጊዜ ማብቂያ ምክንያት፣ የገቢ ግንኙነቶች ማዕበል ያልተዳከመ ሊሆን ይችላል። ያለ ገላጭ የኋላ መጥፋት ወደ መሰረቱ እንደገና ከሞከሩ፣ በተጣመረ ማዕበል ውስጥ ደጋግመው አይመጡም።

16 ኮሮችን በ16% የሚጭኑ የ100 PgBouncers ምሳሌ እዚህ አለ።

ወደ ፏፏቴው PgBouncer ደርሰናል። ይህ Bouncer ጋር በእኛ ጭነት ላይ ሊደረስበት የሚችል ምርጥ ውቅር ነው. የእኛ ውጫዊ Bouncers ለ TCP የእጅ መጨባበጥ ጥቅም ላይ ይውላሉ, እና ውስጣዊ Bouncers ውጫዊ ግንኙነቶችን ከመጠን በላይ ላለመበታተን ለትክክለኛ ገንዳ ጥቅም ላይ ይውላሉ.

በዚህ ውቅር ውስጥ, ለስላሳ ዳግም ማስጀመር ይቻላል. እነዚህን ሁሉ 18 Bouncers አንድ በአንድ እንደገና ማስጀመር ይችላሉ። ግን እንዲህ ዓይነቱን ውቅር ማቆየት በጣም ከባድ ነው። Sysadmins፣ DevOps እና ለዚህ አገልጋይ ተጠያቂ የሆኑ ሰዎች በዚህ ዝግጅት በጣም ደስተኛ አይሆኑም።

ሁሉም ማሻሻያዎቻችን ወደ ክፍት ምንጭ የሚያድጉ ይመስላል፣ ነገር ግን Bouncer በደንብ አይደገፍም። ለምሳሌ፣ በአንድ ወደብ ላይ በርካታ PgBouncersን የማስኬድ ችሎታ ከአንድ ወር በፊት ተፈጽሟል። ከበርካታ አመታት በፊት ከዚህ ባህሪ ጋር የመሳብ ጥያቄ ነበር።

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

ወይም አንድ ተጨማሪ ምሳሌ። በ Postgres ውስጥ፣ ያለአስፈላጊ ማረጋገጫ ምስጢሩን ወደ ሌላ ግንኙነት በመላክ በሂደት ላይ ያለ ጥያቄን መሰረዝ ይችላሉ። ነገር ግን አንዳንድ ደንበኞች በቀላሉ የ TCP ዳግም ማስጀመርን ይልካሉ, ማለትም የአውታረ መረብ ግንኙነቱን ያቋርጣሉ. Bouncer ምን ያደርጋል? ምንም አያደርግም። ጥያቄውን መፈጸም ይቀጥላል. በትንሽ ጥያቄዎች የውሂብ ጎታ የፈጠሩ እጅግ በጣም ብዙ ግንኙነቶችን ከተቀበሉ ፣ ግንኙነቱን ከ Bouncer ማቋረጥ ብቻ በቂ አይሆንም ፣ እንዲሁም በመረጃ ቋቱ ውስጥ እየሰሩ ያሉትን ጥያቄዎች ማጠናቀቅ ያስፈልግዎታል።

ይህ ተስተካክሏል እና ይህ ችግር ገና ወደ Bouncer ጅረት አልተዋሃደም።

እና ስለዚህ እኛ የራሳችንን የግንኙነት ፑልለር እንፈልጋለን ወደሚል መደምደሚያ ላይ ደርሰናል ፣ እሱም የሚዳብር ፣ የሚለጠፍ ፣ ችግሮች በፍጥነት የሚስተካከሉበት እና በእርግጥ ፣ ባለብዙ-ክር መሆን አለበት።

መልቲ-ክርክርን እንደ ዋና ተግባር አዘጋጅተናል። የገቢ TLS ግንኙነቶችን ሞገድ በደንብ መቆጣጠር መቻል አለብን።

ይህንን ለማድረግ ማቺናሪየም የሚባል የተለየ ቤተ መፃህፍት ማዘጋጀት ነበረብን፣ እሱም የኔትወርክ ግንኙነትን የማሽን ሁኔታዎች እንደ ቅደም ተከተል ኮድ ለመግለጽ ታስቦ የተሰራ ነው። የlibpq ምንጭ ኮድ ከተመለከቱ ውጤቱን ሊመልሱልዎ የሚችሉ እና “በኋላ ደውልልኝ። አሁን ለአሁኑ አይኦ አለኝ፣ ግን አይኦ ሲሄድ ፕሮሰሰሩ ላይ ሸክም ይኖረኛል። እና ይህ ባለብዙ ደረጃ እቅድ ነው. የአውታረ መረብ ግንኙነት አብዛኛውን ጊዜ በስቴት ማሽን ይገለጻል. እንደ “ከዚህ በፊት የመጠን ፓኬት ራስጌ ከተቀበልኩ አሁን N ባይት እየጠበቅኩ ነው”፣ “የSYNC ፓኬት ከላኩኝ አሁን የውጤት ዲበ ዳታ ያለው ፓኬት እየጠበቅኩ ነው።” ውጤቱ ወደ መስመር ቅኝት የተቀየረ ይመስል ውጤቱ በጣም አስቸጋሪ፣ ተቃራኒ ኮድ ነው። እኛ ያደረግነው ከስቴት ማሽን ይልቅ ፕሮግራመርተኛው የግንኙነቱን ዋና መንገድ በተለመደው የግድ ኮድ መልክ ይገልፃል። በዚህ አስፈላጊ ኮድ ውስጥ ከአውታረ መረቡ ላይ መረጃን በመጠባበቅ የአፈፃፀም ቅደም ተከተል መቋረጥ ያለባቸውን ቦታዎች ማስገባት ብቻ ነው, የአፈፃፀም አውድ ወደ ሌላ ኮሮቲን (አረንጓዴ ክር) በማለፍ. ይህ አቀራረብ በሜዝ ውስጥ በጣም የሚጠበቀውን መንገድ በተከታታይ ከመጻፍ እና ከዛም ቅርንጫፎችን ከመጨመር ጋር ተመሳሳይ ነው.

በውጤቱም፣ TCP የሚቀበል እና ክብ ሮቢን የ TPC ግንኙነትን ለብዙ ሰራተኞች የሚያስተላልፍ አንድ ክር አለን።

በዚህ አጋጣሚ እያንዳንዱ የደንበኛ ግንኙነት ሁልጊዜ በአንድ ፕሮሰሰር ላይ ይሰራል። እና ይሄ መሸጎጫ-ተስማሚ ለማድረግ ያስችልዎታል.

እና በተጨማሪ፣ የስርዓቱን TCP ቁልል ለማስታገስ የትናንሽ ፓኬቶችን ስብስብ ወደ አንድ ትልቅ ፓኬት በትንሹ አሻሽለናል።

በተጨማሪም፣ Odyssey ሲዋቀር የኔትወርክ ግኑኝነት ብልሽት ሲያጋጥም ሰርዝ እና ROLLBACK መላክ ይችላል ማለትም ማንም ጥያቄ የማይጠብቅ ከሆነ ኦዲሴይ የውሂብ ጎታውን እንዳይሞክር ይነግረዋል። ውድ ሀብቶችን ሊያባክን የሚችለውን ጥያቄ ማሟላት.

እና በተቻለ መጠን ከተመሳሳይ ደንበኛ ጋር ግንኙነቶችን እንቀጥላለን። ይህ አፕሊኬሽን_ስም_አድ_ሆስትን ዳግም መጫንን ያስወግዳል። ይህ የሚቻል ከሆነ ለምርመራዎች የሚያስፈልጉትን መለኪያዎች በተጨማሪ እንደገና ማስጀመር የለብንም.

በ Yandex.Cloud ፍላጎቶች እንሰራለን. እና የሚተዳደር PostgreSQLን ከተጠቀሙ እና የግንኙነት ገንዳ ከተጫነ ወደ ውጭ ምክንያታዊ ማባዛትን መፍጠር ይችላሉ፣ ማለትም፣ ከፈለጉ፣ ምክንያታዊ ማባዛትን በመጠቀም ይተውን። Bouncer አመክንዮአዊ ብዜት ፍሰት ውጭ አይለቅም።

ይህ አመክንዮአዊ ማባዛትን የማዋቀር ምሳሌ ነው።

በተጨማሪም፣ ወደ ውጭ ለአካላዊ መራባት ድጋፍ አለን። በክላውድ ውስጥ, በእርግጥ, ይህ የማይቻል ነው, ምክንያቱም ከዚያ ክላስተር ስለራሱ ብዙ መረጃ ይሰጥዎታል. ነገር ግን በእርስዎ ጭነቶች ውስጥ፣ በኦዲሲ ውስጥ ባለው የግንኙነት ፑለር በኩል አካላዊ ማባዛት ከፈለጉ፣ ይህ ይቻላል።

ኦዲሴይ ከPgBouncer ጋር ሙሉ ለሙሉ ተስማሚ የሆነ ክትትል አለው። ሁሉንም ተመሳሳይ ትዕዛዞችን የሚያሄድ አንድ አይነት ኮንሶል አለን። የሆነ ነገር ከጠፋ፣ የመጎተት ጥያቄን ወይም ቢያንስ ችግር በ GitHub ላይ ይላኩ እና አስፈላጊዎቹን ትዕዛዞች እናሟላለን። ግን የ PgBouncer ኮንሶል ዋና ተግባር ቀድሞውኑ አለን።

እና በእርግጥ፣ የማስተላለፍ ስህተት አለን። በመረጃ ቋቱ የተዘገበውን ስህተት እንመልሰዋለን። በመረጃ ቋቱ ውስጥ ለምን እንዳልተካተቱ መረጃ ይደርሰዎታል, እና እርስዎ በእሱ ውስጥ ያልተካተቱ ብቻ አይደሉም.

ከPgBouncer ጋር 100% ተኳሃኝነት ካስፈለገዎት ይህ ባህሪ ተሰናክሏል። በአስተማማኝ ጎን ለመሆን ልክ እንደ Bouncer አይነት ባህሪ ማሳየት እንችላለን።

ልማት

ስለ ኦዲሴይ ምንጭ ኮድ ጥቂት ቃላት።

https://github.com/yandex/odyssey/pull/66

ለምሳሌ፣ “Pause/Resume” ትዕዛዞች አሉ። አብዛኛውን ጊዜ የውሂብ ጎታውን ለማዘመን ያገለግላሉ. Postgresን ማዘመን ከፈለጉ በግንኙነት ፑለር ውስጥ ባለበት ማቆም፣ pg_upgrade ያድርጉ፣ ከዚያ ከቆመበት ይቀጥሉ። እና ከደንበኛው ጎን የመረጃ ቋቱ በቀላሉ እየቀነሰ ያለ ይመስላል። ይህ ተግባር ከማህበረሰቡ በመጡ ሰዎች ነው ያመጡልን። እሷ ገና አልቀዘቀዘችም ፣ ግን በቅርቡ ሁሉም ነገር ይሆናል። (ቀድሞውኑ የቀዘቀዘ)

https://github.com/yandex/odyssey/pull/73 - አስቀድሞ የቀዘቀዘ

በተጨማሪም, በ PgBouncer ውስጥ ካሉት አዲስ ባህሪያት አንዱ ለ SCRAM ማረጋገጫ ድጋፍ ነው, እሱም በ Yandex.Cloud ውስጥ የማይሰራ ሰው ያመጣን. ሁለቱም ውስብስብ ተግባራት እና አስፈላጊ ናቸው.

ስለዚህ አሁን ትንሽ ኮድ መጻፍ ከፈለጉ ኦዲሴይ የተሰራውን ልነግርዎ እፈልጋለሁ።

በሁለት ዋና ቤተ-መጻሕፍት ላይ የሚመረኮዝ የኦዲሲ ምንጭ መሠረት አለዎት። የኪዊ ቤተ መፃህፍት የፖስትግሬስ መልእክት ፕሮቶኮል ትግበራ ነው። ማለትም፡ የ Postgres ቤተኛ ፕሮቶ 3 የፊት እና የኋላ ጫፍ የሚለዋወጡት መደበኛ መልዕክቶች ነው። በኪዊ ቤተ-መጽሐፍት ውስጥ ይተገበራሉ.

የማቺናሪየም ቤተ-መጽሐፍት የክር መተግበርያ ቤተ-መጽሐፍት ነው። የዚህ Machinarium ትንሽ ቁራጭ በስብሰባ ቋንቋ ተጽፏል። ግን አትደናገጡ ፣ 15 መስመሮች ብቻ አሉ።

የኦዲሴይ ሥነ ሕንፃ። ኮርቲኖች የሚሠሩበት ዋና ማሽን አለ። ይህ ማሽን ገቢ የ TCP ግንኙነቶችን መቀበል እና በሠራተኞች መካከል በማሰራጨት ይተገበራል።

የበርካታ ደንበኞች ተቆጣጣሪ በአንድ ሰራተኛ ውስጥ ሊሰራ ይችላል. ዋናው ክር ደግሞ ኮንሶል እና የክሮን ስራዎችን በማቀናበር በኩሬው ውስጥ የማይፈለጉ ግንኙነቶችን ይሰርዛል.

ኦዲሴይ የሚፈተነው መደበኛውን የፖስትግሬስ የሙከራ ስብስብን በመጠቀም ነው። መጫን-ቼክን በ Bouncer በኩል እና በኦዲሲ በኩል እናካሂዳለን፣ null div እናገኛለን። Bouncer እና Odyssey ውስጥ በትክክል ተመሳሳይ የማያልፉ ከቀን ቅርጸት ጋር የተያያዙ በርካታ ሙከራዎች አሉ።

በተጨማሪም, የራሳቸው ፈተና ያላቸው ብዙ አሽከርካሪዎች አሉ. እና ፈተናዎቻቸውን ኦዲሲን ለመፈተሽ እንጠቀማለን.

በተጨማሪም ፣በካስኬድ አወቃቀራችን ምክንያት የተለያዩ ቅርቅቦችን መሞከር አለብን፡ Postgres + Odyssey፣ PgBouncer + Odyssey፣ Odyssey + Odyssey በካስኬድ ውስጥ ካሉት ክፍሎች ውስጥ ኦዲሴ ከተጠናቀቀ አሁንም እንደሚሰራ እርግጠኛ ለመሆን። እንደምንጠብቀው.

Rake

ኦዲሲን በምርት ውስጥ እንጠቀማለን. እና ሁሉም ነገር ይሰራል ካልኩ ፍትሃዊ አይሆንም። አይደለም፣ ማለትም፣ አዎ፣ ግን ሁልጊዜ አይደለም። ለምሳሌ፣ በምርት ላይ ሁሉም ነገር አሁን ሰርቷል፣ከዚያ ከ PostgreSQL ፕሮፌሽናል የመጡ ጓደኞቻችን መጡ እና የማስታወሻ መፍሰስ እንዳለብን ነገሩን። እነሱ በእርግጥ ነበሩ፣ አስተካክለናቸው። ግን ቀላል ነበር.

ከዚያ የግንኙነት ፑልለር ገቢ TLS ግንኙነቶች እና ወጪ TLS ግንኙነቶች እንዳሉት ደርሰንበታል። እና ግንኙነቶች የደንበኛ ሰርተፊኬቶች እና የአገልጋይ ሰርተፊኬቶች ያስፈልጋቸዋል።

የ Bouncer እና Odyssey አገልጋይ ሰርተፊኬቶች በፒሲቸው ድጋሚ ይነበባሉ፣ ነገር ግን የደንበኛ ሰርተፊኬቶች ከፒሲኬ እንደገና መነበብ አያስፈልጋቸውም፣ ምክንያቱም የእኛ scalable Odyssey በመጨረሻ ይህንን ሰርተፍኬት በማንበብ የስርዓት አፈጻጸም ውስጥ ስለሚገባ ነው። ይህ ለእኛ አስደንቆናል, ምክንያቱም ለመቃወም ብዙ ጊዜ አልወሰደበትም. መጀመሪያ ላይ መስመራዊ በሆነ መልኩ ጨምሯል፣ ነገር ግን ከ20 ገቢ በአንድ ጊዜ ግንኙነቶች በኋላ ይህ ችግር እራሱን አሳይቷል።

ሊሰካ የሚችል የማረጋገጫ ዘዴ አብሮገነብ የሉኑክስ መሳሪያዎችን በመጠቀም የማረጋገጥ ችሎታ ነው። በ PgBouncer ውስጥ ከ PAM ምላሽ ለመጠበቅ የተለየ ክር እንዲኖር እና የአሁኑን ግንኙነት የሚያገለግል እና በ PAM ፈትል ውስጥ እንዲኖሩ የሚጠይቅ ዋና የ PgBouncer ክር አለ ።

ይህንን ተግባራዊ ያደረግነው በአንድ ቀላል ምክንያት አይደለም። ብዙ ክሮች አሉን። ይህ ለምን ያስፈልገናል?

ይህ በመጨረሻ ችግሮች ሊፈጥር ይችላል የ PAM ማረጋገጫ እና የPAM ያልሆነ ማረጋገጫ ካሎት፣ ትልቅ የPAM ማረጋገጫ የPAM ያልሆነውን ማረጋገጫ በእጅጉ ሊያዘገየው ይችላል። ካላስተካከልናቸው ነገሮች አንዱ ይሄ ነው። ግን ማስተካከል ከፈለጉ ይህን ማድረግ ይችላሉ.

ሌላው መሰቅሰቂያ ሁሉንም ገቢ ግንኙነቶች የሚቀበል አንድ ክር አለን. እና ከዚያ ወደ ሰራተኛ ገንዳ ይዛወራሉ, የቲኤልኤስ መጨባበጥ ይከናወናል.

የታችኛው መስመር፣ የ20 የአውታረ መረብ ግንኙነቶች ወጥ የሆነ ሞገድ ካለህ ሁሉም ይቀበላሉ። እና በደንበኛው በኩል libpq የጊዜ ማብቂያዎችን ሪፖርት ማድረግ ይጀምራል። በነባሪነት 000 ሰከንድ ይመስላል።

ሁሉም በአንድ ጊዜ የውሂብ ጎታውን ማስገባት ካልቻሉ, ወደ ዳታቤዝ ማስገባት አይችሉም, ምክንያቱም ይህ ሁሉ ገላጭ ባልሆነ ድጋሚ መሞከር ሊሸፈን ይችላል.

እኛ የተቀበልንበትን የ TCP ግንኙነቶች ብዛት በማቃለል እቅዱን ከ PgBouncer ቀድተናል ወደሚል መደምደሚያ ላይ ደርሰናል።

ግንኙነቶችን እየተቀበልን መሆኑን ከተመለከትን ፣ ግን በመጨረሻ ለመጨባበጥ ጊዜ ከሌላቸው ፣ የሲፒዩ ሀብቶችን እንዳያባክን ወረፋ ውስጥ እናስቀምጣቸዋለን ። ይህ ለደረሱት ግንኙነቶች ሁሉ በአንድ ጊዜ መጨባበጥ ላይሆን ይችላል የሚለውን እውነታ ይመራል። ነገር ግን ቢያንስ አንድ ሰው ወደ ዳታቤዝ ይገባል፣ ጭነቱ በጣም ከባድ ቢሆንም።

በየክፍል

ወደፊት በኦዲሲ ምን ማየት ይፈልጋሉ? እራሳችንን ለማሳደግ ምን ዝግጁ ነን እና ከማህበረሰቡ ምን እንጠብቃለን?

ከኦገስት 2019 ጀምሮ።

የኦዲሴይ ፍኖተ ካርታ በነሐሴ ወር ይህን ይመስላል፡-

• SCRAM እና PAM ማረጋገጥ እንፈልጋለን።
• የንባብ ጥያቄዎችን ወደ ተጠባባቂነት ማስተላለፍ እንፈልጋለን።
• የመስመር ላይ ዳግም መጀመር እፈልጋለሁ።
• እና በአገልጋዩ ላይ ለአፍታ የማቆም ችሎታ።

የዚህ ፍኖተ ካርታ ግማሹ የተጠናቀቀ ነው እንጂ በእኛ አይደለም። ይህ ደግሞ ጥሩ ነው። ስለዚህ የቀረውን እንወያይ እና ተጨማሪ እንጨምር።

ወደ ተጠባባቂነት የሚቀርቡ የንባብ-ብቻ መጠይቆችን በተመለከተ? ጥያቄዎችን ሳናስፈጽም አየሩን በቀላሉ የሚያሞቁ ቅጂዎች አሉን። ውድቀትን እና መቀያየርን እንዲሰጡን እንፈልጋለን። በአንዱ የውሂብ ማእከሎች ውስጥ ችግሮች ካጋጠሙኝ አንዳንድ ጠቃሚ ስራዎችን ልይዛቸው እፈልጋለሁ. ተመሳሳዩን ማዕከላዊ ፕሮሰሰር ማዋቀር ስለማንችል፣ ተመሳሳይ ማህደረ ትውስታን በተለየ መንገድ ማዋቀር ስለማንችል፣ አለበለዚያ ማባዛት አይሰራም።

በመርህ ደረጃ, በ Postgres, ከ 10 ጀምሮ, በሚገናኙበት ጊዜ session_attrs ን መግለጽ ይቻላል. በግንኙነቱ ውስጥ ያሉትን ሁሉንም የውሂብ ጎታ አስተናጋጆች መዘርዘር እና ለምን ወደ ዳታቤዝ እንደሚሄዱ መናገር ይችላሉ-መፃፍ ወይም ማንበብ ብቻ። እና ሹፌሩ ራሱ በዝርዝሩ ውስጥ የመጀመሪያውን አስተናጋጅ ይመርጣል ፣ እሱም በጣም የሚወደውን ፣ ይህም የክፍለ-አትተርን መስፈርቶች ያሟላል።

ነገር ግን የዚህ አቀራረብ ችግር የማባዛት መዘግየትን አለመቆጣጠሩ ነው. ለአገልግሎትዎ ተቀባይነት ለሌላቸው ጊዜ ያህል ወደኋላ የቀረ ቅጂ ሊኖርዎት ይችላል። የንባብ መጠይቆችን በብዜት ሙሉ ለሙሉ እንዲፈፀም ለማንቃት፣ ኦዲሴ ሊነበብ በማይችልበት ጊዜ እንዳይሮጥ መቻልን መደገፍ አለብን።

Odyssey ከጊዜ ወደ ጊዜ ወደ ዳታቤዝ በመሄድ እና ከዋናው የማባዛት ርቀት መጠየቅ አለበት. እና ገደቡ እሴቱ ላይ ከደረሰ፣ አዲስ ጥያቄዎችን ወደ ዳታቤዝ አይፍቀዱ፣ ለደንበኛው እንደገና ግንኙነቶችን መጀመር እንዳለበት ይንገሩ እና ምናልባትም ጥያቄዎችን ለማስፈጸም ሌላ አስተናጋጅ ይምረጡ። ይህ የመረጃ ቋቱ የማባዛት መዘግየትን በፍጥነት እንዲመልስ እና በጥያቄ ለመመለስ እንደገና እንዲመለስ ያስችለዋል።

ለትግበራ ጊዜ ገደብ መስጠት አስቸጋሪ ነው, ምክንያቱም ክፍት ምንጭ ነው. ነገር ግን፣ ከPgBouncer እንደ ባልደረቦቼ 2,5 ዓመት ሳይሆን ተስፋ አደርጋለሁ። በኦዲሲ ውስጥ ማየት የምፈልገው ባህሪ ይህ ነው።

በማህበረሰቡ ውስጥ ሰዎች ለተዘጋጀው መግለጫ ድጋፍ ጠይቀዋል. አሁን የተዘጋጀ መግለጫ በሁለት መንገዶች መፍጠር ይችላሉ. በመጀመሪያ የ SQL ትዕዛዝን ማለትም "ተዘጋጅቶ" መፈጸም ይችላሉ. ይህንን የSQL ትዕዛዝ ለመረዳት በቡውንሰር በኩል ያለውን SQL መረዳት መማር አለብን። ይህ ከመጠን በላይ መወጠር ይሆናል፣ ምክንያቱም ከመጠን በላይ ነው፣ ምክንያቱም ሙሉውን ተንታኝ ስለምንፈልግ። እያንዳንዱን የSQL ትዕዛዝ መተንተን አንችልም።

ነገር ግን በፕሮቶ3 ላይ በመልእክት ፕሮቶኮል ደረጃ የተዘጋጀ መግለጫ አለ። እናም ይህ የተዘጋጀ መግለጫ እየተፈጠረ ያለው መረጃ በተዋቀረ መልክ ሲመጣ ይህ ቦታ ነው. እና በአንዳንድ የአገልጋይ ግንኙነት ደንበኛው የተዘጋጀ መግለጫዎችን እንዲፈጥር መጠየቁን መደገፍ እንችላለን። እና ግብይቱ ቢዘጋም አሁንም በአገልጋዩ እና በደንበኛው መካከል ያለውን ግንኙነት መጠበቅ አለብን።

ነገር ግን እዚህ በንግግሩ ውስጥ አለመግባባት ይፈጠራል, ምክንያቱም አንድ ሰው ደንበኛው የፈጠረው ምን ዓይነት የተዘጋጁ መግለጫዎችን መረዳት እንዳለብዎት እና ይህንን የአገልጋይ ግንኙነት በፈጠሩት ደንበኞች መካከል ያለውን የአገልጋይ ግንኙነት ማጋራት ያስፈልግዎታል, ማለትም, እንደዚህ አይነት የተዘጋጀ መግለጫ የፈጠረው.

አንድሬስ ፍሬውንድ በሌላ የአገልጋይ ግንኙነት ውስጥ እንደዚህ ያለ የተዘጋጀ መግለጫ የፈጠረ ደንበኛ ወደ እርስዎ ቢመጣ ለእሱ ይፍጠሩ። ነገር ግን ከደንበኛው ይልቅ በመረጃ ቋቱ ውስጥ መጠይቆችን መፈፀም ትንሽ ስህተት ይመስላል ነገር ግን ከዳታቤዙ ጋር መስተጋብር ለመፍጠር ፕሮቶኮሉን ከሚጽፈው ገንቢ እይታ አንጻር በቀላሉ የአውታረ መረብ ግንኙነት ቢሰጠው ምቹ ነው። እንዲህ ያለ የተዘጋጀ ጥያቄ አለ.

እና ልንተገበር የሚገባን አንድ ተጨማሪ ባህሪ. አሁን ከPgBouncer ጋር የሚስማማ ክትትል አለን። አማካዩን የጥያቄ ማስፈጸሚያ ጊዜ መመለስ እንችላለን። ነገር ግን አማካይ ጊዜ በሆስፒታሉ ውስጥ ያለው አማካይ የሙቀት መጠን ነው: አንዳንዶቹ ቀዝቃዛዎች, አንዳንዶቹ ሞቃት ናቸው - በአማካይ ሁሉም ሰው ጤናማ ነው. እውነት አይደለም.

ሀብትን የሚያባክኑ ቀርፋፋ መጠይቆች መኖራቸውን የሚጠቁሙ እና ክትትልን የበለጠ ተቀባይነት ያለው ለማድረግ ለፐርሰንታይሎች ድጋፍን መተግበር አለብን።

በጣም አስፈላጊው ነገር ስሪት 1.0 እፈልጋለሁ (ስሪት 1.1 አስቀድሞ ተለቋል)። እውነታው ግን Odyssey አሁን በ 1.0rc ስሪት ውስጥ ነው, ማለትም የመልቀቂያ እጩ. እና እኔ የዘረዘርኳቸው ችግሮች ሁሉ ከማስታወሻ መፍሰስ በስተቀር በትክክል በተመሳሳይ ስሪት ተስተካክለዋል ።

ስሪት 1.0 ለኛ ምን ማለት ነው? ኦዲሲን ወደ መሠረታችን እየገለጥን ነው። ቀድሞውንም በእኛ የውሂብ ጎታ ላይ እየሰራ ነው፣ ነገር ግን በሰከንድ 1 ጥያቄዎች ነጥብ ላይ ሲደርስ ይህ የተለቀቀው ስሪት ነው እና ይህ 000 ተብሎ ሊጠራ የሚችል ስሪት ነው ማለት እንችላለን።

በማህበረሰቡ ውስጥ ያሉ በርካታ ሰዎች ስሪት 1.0 ለአፍታ ማቆም እና SCRAM ን ጠይቀዋል። ነገር ግን ይህ ማለት ቀጣዩን ስሪት ወደ ምርት መልቀቅ ያስፈልገናል ማለት ነው፣ ምክንያቱም SCRAMም ሆነ ለአፍታ ማቆም ገና አልተገደሉም። ግን ፣ ምናልባት ፣ ይህ ጉዳይ በፍጥነት መፍትሄ ያገኛል ።

የመሳብ ጥያቄህን እየጠበቅኩ ነው። ከ Bouncer ጋር ምን ችግሮች እንዳሉዎት መስማት እፈልጋለሁ። እንወያይባቸው። ምናልባት እርስዎ የሚፈልጉትን አንዳንድ ተግባራትን መተግበር እንችላለን.

ይህ የኔ ክፍል መጨረሻ ነው እናንተን ማዳመጥ እፈልጋለሁ። አመሰግናለሁ!

ጥያቄዎች

የራሴን መተግበሪያ_ስም ካዘጋጀሁ፣ በኦዲሲ ውስጥ የግብይት ማሰባሰብን ጨምሮ በትክክል ይተላለፋል?

ኦዲሴይ ወይስ Bouncer?

በኦዲሲ ውስጥ. በ Bouncer ውስጥ ይጣላል.

ስብስብ እንሰራለን.

እና የእኔ እውነተኛ ግንኙነት በሌሎች ግንኙነቶች ላይ ቢወድቅ ይተላለፋል?

በዝርዝሩ ውስጥ የተዘረዘሩትን ሁሉንም መለኪያዎች እንሰራለን. app_name በዚህ ዝርዝር ውስጥ እንዳለ ማወቅ አልችልም። እዚያ ያየሁት ይመስለኛል። ሁሉንም ተመሳሳይ መለኪያዎች እናዘጋጃለን. በአንድ ጥያቄ, ስብስቡ በጅማሬው ወቅት በደንበኛው የተጫነውን ሁሉ ያደርጋል.

አንድሬ ለሪፖርቱ እናመሰግናለን! ጥሩ ዘገባ! ኦዲሴ በየደቂቃው በፍጥነት እና በፍጥነት እያደገ በመምጣቱ ደስተኛ ነኝ። በዚህ መቀጠል እፈልጋለሁ። Odyssey በአንድ ጊዜ ከተለያዩ የውሂብ ጎታዎች ማለትም ከዋና ባርያ ጋር እንዲገናኝ እና ከተሳካለት በኋላ በራስ-ሰር ከአዲስ ጌታ ጋር እንዲገናኝ ቀደም ሲል የብዙ ዳታ-ምንጭ ግንኙነት እንዲኖርዎት ጠይቀናል።

አዎ፣ ይህንን ውይይት ያስታውሰኝ ይመስላል። አሁን ብዙ ማከማቻዎች አሉ። ነገር ግን በመካከላቸው ምንም መቀያየር የለም. በእኛ በኩል አገልጋዩ አሁንም በህይወት እንዳለ መጠይቅ እና አለመሳካት መከሰቱን መረዳት አለብን፣ ማን pg_recovery ብሎ ይጠራል። ወደ ጌታው እንዳልመጣን አንድ ደረጃውን የጠበቀ የመረዳት ዘዴ አለኝ። እና ከስህተቶቹ እንደምንም እንረዳለን ወይንስ ምን? ማለትም ሀሳቡ አስደሳች ነው እየተወያየበት ነው። ተጨማሪ አስተያየቶችን ይጻፉ። C የሚያውቁ ሰራተኞች ካሉዎት ያ በጣም ጥሩ ነው።

በቅጂዎች ላይ የመለካት ጉዳይ ለእኛም ትኩረት የሚስብ ነው፣ ምክንያቱም የተባዙ ስብስቦችን መቀበል ለመተግበሪያ ገንቢዎች በተቻለ መጠን ቀላል ማድረግ እንፈልጋለን። ግን እዚህ ተጨማሪ አስተያየቶችን እፈልጋለሁ, ማለትም በትክክል እንዴት ማድረግ እንዳለብኝ, እንዴት በጥሩ ሁኔታ እንደሚሰራ.

ጥያቄው ስለ ቅጂዎችም ጭምር ነው። ዋና እና ብዙ ቅጂዎች እንዳሉዎት ሆኖአል። እና ለግንኙነቶች ከጌታው ያነሰ በተደጋጋሚ ወደ ቅጂው እንደሚሄዱ ግልጽ ነው, ምክንያቱም ልዩነቶች ሊኖራቸው ይችላል. የመረጃው ልዩነት ንግድዎን የማያረካ ሊሆን ይችላል እና እስኪደገም ድረስ ወደዚያ አይሄዱም ብለዋል ። በተመሳሳይ ጊዜ, ለረጅም ጊዜ ወደዚያ ካልሄዱ እና ከዚያ መሄድ ከጀመሩ, አስፈላጊው መረጃ ወዲያውኑ አይገኝም. ማለትም ፣ ያለማቋረጥ ወደ ጌታው የምንሄድ ከሆነ ፣ እዚያ ያለው መሸጎጫ ይሞቃል ፣ ግን በቅጅው ውስጥ መሸጎጫው ትንሽ ይቀራል።

አዎ እውነት ነው. ፒሲኬው የሚፈልጓቸው የውሂብ እገዳዎች አይኖሩትም, እውነተኛው መሸጎጫ ስለፈለጉት ጠረጴዛዎች መረጃ አይኖረውም, እቅዶቹ የተተነተኑ መጠይቆች አይኖራቸውም, ምንም ነገር አይኖርም.

እና አንድ ዓይነት ክላስተር ሲኖርዎት እና እዚያ አዲስ ቅጂ ሲጨምሩ ፣ ከዚያ ሲጀመር ፣ ሁሉም ነገር በውስጡ መጥፎ ነው ፣ ማለትም መሸጎጫውን ይጨምራል።

ሀሳቡን ገባኝ። ትክክለኛው አቀራረብ በመጀመሪያ ቅጂው ላይ ትንሽ መቶኛ መጠይቆችን ማስኬድ ነው ፣ ይህም መሸጎጫውን ያሞቀዋል። በግምት፣ ከ10 ሰከንድ ባልበለጠ ጊዜ ውስጥ ጌታውን ወደ ኋላ የምንቀርበት ሁኔታ አለን። እና ይህ ሁኔታ በአንድ ሞገድ ውስጥ አልተካተተም, ግን ለአንዳንድ ደንበኞች በተቀላጠፈ.

አዎ ክብደት ይጨምሩ።

ይህ ጥሩ ሀሳብ ነው። ግን መጀመሪያ ይህንን መዘጋት መተግበር አለብን። በመጀመሪያ ማጥፋት አለብን, እና ከዚያ እንዴት ማብራት እንዳለብን እናስባለን. ይህ ያለችግር ለማንቃት በጣም ጥሩ ባህሪ ነው።

Nginx ይህ አማራጭ አለው። slowly start ለአገልጋዩ በክላስተር። እና ጭነቱን ቀስ በቀስ ይጨምራል.

አዎ፣ ጥሩ ሀሳብ፣ ወደ እሱ ስንሄድ እንሞክራለን።

ምንጭ: hab.com