Orchestrator ug VIP isip solusyon sa HA alang sa MySQL cluster

Sa Citymobil naggamit kami og MySQL database isip among nag-unang padayon nga pagtipig sa datos. Adunay kami daghang mga cluster sa database alang sa lainlaing mga serbisyo ug katuyoan.

Ang kanunay nga pagkaanaa sa agalon usa ka kritikal nga timailhan sa pasundayag sa tibuuk nga sistema ug ang mga indibidwal nga bahin niini. Ang awtomatikong pag-ayo sa cluster kung adunay usa ka master nga kapakyasan labi nga nagpamenos sa oras sa pagtubag sa insidente ug downtime sa sistema. Niini nga artikulo, akong tan-awon ang usa ka taas nga magamit (HA) nga disenyo alang sa usa ka MySQL cluster nga gibase sa MySQL Orchestrator ug mga virtual IP address (VIP).

Orchestrator ug VIP isip solusyon sa HA alang sa MySQL cluster

HA solusyon base sa VIP

Una, isulti ko kanimo kung unsa ang among sistema sa pagtipig sa datos.

Gigamit namo ang usa ka classic replication scheme nga adunay usa ka write-accessible master ug multiple read-only replicas. Ang usa ka cluster mahimong adunay usa ka intermediate master - usa ka node nga usa ka replika ug usa ka master alang sa uban. Ang mga kliyente nag-access sa mga replika pinaagi sa HAProxy, nga nagtugot alang sa bisan pag-apod-apod sa load ug dali nga pag-scale. Ang paggamit sa HAProxy tungod sa mga hinungdan sa kasaysayan, ug kami karon anaa sa proseso sa paglalin sa ProxySQL.

Ang pagkopya gihimo sa semi-synchronous mode base sa GTID. Kini nagpasabot nga labing menos usa ka replika ang kinahanglang mag-log sa usa ka transaksyon sa dili pa kini makonsiderar nga malampuson. Kini nga mode sa pagkopya naghatag usa ka kamalaumon nga balanse tali sa pasundayag ug kaluwasan sa datos kung adunay pagkapakyas sa master node. Sa panguna ang tanan nga mga pagbag-o gibalhin gikan sa agalon ngadto sa mga replika nga gigamit Row Based Replication (RBR), apan ang pipila ka mga node mahimong adunay mixed binlog format.

Ang orkestra matag karon ug unya nag-update sa kahimtang sa cluster topology, nag-analisar sa impormasyon nga nadawat, ug kung adunay mga problema, mahimo kini nga maglunsad og usa ka awtomatikong pamaagi sa pagbawi. Ang developer ang responsable sa pamaagi mismo, tungod kay mahimo kini ipatuman sa lainlaing mga paagi: base sa VIP, DNS, gamit ang mga serbisyo sa pagdiskobre sa serbisyo o mga mekanismo nga gisulat sa kaugalingon.

Usa ka yano nga paagi aron mapasig-uli ang usa ka agalon kung kini mapakyas mao ang paggamit sa naglutaw nga mga adres sa VIP.

Unsa ang kinahanglan nimong masayran bahin sa kini nga solusyon sa dili pa magpadayon:

  • Ang usa ka VIP usa ka IP address nga wala kauban sa usa ka piho nga interface sa pisikal nga network. Kung ang usa ka node mapakyas o sa panahon sa gikatakda nga pagmentinar, mahimo natong ibalhin ang VIP ngadto sa laing kapanguhaan nga adunay gamay nga downtime.
  • Ang pagpalingkawas ug pag-isyu sa usa ka virtual IP address usa ka barato ug paspas nga operasyon.
  • Aron magtrabaho kauban ang VIP, kinahanglan nimo ang pag-access sa server pinaagi sa SSH, o ang paggamit sa mga espesyal nga kagamitan, pananglitan, keepalived.

Atong tan-awon ang posible nga mga problema sa among wizard ug hunahunaa kung giunsa ang mekanismo sa awtomatikong pagbawi.

Ang koneksyon sa network sa agalon nawala, o adunay problema nga mitungha sa lebel sa hardware, ug ang server dili magamit

  1. Gi-update sa orkestra ang topology sa cluster, ang matag replika nagreport nga dili magamit ang master. Gisugdan sa orkestra ang proseso sa pagpili sa usa ka replika nga angay alang sa papel sa bag-ong agalon ug nagsugod sa pagkaayo.
  2. Gisulayan namon nga tangtangon ang VIP gikan sa tigulang nga agalon - nga wala’y kalampusan.
  3. Ang replika nagbalhin sa papel sa agalon. Gitukod pag-usab ang topology.
  4. Pagdugang usa ka bag-ong interface sa network nga adunay VIP. Tungod kay dili mahimo nga tangtangon ang VIP, magsugod kami kanunay nga magpadala usa ka hangyo sa background walay bayad nga ARP. Kini nga matang sa hangyo / tubag nagtugot kanimo sa pag-update sa IP ug MAC address mapping table sa konektado nga mga switch, sa ingon nagpahibalo kanimo nga ang among VIP mibalhin. Gipamenos niini ang posibilidad split brain sa pagbalik sa tigulang nga agalon.
  5. Ang tanan nga mga bag-ong koneksyon gi-redirect dayon sa bag-ong agalon. Ang mga daan nga koneksyon napakyas ug ang balikbalik nga mga tawag sa database gihimo sa lebel sa aplikasyon.

Ang server naglihok sa normal nga mode, usa ka kapakyasan ang nahitabo sa lebel sa DBMS

Ang algorithm susama sa miaging kaso: pag-update sa topology ug pagsugod sa proseso sa pagbawi. Tungod kay anaa ang server, malampuson namong buhian ang VIP sa daan nga agalon, ibalhin kini ngadto sa bag-o, ug ipadala ang daghang mga hangyo sa ARP. Ang posible nga pagbalik sa daan nga agalon kinahanglan dili makaapekto sa gitukod pag-usab nga cluster ug sa operasyon sa aplikasyon.

Ubang mga problema

Pagkapakyas sa mga replika o intermediate masters dili mangulo sa awtomatikong mga aksyon ug nanginahanglan manwal nga interbensyon.

Ang usa ka virtual nga interface sa network kanunay nga gidugang temporaryo, nga mao, pagkahuman sa pag-reboot sa server, ang VIP dili awtomatiko nga gi-assign. Ang matag database nga pananglitan magsugod sa read-only mode pinaagi sa default, ang orkestra awtomatik nga mobalhin sa bag-ong master aron magsulat ug mosulay sa pag-instalar read only sa tigulang nga agalon. Kini nga mga aksyon gitumong sa pagpakunhod sa posibilidad split brain.

Ang mga problema mahimong motumaw sa panahon sa proseso sa pagbawi, nga kinahanglan usab nga ipahibalo pinaagi sa orkestra UI dugang sa mga standard nga himan sa pag-monitor. Among gipalapdan ang REST API pinaagi sa pagdugang niini nga bahin (PR kasamtangan nga gisusi).

Ang kinatibuk-ang diagram sa solusyon sa HA gipresentar sa ubos.

Orchestrator ug VIP isip solusyon sa HA alang sa MySQL cluster

Pagpili og bag-ong agalon

Ang orkestra kay maalamon ug naningkamot sa pagpili ang labing angay nga replika isip bag-ong agalon sumala sa mosunod nga mga criteria:

  • ang replica naa sa luyo sa agalon;
  • MySQL nga bersyon sa master ug replika;
  • tipo sa pagkopya (RBR, SBR o sinagol);
  • lokasyon sa parehas o lainlaing mga sentro sa datos;
  • pagkabaton errant GTID - mga transaksyon nga gihimo sa replika ug wala sa agalon;
  • Gikonsiderar usab ang mga lagda sa pagpili sa kostumbre.

Dili tanan nga cue usa ka sulundon nga kandidato alang sa usa ka agalon. Pananglitan, ang usa ka kopya mahimong magamit sa pag-backup sa datos, o ang server adunay mas huyang nga configuration sa hardware. Orkestra nagsuporta manwal nga mga lagda diin mahimo nimong ipasibo ang imong mga gusto sa pagpili sa kandidato gikan sa labing gipalabi nga wala panumbalinga.

Panahon sa pagtubag ug pagkaayo

Sa panghitabo sa usa ka insidente, importante nga mamenosan ang sistema sa downtime, busa atong tagdon ang MySQL parameters nga makaapekto sa paghimo ug pag-update sa cluster topology sa orkestra:

  • slave_net_timeout — ang gidaghanon sa mga segundos diin ang replica naghulat alang sa bag-ong datos o usa ka signal sa tibok sa kasingkasing nga moabut gikan sa agalon sa wala pa mailhan ang koneksyon nga nawala ug nakonekta pag-usab. Kon mas ubos ang bili, mas paspas ang replica nga makatino nga ang komunikasyon sa agalon naguba. Gibutang namon kini nga kantidad sa 5 segundos.
  • MASTER_CONNECT_RETRY — gidaghanon sa mga segundo tali sa mga pagsulay sa pagkonektar pag-usab. Kung adunay mga problema sa network, ang usa ka gamay nga kantidad alang niini nga parameter magtugot sa dali nga pagkonekta pag-usab ug mapugngan ang proseso sa pagbawi sa cluster gikan sa pagsugod. Ang girekomenda nga kantidad mao ang 1 segundo.
  • MASTER_RETRY_COUNT — maximum nga gidaghanon sa mga pagsulay sa pagkonektar pag-usab.
  • MASTER_HEARTBEAT_PERIOD — agwat sa mga segundo pagkahuman ang agalon nagpadala usa ka signal sa pagpitik sa kasingkasing. Default sa katunga sa kantidad slave_net_timeout.

Mga Opsyon sa Orkestra:

  • DelayMasterPromotionIfSQLThreadNotUpToDate - kung parehas true, unya ang master nga papel dili magamit sa kandidato nga replika hangtod ang SQL thread sa replica makompleto ang tanan nga wala magamit nga mga transaksyon gikan sa Relay Log. Gigamit namon kini nga kapilian aron malikayan ang pagkawala sa mga transaksyon kung ang tanan nga mga replika sa kandidato nahulog.
  • InstancePollSeconds - frequency sa pagtukod ug pag-update sa topology.
  • RecoveryPollSeconds - frequency sa pagtuki sa topology. Kung ang usa ka problema nakit-an, ang pagbawi sa topology gisugdan. Kini makanunayon, katumbas sa 1 segundos.

Ang matag cluster node gisusi sa orkestra kausa matag usa InstancePollSeconds segundos Kung ang usa ka problema nakit-an, ang kahimtang sa cluster mapugos updated, ug dayon ang kataposang desisyon gihimo sa pagpahigayon sa pagkaayo. Pinaagi sa pag-eksperimento sa lain-laing database ug mga parameter sa orkestra, nakahimo kami sa pagpakunhod sa tubag ug oras sa pagbawi ngadto sa 30 segundos.

pagsulay stand

Among gisugdan ang pagsulay sa HA scheme uban sa pagpalambo sa usa ka lokal test bench ug dugang nga pagpatuman sa pagsulay ug mga palibot sa produksiyon. Ang lokal nga baruganan bug-os nga awtomatiko base sa Docker ug gitugotan ka nga mag-eksperimento sa pag-configure sa orkestra ug network, i-scale ang cluster gikan sa 2-3 server hangtod sa daghang dosena, ug magpahigayon mga ehersisyo sa luwas nga palibot.

Atol sa mga ehersisyo, gipili namo ang usa sa mga pamaagi sa pagsundog sa problema: pusil dayon ang agalon gamit kill -9, hinayhinay nga tapuson ang proseso ug ihunong ang server (docker-compose stop), i-simulate ang mga problema sa network gamit iptables -j REJECT o iptables -j DROP. Gipaabot namo ang mosunod nga mga resulta:

  • makit-an sa orkestra ang mga problema sa agalon ug i-update ang topology sa dili molapas sa 10 segundos;
  • ang pamaagi sa pagbawi awtomatikong magsugod: ang pag-configure sa network mausab, ang papel sa agalon ipasa sa replika, ang topology matukod pag-usab;
  • ang bag-ong agalon mahimong masulat, ang mga buhi nga replika dili mawala sa panahon sa proseso sa pagtukod pag-usab;
  • data magsugod sa pagsulat ngadto sa bag-ong agalon ug replicated;
  • Ang kinatibuk-ang oras sa pagbawi dili molapas sa 30 segundos.

Sama sa imong nahibal-an, ang sistema mahimo’g lahi ang pamatasan sa pagsulay ug mga palibot sa produksiyon tungod sa lainlaing mga pag-configure sa hardware ug network, mga kalainan sa sintetiko ug tinuud nga pagkarga, ug uban pa. Busa, matag karon ug unya nagpahigayon kami mga ehersisyo sa tinuud nga mga kahimtang, gisusi kung giunsa ang paglihok sa sistema kung nawala ang koneksyon sa network o ang mga indibidwal nga bahin niini nadaot. Sa umaabot, gusto namon nga magtukod usa ka hingpit nga parehas nga imprastraktura alang sa parehas nga mga palibot ug i-automate ang pagsulay niini.

kaplag

Ang kahimsog sa main storage system node usa sa mga nag-unang buluhaton sa SRE ug operations team. Ang pagpatuman sa orkestra ug HA nga solusyon base sa VIP nagtugot kanamo sa pagkab-ot sa mosunod nga mga resulta:

  • kasaligan nga pagkakita sa mga problema sa topology sa database cluster;
  • awtomatik ug paspas nga pagtubag sa mga insidente nga may kalabutan sa master, nga gipamenos ang downtime sa sistema.

Bisan pa, ang solusyon adunay mga limitasyon ug disbentaha:

  • Ang pag-scale sa HA scheme ngadto sa daghang mga data center magkinahanglan og usa ka L2 network tali kanila;
  • Sa dili pa i-assign ang VIP sa bag-ong agalon, kinahanglan naton nga buhian kini sa daan. Ang proseso sunud-sunod, nga nagdugang sa oras sa pagkaayo;
  • Ang pagpagawas sa VIP nanginahanglan ug SSH nga pag-access sa server, o bisan unsang paagi sa pagtawag sa layo nga mga pamaagi. Tungod kay ang server o database nakasinati og mga problema nga hinungdan sa proseso sa pagbawi, dili kami makasiguro nga ang pagtangtang sa VIP makompleto nga malampuson. Ug kini mahimong mosangpot sa pagpakita sa duha ka mga server nga adunay parehas nga virtual IP address ug usa ka problema split brain.

Aron malikayan split brain, mahimo nimong gamiton ang pamaagi STONITH (“Shoot The Other Node In The Head”), nga hingpit nga naglain o nagpugong sa problema nga node. Adunay ubang mga paagi sa pagpatuman sa cluster high availability: usa ka kombinasyon sa VIP ug DNS, service discovery ug proxy services, synchronous replication ug uban pang mga pamaagi nga adunay kaugalingong mga disbentaha ug mga bentaha.

Naghisgot ko bahin sa among pamaagi sa paghimo og MySQL failover cluster. Sayon nga ipatuman ug naghatag usa ka madawat nga lebel sa kasaligan sa ilawom sa karon nga mga kahimtang. Samtang nag-uswag ang tibuuk nga sistema ug labi na ang imprastraktura, kini nga pamaagi sa walay duhaduha molambo.

Source: www.habr.com

Idugang sa usa ka comment