ProHoster > Blogs > Administrācija > Orchestrator for MySQL: kāpēc jūs nevarat izveidot defektu izturīgu projektu bez tā

Orchestrator for MySQL: kāpēc jūs nevarat izveidot defektu izturīgu projektu bez tā

JebkurÅ” liels projekts sākās ar pāris serveriem. Sākumā bija viens DB serveris, tad tam tika pievienoti vergi, lai mērogotu nolasÄ«jumu. Un tad - stop! Ir viens saimnieks, bet daudz vergu; ja kāds no vergiem aizies, tad viss bÅ«s kārtÄ«bā, bet ja saimnieks aizies, tad bÅ«s slikti: dÄ«kstāve, admini mēģina serveri pacelt. Ko darÄ«t? Rezervējiet meistaru. Mans kolēģis Pāvels par to jau rakstÄ«ja raksts, Es to neatkārtoÅ”u. Tā vietā es jums pastāstÄ«Å”u, kāpēc jums noteikti ir nepiecieÅ”ams Orchestrator for MySQL!

Sāksim ar galveno jautājumu: "Kā mēs pārslēgsim kodu uz jaunu maŔīnu, kad meistars aizies?"

  • Man visvairāk patÄ«k shēma ar VIP (Virtual IP), par to mēs runāsim tālāk. Tas ir visvienkārŔākais un acÄ«mredzamākais, lai gan tam ir acÄ«mredzams ierobežojums: kapteinim, kuru mēs rezervēsim, ar jauno maŔīnu jāatrodas L2 segmentā, tas ir, mēs varam aizmirst par otro DC. Un, draudzÄ«gā veidā, ja ievēro likumu, ka liels L2 ir ļauns, jo L2 ir tikai uz statÄ«vu, bet L3 ir starp statÄ«viem, un Ŕādai shēmai ir vēl vairāk ierobežojumu.
  • Kodā varat ierakstÄ«t DNS nosaukumu un atrisināt to, izmantojot /etc/hosts. PatiesÄ«bā rezolÅ«cijas nebÅ«s. Shēmas priekÅ”rocÄ«ba: nav ierobežojumu, kas raksturÄ«gi pirmajai metodei, tas ir, ir iespējams organizēt krustenisko lÄ«dzstrāvu. Bet tad rodas acÄ«mredzams jautājums: cik ātri mēs varam piegādāt izmaiņas uz /etc/hosts, izmantojot Puppet-Ansible?
  • Varat nedaudz mainÄ«t otro metodi: visos tÄ«mekļa serveros instalējiet keÅ”atmiņas DNS, caur kuru kods nonāks galvenajā datu bāzē. Å im DNS ierakstam varat iestatÄ«t TTL 60. Å Ä·iet, ka, pareizi Ä«stenojot, metode ir laba.
  • Shēma ar pakalpojumu atklāŔanu, kas nozÄ«mē, ka tiek izmantots konsuls utt.
  • Interesants variants ar ProxySQL. Visa trafika ir jānovirza uz MySQL, izmantojot ProxySQL; pati ProxySQL var noteikt, kurÅ” ir galvenais. Starp citu, par vienu no Ŕī produkta lietoÅ”anas iespējām varat izlasÄ«t manā raksts.

Orchestrator autors, strādājot Githubā, vispirms ieviesa pirmo shēmu ar VIP, un pēc tam pārveidoja to par shēmu ar konsulu.

Tipisks infrastruktūras izkārtojums:

Orchestrator for MySQL: kāpēc jūs nevarat izveidot defektu izturīgu projektu bez tā
Es nekavējoties aprakstÄ«Å”u acÄ«mredzamās situācijas, kas jāņem vērā:

  • VIP adrese nedrÄ«kst bÅ«t reÄ£istrēta neviena servera konfigurācijā. Iedomāsimies situāciju: kapteinis pārstartēja, un, kamēr tas tika ielādēts, Orchestrator pārgāja kļūmjpārlēces režīmā un padarÄ«ja vienu no vergiem par meistaru; tad vecmeistars piecēlās, un tagad VIP ir uz divām maŔīnām. Tas ir slikti.
  • OrÄ·estratoram jums bÅ«s jāuzraksta skripts, lai izsauktu veco meistaru un jauno meistaru. Uz vecā meistara jāskrien ifdown, bet uz jaunā meistara ā€“ ifup vip. BÅ«tu jauki Å”ajā skriptā iekļaut arÄ« to, ka kļūmjpārlēces gadÄ«jumā vecā galvenā slēdža ports tiek vienkārÅ”i izslēgts, lai izvairÄ«tos no smadzeņu sadalÄ«Å”anas.
  • Pēc tam, kad Orchestrator ir izsaucis jÅ«su skriptu, lai vispirms noņemtu VIP un/vai dzēstu slēdža portu, un pēc tam izsaucis VIP paaugstināŔanas skriptu jaunajam galvenajam, neaizmirstiet izmantot komandu arping, lai paziņotu visiem, ka jaunais VIP tagad ir Å”eit.
  • Visiem pakārtotajiem elementiem ir jābÅ«t tikai read_only=1, un, tiklÄ«dz jÅ«s paaugstināsit vergu par galveno, tam vajadzētu bÅ«t tikai read_only=0.
  • Neaizmirstiet, ka ikviens vergs, kuru esam izvēlējuÅ”ies Å”im mērÄ·im, var kļūt par kungu (OrÄ·estram ir viss izvēles mehānisms, kuru vergu uzskatÄ«t par jauna kunga kandidātu vispirms, kuru, otrkārt, un kuru vergu vajadzētu uzskatÄ«t nekādā gadÄ«jumā nedrÄ«kst izvēlēties meistaru). Ja vergs kļūst par saimnieku, tad verga slodze uz tā paliks un saimnieka slodze tiks pieskaitÄ«ta, tas ir jāņem vērā.

Kāpēc jums ir nepiecieÅ”ams Orchestrator, ja jums tāda nav?

  • Orchestrator ir ļoti lietotājam draudzÄ«gs grafiskais interfeiss, kas parāda visu topoloÄ£iju (skatiet ekrānuzņēmumu zemāk).
  • Orchestrator var izsekot, kuri vergi atpaliek un kur replikācija parasti ir sabojājusies (mums ir Orchestrator pievienoti skripti SMS sÅ«tÄ«Å”anai).
  • Orchestrator norāda, kuriem vergiem ir GTID kļūda.

OrÄ·estra interfeiss:

Orchestrator for MySQL: kāpēc jūs nevarat izveidot defektu izturīgu projektu bez tā
Kas ir GTID kļūdains?

Orķestra darbam ir divas galvenās prasības:

  • Ir nepiecieÅ”ams, lai pseido GTID bÅ«tu iespējots visās MySQL klastera maŔīnās; mums ir iespējots GTID.
  • Ir nepiecieÅ”ams, lai visur bÅ«tu viena veida binlogi, varat izmantot paziņojumu. Mums bija konfigurācija, kurā galvenajam un lielākajai daļai vergu bija Row, un divi vēsturiski palika jauktā režīmā. Rezultātā Orchestrator vienkārÅ”i nevēlējās savienot Å”os vergus ar jauno meistaru.

Atcerieties, ka ražoÅ”anas vergā vissvarÄ«gākais ir tā atbilstÄ«ba saimniekam! Ja gan galvenajā, gan pakārtotajā ierÄ«cē ir iespējots Global Transaction ID (GTID), varat izmantot funkciju gtid_subset, lai noskaidrotu, vai Å”ajās iekārtās ir izpildÄ«ti tie paÅ”i datu izmaiņu pieprasÄ«jumi. JÅ«s varat lasÄ«t vairāk par Å”o Å”eit.

Tādējādi Orchestrator, izmantojot GTID kļūdu, parāda, ka ar pakārtoto ierīci ir transakcijas, kuras nav galvenajā ierīcē. Kāpēc tas notiek?

  • Slavejā nav iespējots Read_only=1, kāds izveidoja savienojumu un pabeidza datu maiņas pieprasÄ«jumu.
  • Uz vergu nav iespējots Super_read_only=1, tad admins, sajaucis serveri, iegāja un tur izpildÄ«ja pieprasÄ«jumu.
  • Ja ņēmāt vērā abus iepriekŔējos punktus, tad ir vēl viens triks: MySQL binlogu izskaloÅ”anas pieprasÄ«jums nonāk arÄ« binlogā, tāpēc pirmajā skaloÅ”anas reizē uz galvenā un visiem vergu parādÄ«sies GTID kļūda. Kā no tā izvairÄ«ties? Perona-5.7.25-28 ieviesa iestatÄ«jumu binlog_skip_flush_commands=1, kas aizliedz rakstÄ«t viļņus binlogos. Vietnē mysql.com ir izveidota tāda kļūda.

Ä»aujiet man apkopot visu iepriekÅ” minēto. Ja vēl nevēlaties izmantot Orchestrator kļūmjpārlēces režīmā, ievietojiet to novēroÅ”anas režīmā. Tad jÅ«su acu priekŔā vienmēr bÅ«s MySQL maŔīnu mijiedarbÄ«bas karte un vizuāla informācija par to, kāda veida replikācija ir katrā maŔīnā, vai vergi atpaliek un galvenais, cik tie ir saskaņoti ar galveno!

AcÄ«mredzamais jautājums ir: "Kā Orchestrator vajadzētu strādāt?" Viņam ir jāatlasa jauns galvenais no esoÅ”ajiem pakārtotajiem un pēc tam atkal jāsavieno ar to visi vergi (Å”im nolÅ«kam ir nepiecieÅ”ams GTID; ja izmantojat veco mehānismu ar binlog_name un binlog_pos, tad pārslēdziet vergu no paÅ”reizējā galvenā uz jaunu tas ir vienkārÅ”i neiespējami!). Pirms mums bija Orchestrator, man reiz tas viss bija jādara manuāli. Vecais meistars karājās bagija Adaptec kontroliera dēļ, tajā bija apmēram 10 vergi. Man vajadzēja pārsÅ«tÄ«t VIP no galvenā uz vienu no vergu un no jauna savienot visus pārējos vergus. Cik konsoles man bija jāatver, cik vienlaicÄ«gu komandu man bija jāievada... Man bija jāgaida lÄ«dz 3 naktÄ«, jānoņem slodze no visiem vergiem, izņemot divus, jāuztaisa pirmā maŔīna no diviem galvenajiem, nekavējoties jāpievieno otra maŔīna pie tā, tāpēc piestipriniet visus pārējos vergus jaunajam saimniekam un atdodiet kravu. Kopumā Å”ausmÄ«gi...

Kā Orchestrator darbojas, kad tas pāriet kļūmjpārlēces režīmā? To visvieglāk ilustrē piemērs situācijai, kad mēs vēlamies meistaru padarÄ«t par jaudÄ«gāku, modernāku maŔīnu nekā Å”obrÄ«d.

Orchestrator for MySQL: kāpēc jūs nevarat izveidot defektu izturīgu projektu bez tā
Attēlā parādÄ«ts procesa vidus. Kas lÄ«dz Å”im jau ir izdarÄ«ts? Mēs teicām, ka vēlamies kādu vergu padarÄ«t par jauno saimnieku, Orchestrator sāka vienkārÅ”i savienot visus citus vergus ar to, jaunajam kapteinim darbojoties kā tranzÄ«ta maŔīnai. Ar Å”o shēmu kļūdas nerodas, strādā visi vergi, Orchestrator noņem VIP no vecā meistara, pārsÅ«ta uz jauno, padara read_only=0 un aizmirst par veco meistaru. Visi! MÅ«su pakalpojuma dÄ«kstāve ir VIP pārsÅ«tÄ«Å”anas laiks, kas ir 2-3 sekundes.

Tas arÄ« viss Å”odienai, paldies visiem. DrÄ«zumā bÅ«s otrs raksts par Orchestrator. Slavenajā padomju filmā ā€œGarāžaā€ viens varonis teica: ā€œEs ar viņu nedotos izlÅ«kos!ā€ Tātad, orÄ·estra kungs, es dotos ar jums izlÅ«koÅ”anā!

Avots: www.habr.com

Pievieno komentāru