ማንኛውም ትልቅ ፕሮጀክት በሁለት ሰርቨሮች ተጀምሯል። መጀመሪያ ላይ አንድ የዲቢ አገልጋይ ነበር፣ ከዚያም ንባቡን ለመለካት ባሮች ተጨመሩ። እና ከዚያ - አቁም! አንድ ጌታ አለ, ግን ብዙ ባሮች አሉ; ከባሮቹ አንዱ ከሄደ ሁሉም ነገር ደህና ይሆናል ፣ ግን ጌታው ከሄደ ፣ መጥፎ ይሆናል - የእረፍት ጊዜ ፣ አስተዳዳሪዎች አገልጋዩን ለማሳደግ እየሞከሩ ነው። ምን ለማድረግ? ዋና ቦታ ያስይዙ። የሥራ ባልደረባዬ ፓቬል ስለዚህ ጉዳይ አስቀድሞ ጽፏል ፣ አልደግመውም። በምትኩ፣ ለምን በእርግጠኝነት ኦርኬስትራ ለ MySQL እንደሚያስፈልግህ እነግርሃለሁ!
በዋናው ጥያቄ እንጀምር፡- “ጌታው ሲሄድ ኮዱን እንዴት ወደ አዲስ ማሽን እንቀይረው?”
- ከቪአይፒ (ምናባዊ አይፒ) ጋር እቅዱን በጣም እወዳለሁ ፣ ስለ እሱ ከዚህ በታች እንነጋገራለን ። በጣም ቀላሉ እና በጣም ግልጽ ነው, ምንም እንኳን ግልጽ የሆነ ገደብ ቢኖረውም: የምናስቀምጠው ጌታ በአዲሱ ማሽን በ L2 ክፍል ውስጥ መሆን አለበት, ማለትም, ስለ ሁለተኛው ዲሲ መርሳት እንችላለን. እና, በሰላማዊ መንገድ, አንድ ትልቅ L2 ክፉ ነው የሚለውን ህግ ከተከተሉ, ምክንያቱም L2 በአንድ መደርደሪያ ብቻ ነው, እና L3 በመደርደሪያዎቹ መካከል ነው, እና እንዲህ ዓይነቱ እቅድ የበለጠ ተጨማሪ ገደቦች አሉት.
- በኮዱ ውስጥ የዲ ኤን ኤስ ስም መጻፍ እና በ /etc/hosts በኩል መፍታት ይችላሉ። በእውነቱ, ምንም መፍትሄ አይኖርም. የመርሃግብሩ ጠቀሜታ-የመጀመሪያው ዘዴ ምንም አይነት ገደብ ባህሪ የለውም, ማለትም, መስቀል-ዲሲን ማደራጀት ይቻላል. ግን ግልጽ የሆነው ጥያቄ የሚነሳው፡ ለውጡን በምን ያህል ፍጥነት ወደ /etc/hosts በአሻንጉሊት-አንሲብል በኩል ማድረስ እንችላለን?
- ሁለተኛውን ዘዴ ትንሽ መለወጥ ይችላሉ-መሸጎጫ ዲ ኤን ኤስ በሁሉም የድር አገልጋዮች ላይ ይጫኑ ፣ በዚህ በኩል ኮዱ ወደ ዋና ዳታቤዝ ይሄዳል። ለዚህ ግቤት TTL 60 ማቀናበር ትችላለህ ዲ ኤን ኤስ። በትክክል ከተተገበረ, ዘዴው ጥሩ ይመስላል.
- የቆንስልና ወዘተ አጠቃቀምን የሚያመለክት የአገልግሎት ግኝት ያለው እቅድ።
- ጋር አስደሳች አማራጭ . ሁሉንም ትራፊክ ወደ MySQL በProxySQL በኩል ማምራት አለቦት፤ ፕሮክሲኤስQL ራሱ ማን ጌታ እንደሆነ ሊወስን ይችላል። በነገራችን ላይ, ይህንን ምርት ለመጠቀም ስለ አንዱ አማራጮች በእኔ ውስጥ ማንበብ ይችላሉ .
የኦርኬስትራ ደራሲ በ Github ውስጥ እየሰራ በመጀመሪያ የመጀመሪያውን እቅድ ከቪአይፒ ጋር ተግባራዊ አደረገ እና ከዚያም ወደ ቆንስላ ለውጦታል።
የተለመደው የመሠረተ ልማት አቀማመጥ፡-
ግምት ውስጥ መግባት ያለባቸውን ግልጽ ሁኔታዎች ወዲያውኑ እገልጻለሁ-
- የቪአይፒ አድራሻው በማንኛውም አገልጋይ ላይ ባለው ውቅረት ውስጥ መመዝገብ የለበትም። እስቲ አንድ ሁኔታን እናስብ: ጌታው እንደገና ተነሳ, እና እየተጫነ ሳለ, ኦርኬስትራ ወደ ውድቀት ሁነታ ሄዶ ከባሮቹ አንዱን ጌታ አደረገ; ከዚያም አሮጌው ጌታ ተነሳ, እና አሁን ቪአይፒ በሁለት መኪኖች ላይ ነው. ይህ መጥፎ ነው።
- ለኦርኬስትራ (ኦርኬስትራ) አሮጌውን ጌታ እና አዲሱን ጌታ ለመጥራት ስክሪፕት መጻፍ ያስፈልግዎታል. በአሮጌው ጌታ ላይ ifdown ማሄድ ያስፈልግዎታል ፣ እና በአዲሱ ጌታ ላይ - ifup vip። በዚህ ስክሪፕት ውስጥ መጨናነቅ በሚፈጠርበት ጊዜ በአሮጌው ማስተር ማብሪያ / ማጥፊያ ላይ ያለው ወደብ በቀላሉ መከፋፈሉን ለማስወገድ እንዲዘጋ ቢደረግ ጥሩ ነው።
- ኦርኬስትራዎ መጀመሪያ ቪአይፒን ለማስወገድ እና/ወይም በማቀያየር ላይ ያለውን ወደብ ለማጥፋት ስክሪፕትዎን ከጠራ በኋላ እና በአዲሱ ጌታ ላይ የቪአይፒ ማሳደጊያ ስክሪፕት ከጠራ በኋላ አዲሱ ቪአይፒ አሁን መሆኑን ለሁሉም ሰው ለመንገር የአርፒንግ ትዕዛዙን መጠቀምዎን አይርሱ። እዚህ.
- ሁሉም ባሪያዎች ማንበብ የነበረባቸው_only=1 ነው፡ እና ባሪያውን ለጌታው እንዳስተዋወቅክ፡ መነበብ የነበረበት_only=0 ነው።
- ለዚህ የመረጥነው ማንኛውም ባሪያ ጌታ ሊሆን እንደሚችል መዘንጋት የለባችሁም (ኦርኬስትራተሩ ለአዲሱ ጌታ እጩ ሆኖ የሚቆጠርበት ሙሉ ምርጫ ዘዴ አለው፣ ይህም በሁለተኛ ደረጃ እና የትኛው ባሪያ መሆን እንዳለበት) በምንም አይነት ሁኔታ መመረጥ የለበትም ዋና). ባሪያው ጌታ ከሆነ የባሪያው ሸክም በላዩ ላይ ይቆያል እና የጌታው ሸክም ይጨመራል, ይህ ግምት ውስጥ መግባት አለበት.
ኦርኬስትራ ከሌለህ ለምን አስፈለገህ?
- ኦርኬስትራተር ሙሉውን ቶፖሎጂ የሚያሳይ ለተጠቃሚ ምቹ የሆነ ስዕላዊ በይነገጽ አለው (ከዚህ በታች ያለውን ቅጽበታዊ ገጽ እይታ ይመልከቱ)።
- ኦርኬስትራ የትኛዎቹ ባሪያዎች ወደ ኋላ እንደቀሩ እና ማባዛት በአጠቃላይ የተበላሹበትን መከታተል ይችላል (ኤስኤምኤስ ለመላክ ከኦርኬስትራተሩ ጋር ተያይዘናል)።
- ኦርኬስትራተሩ የትኞቹ ባሪያዎች የGTID ስህተት እንዳለባቸው ይነግርዎታል።
የኦርኬስትራ በይነገጽ፡-
GTID ስህተት ምንድን ነው?
ኦርኬስትራ ለመስራት ሁለት ዋና መስፈርቶች አሉ፡-
- በ MySQL ክላስተር ውስጥ ባሉ ሁሉም ማሽኖች ላይ የውሸት GTID መንቃቱ አስፈላጊ ነው፤ GTID ነቅተናል።
- በሁሉም ቦታ አንድ ዓይነት ቢንሎግ መኖሩ አስፈላጊ ነው, መግለጫን መጠቀም ይችላሉ. እኛ ጌታው እና አብዛኞቹ ባሮች ረድፍ ያላቸውበት ውቅር ነበረን ፣ እና ሁለቱ በታሪክ በድብልቅ ሞድ ውስጥ ይቀራሉ። በዚህ ምክንያት ኦርኬስትራ እነዚህን ባሪያዎች ከአዲሱ ጌታ ጋር ማገናኘት አልፈለገም.
በማምረት ባሪያ ውስጥ በጣም አስፈላጊው ነገር ከጌታው ጋር ያለው ወጥነት መሆኑን ያስታውሱ! በሁለቱም ጌታህ እና ባሪያህ ላይ የነቃ የአለምአቀፍ ግብይት መታወቂያ (GTID) ካለህ በነዚህ ማሽኖች ላይ ተመሳሳይ የውሂብ ለውጥ ጥያቄዎች መፈጸሙን ለማወቅ የ gtid_subset ተግባርን መጠቀም ትችላለህ። ስለዚህ ጉዳይ የበለጠ ማንበብ ይችላሉ .
ስለዚህ ኦርኬስትራተሩ በ GTID ስህተት በኩል በባሪያው ላይ የሌሉ ግብይቶች እንዳሉ ያሳየዎታል። ይህ ለምን እየሆነ ነው?
- Read_only=1 በባሪያው ላይ አልነቃም፣ የሆነ ሰው አገናኝቶ ውሂብ የመቀየር ጥያቄን አጠናቋል።
- Super_read_only=1 በባሪያው ላይ አልነቃም ከዚያም አስተዳዳሪው አገልጋዩን ግራ በመጋባት ገብተው ጥያቄውን እዛው ፈጸሙ።
- ሁለቱንም ቀዳሚ ነጥቦች ከግምት ውስጥ ካስገቡ ፣ ከዚያ አንድ ተጨማሪ ብልሃት አለ-በ MySQL ውስጥ ፣ ቢንሎጎችን የማፍሰስ ጥያቄ እንዲሁ ወደ ቢንሎግ ይሄዳል ፣ ስለዚህ በመጀመሪያ ማጠብ ፣ የ GTID ስህተት በጌታው እና በሁሉም ባሪያዎች ላይ ይታያል። ይህንን እንዴት ማስወገድ ይቻላል? ፔሮና-5.7.25-28 የቢንሎግ_skip_flush_commands=1 መቼት አስተዋውቋል፣ይህም ወደ ቢንሎግ መጣጥፍን ይከለክላል። በ mysql.com ድህረ ገጽ ላይ የተቋቋመ አለ። .
ከላይ ያሉትን ሁሉንም ላጠቃልል። እስካሁን ድረስ ኦርኬስትራተሩን በ failover ሁነታ መጠቀም ካልፈለጉ, ከዚያ ወደ ምልከታ ሁነታ ያስቀምጡት. ከዚያ ሁል ጊዜ በዓይንዎ ፊት የ MySQL ማሽኖችን መስተጋብር ካርታ እና በእያንዳንዱ ማሽን ላይ ምን አይነት ማባዛት እንዳለ ፣ባሮቹ ወደ ኋላ ቀርተው እንደሆነ እና ከሁሉም በላይ ደግሞ ከጌታው ጋር ምን ያህል ወጥነት እንዳላቸው የሚያሳይ የእይታ መረጃ ይኖርዎታል!
ግልጽ የሆነው ጥያቄ “ኦርኬስትራ እንዴት መሥራት አለበት?” የሚለው ነው። አሁን ካሉት ባሪያዎች አዲስ ጌታን መምረጥ አለበት እና ከዚያም ሁሉንም ባሪያዎች ከእሱ ጋር ማገናኘት አለበት (GTID የሚያስፈልገው ለዚህ ነው፡ የድሮውን ሜካኒኬሽን በቢንሎግ_ስም እና ቢንሎግ_ፖስ ከተጠቀምክ ባሪያውን ከአሁኑ ጌታ ወደ አዲስ መቀየር) በቀላሉ የማይቻል ነው!). ኦርኬስትራ ከመድረሳችን በፊት፣ አንድ ጊዜ ይህንን ሁሉ በእጅ ማድረግ ነበረብኝ። አሮጌው ጌታ በአዳፕቴክ መቆጣጠሪያ ምክንያት ተንጠልጥሎ ነበር፡ ወደ 10 የሚጠጉ ባሮች ነበሩት። ቪአይፒን ከጌታው ወደ አንዱ ባሪያ ማዛወር እና ሌሎች ባሮችን በሙሉ ከሱ ጋር ማገናኘት ነበረብኝ። ስንት ኮንሶሎች መክፈት አለብኝ፣ ስንት በአንድ ላይ ያሉ ትዕዛዞችን ገባሁ... እስከ 3 ሰአት መጠበቅ ነበረብኝ፣ ጭነቱን ከሁለት በቀር ከሁሉም ባሪያዎች ላይ አውጥቼ፣ የሁለቱን ጌታዎች የመጀመሪያ ማሽን ሰራሁ፣ ወዲያው ሁለተኛውን ማሽን ያያዝኩት። በእሱ ላይ, ስለዚህ ሁሉንም ባሪያዎች ከአዲሱ ጌታ ጋር በማያያዝ ሸክሙን ይመልሱ. በአጠቃላይ ፣ አስፈሪ…
ኦርኬስትራ ወደ ውድቀት ሁነታ ሲሄድ እንዴት ነው የሚሰራው? ይህ በቀላሉ አንድ ጌታን አሁን ካለንበት የበለጠ ኃይለኛ እና የበለጠ ዘመናዊ ማሽን ለማድረግ በምንፈልግበት ሁኔታ ምሳሌ ይገለጻል።
ስዕሉ የሂደቱን መካከለኛ ያሳያል. እስከዚህ ነጥብ ድረስ ምን ተሠርቷል? አንዳንድ ባሪያዎችን አዲሱን ጌታ ለማድረግ እንፈልጋለን አልን ፣ ኦርኬስትራተር በቀላሉ ሌሎች ባሪያዎችን ከሱ ጋር ማገናኘት ጀመረ ፣ አዲሱ ጌታ እንደ ማመላለሻ ማሽን ይሠራል። በዚህ እቅድ ምንም ስህተት አይከሰትም, ሁሉም ባሪያዎች ይሠራሉ, ኦርኬስትራ ቪአይፒን ከአሮጌው ጌታ ያነሳል, ወደ አዲሱ ያስተላልፋል, read_only=0 እና የአሮጌውን ጌታ ይረሳል. ሁሉም! የአገልግሎታችን የቀነሰበት ጊዜ የቪአይፒ ማስተላለፊያ ጊዜ ሲሆን ይህም ከ2-3 ሰከንድ ነው።
ለዛሬ ያ ብቻ ነው ለሁሉም አመሰግናለሁ። በቅርቡ ስለ ኦርኬስትራ ሁለተኛ መጣጥፍ ይኖራል። በታዋቂው የሶቪዬት ፊልም "ጋራዥ" ውስጥ አንድ ገጸ ባህሪ "ከእሱ ጋር ስለላ አልሄድም!" ስለዚህ ኦርኬስትራተር፣ ስለላ አብሬህ እሄድ ነበር!
ምንጭ: hab.com