Citymobil వద్ద మేము MySQL డేటాబేస్‌ని మా ప్రధాన నిరంతర డేటా నిల్వగా ఉపయోగిస్తాము. మేము వివిధ సేవలు మరియు ప్రయోజనాల కోసం అనేక డేటాబేస్ క్లస్టర్‌లను కలిగి ఉన్నాము.

మాస్టర్ యొక్క స్థిరమైన లభ్యత మొత్తం వ్యవస్థ మరియు దాని వ్యక్తిగత భాగాల పనితీరు యొక్క క్లిష్టమైన సూచిక. మాస్టర్ వైఫల్యం సంభవించినప్పుడు ఆటోమేటిక్ క్లస్టర్ రికవరీ సంఘటన ప్రతిస్పందన సమయాన్ని మరియు సిస్టమ్ పనికిరాని సమయాన్ని బాగా తగ్గిస్తుంది. ఈ వ్యాసంలో, నేను MySQL క్లస్టర్ కోసం అధిక లభ్యత (HA) డిజైన్‌ను పరిశీలిస్తాను MySQL ఆర్కెస్ట్రేటర్ మరియు వర్చువల్ IP చిరునామాలు (VIP).

VIP ఆధారంగా HA పరిష్కారం

ముందుగా, మా డేటా స్టోరేజ్ సిస్టమ్ ఏమిటో నేను మీకు క్లుప్తంగా చెబుతాను.

మేము ఒక వ్రాత-ప్రాప్యత మాస్టర్ మరియు బహుళ చదవడానికి-మాత్రమే ప్రతిరూపాలతో క్లాసిక్ రెప్లికేషన్ స్కీమ్‌ని ఉపయోగిస్తాము. ఒక క్లస్టర్ ఇంటర్మీడియట్ మాస్టర్‌ను కలిగి ఉంటుంది - ఇది ఇతరులకు ప్రతిరూపం మరియు మాస్టర్ రెండూ. క్లయింట్లు HAProxy ద్వారా ప్రతిరూపాలను యాక్సెస్ చేస్తారు, ఇది లోడ్ పంపిణీని మరియు సులభమైన స్కేలింగ్‌ను కూడా అనుమతిస్తుంది. HAProxy యొక్క ఉపయోగం చారిత్రక కారణాల వల్ల, మరియు మేము ప్రస్తుతం ProxySQLకి మారే ప్రక్రియలో ఉన్నాము.

రెప్లికేషన్ ఆధారంగా సెమీ-సింక్రోనస్ మోడ్‌లో నిర్వహిస్తారు GTID. దీనర్థం, లావాదేవీని విజయవంతంగా పరిగణించే ముందు కనీసం ఒక ప్రతిరూపమైనా తప్పనిసరిగా లాగిన్ చేయాలి. ఈ రెప్లికేషన్ మోడ్ మాస్టర్ నోడ్ వైఫల్యం సంభవించినప్పుడు పనితీరు మరియు డేటా భద్రత మధ్య సరైన సమతుల్యతను అందిస్తుంది. ప్రాథమికంగా అన్ని మార్పులు మాస్టర్ నుండి ప్రతిరూపాలను ఉపయోగించి బదిలీ చేయబడతాయి Row Based Replication (RBR), కానీ కొన్ని నోడ్స్ కలిగి ఉండవచ్చు mixed binlog format.

ఆర్కెస్ట్రేటర్ క్రమానుగతంగా క్లస్టర్ టోపోలాజీ స్థితిని నవీకరిస్తుంది, అందుకున్న సమాచారాన్ని విశ్లేషిస్తుంది మరియు సమస్యలు తలెత్తితే, అది ఆటోమేటిక్ రికవరీ విధానాన్ని ప్రారంభించవచ్చు. డెవలపర్ ఈ ప్రక్రియకు బాధ్యత వహిస్తారు, ఎందుకంటే ఇది వివిధ మార్గాల్లో అమలు చేయబడుతుంది: VIP, DNS ఆధారంగా, సర్వీస్ డిస్కవరీ సేవలు లేదా స్వీయ-వ్రాతపూర్వక విధానాలను ఉపయోగించడం.

మాస్టర్ విఫలమైతే దాన్ని పునరుద్ధరించడానికి ఒక సులభమైన మార్గం ఫ్లోటింగ్ VIP చిరునామాలను ఉపయోగించడం.

మీరు ముందుకు వెళ్లడానికి ముందు ఈ పరిష్కారం గురించి తెలుసుకోవలసినది:

• VIP అనేది నిర్దిష్ట భౌతిక నెట్‌వర్క్ ఇంటర్‌ఫేస్‌తో అనుబంధించబడని IP చిరునామా. నోడ్ విఫలమైతే లేదా షెడ్యూల్ చేయబడిన నిర్వహణ సమయంలో, మేము తక్కువ సమయ వ్యవధితో VIPని మరొక వనరుకి మార్చవచ్చు.
• వర్చువల్ IP చిరునామాను ఖాళీ చేయడం మరియు జారీ చేయడం చౌకైన మరియు వేగవంతమైన ఆపరేషన్.
• VIPతో పని చేయడానికి, మీకు SSH ద్వారా సర్వర్‌కు యాక్సెస్ లేదా ప్రత్యేక యుటిలిటీలను ఉపయోగించడం అవసరం, ఉదాహరణకు, keepalived.

మా విజర్డ్‌తో సాధ్యమయ్యే సమస్యలను చూద్దాం మరియు ఆటోమేటిక్ రికవరీ మెకానిజం ఎలా పని చేయాలో ఊహించండి.

మాస్టర్‌కు నెట్‌వర్క్ కనెక్టివిటీ అదృశ్యమైంది లేదా హార్డ్‌వేర్ స్థాయిలో సమస్య తలెత్తింది మరియు సర్వర్ అందుబాటులో లేదు

1. ఆర్కెస్ట్రేటర్ క్లస్టర్ టోపోలాజీని అప్‌డేట్ చేస్తుంది, ప్రతి ప్రతిరూపం మాస్టర్ అందుబాటులో లేదని నివేదిస్తుంది. ఆర్కెస్ట్రేటర్ కొత్త మాస్టర్ పాత్రకు తగిన ప్రతిరూపాన్ని ఎంచుకునే ప్రక్రియను ప్రారంభిస్తాడు మరియు రికవరీని ప్రారంభిస్తాడు.
2. మేము పాత మాస్టర్ నుండి VIPని తొలగించడానికి ప్రయత్నిస్తున్నాము - విజయవంతం కాలేదు.
3. ప్రతిరూపం మాస్టర్ పాత్రకు మారుతుంది. టోపోలాజీ పునర్నిర్మించబడుతోంది.
4. VIPతో కొత్త నెట్‌వర్క్ ఇంటర్‌ఫేస్‌ని జోడిస్తోంది. VIPని తీసివేయడం సాధ్యం కానందున, మేము క్రమానుగతంగా నేపథ్యంలో అభ్యర్థనను పంపడం ప్రారంభిస్తాము అవాంఛనీయ ARP. ఈ రకమైన అభ్యర్థన/ప్రతిస్పందన కనెక్ట్ చేయబడిన స్విచ్‌లలో IP మరియు MAC చిరునామా మ్యాపింగ్ పట్టికను నవీకరించడానికి మిమ్మల్ని అనుమతిస్తుంది, తద్వారా మా VIP తరలించబడిందని మీకు తెలియజేస్తుంది. ఇది సంభావ్యతను తగ్గిస్తుంది split brain పాత మాస్టర్‌ను తిరిగి ఇచ్చే సమయంలో.
5. అన్ని కొత్త కనెక్షన్‌లు వెంటనే కొత్త మాస్టర్‌కి మళ్లించబడతాయి. పాత కనెక్షన్‌లు విఫలమవుతాయి మరియు అప్లికేషన్ స్థాయిలో డేటాబేస్‌కు పదేపదే కాల్‌లు చేయబడతాయి.

సర్వర్ సాధారణ మోడ్‌లో పనిచేస్తోంది, DBMS స్థాయిలో వైఫల్యం సంభవించింది

అల్గోరిథం మునుపటి కేసు మాదిరిగానే ఉంటుంది: టోపోలాజీని నవీకరించడం మరియు రికవరీ ప్రక్రియను ప్రారంభించడం. సర్వర్ అందుబాటులో ఉన్నందున, మేము పాత మాస్టర్‌లో VIPని విజయవంతంగా విడుదల చేస్తాము, దాన్ని కొత్తదానికి బదిలీ చేస్తాము మరియు అనేక ARP అభ్యర్థనలను పంపుతాము. పాత మాస్టర్ యొక్క సాధ్యమైన రాబడి పునర్నిర్మించిన క్లస్టర్ మరియు అప్లికేషన్ యొక్క ఆపరేషన్‌ను ప్రభావితం చేయకూడదు.

ఇతర సమస్యలు

ప్రతిరూపాలు లేదా ఇంటర్మీడియట్ మాస్టర్స్ వైఫల్యం దారితీయదు స్వయంచాలక చర్యలకు మరియు మాన్యువల్ జోక్యం అవసరం.

వర్చువల్ నెట్‌వర్క్ ఇంటర్‌ఫేస్ ఎల్లప్పుడూ తాత్కాలికంగా జోడించబడుతుంది, అనగా సర్వర్ రీబూట్ చేసిన తర్వాత, VIP స్వయంచాలకంగా కేటాయించబడదు. ప్రతి డేటాబేస్ ఉదాహరణ డిఫాల్ట్‌గా చదవడానికి-మాత్రమే మోడ్‌లో ప్రారంభమవుతుంది, ఆర్కెస్ట్రేటర్ స్వయంచాలకంగా కొత్త మాస్టర్‌ను వ్రాయడానికి మారుస్తుంది మరియు ఇన్‌స్టాల్ చేయడానికి ప్రయత్నిస్తుంది read only పాత మాస్టర్ మీద. ఈ చర్యలు సంభావ్యతను తగ్గించే లక్ష్యంతో ఉన్నాయి split brain.

రికవరీ ప్రక్రియలో సమస్యలు తలెత్తవచ్చు, వీటిని ప్రామాణిక పర్యవేక్షణ సాధనాలతో పాటు ఆర్కెస్ట్రేటర్ UI ద్వారా కూడా తెలియజేయాలి. మేము ఈ లక్షణాన్ని జోడించడం ద్వారా REST APIని విస్తరించాము (PR ప్రస్తుతం సమీక్షలో ఉంది).

HA పరిష్కారం యొక్క సాధారణ రేఖాచిత్రం క్రింద ప్రదర్శించబడింది.

కొత్త మాస్టర్‌ను ఎంచుకోవడం

ఆర్కెస్ట్రేటర్ తగినంత తెలివైనవాడు మరియు ఎంచుకోవడానికి ప్రయత్నిస్తాడు అత్యంత అనుకూలమైన ప్రతిరూపం కింది ప్రమాణాల ప్రకారం కొత్త మాస్టర్‌గా:

• ప్రతిరూపం మాస్టర్ కంటే వెనుకబడి ఉంటుంది;
• మాస్టర్ మరియు ప్రతిరూపం యొక్క MySQL వెర్షన్;
• ప్రతిరూపణ రకం (RBR, SBR లేదా మిశ్రమ);
• ఒకే లేదా విభిన్న డేటా కేంద్రాలలో స్థానం;
• లభ్యత errant GTID - ప్రతిరూపంలో అమలు చేయబడిన మరియు మాస్టర్‌పై లేని లావాదేవీలు;
• కస్టమ్ ఎంపిక నియమాలు కూడా పరిగణనలోకి తీసుకోబడతాయి.

ప్రతి క్యూ మాస్టర్‌కు అనువైన అభ్యర్థి కాదు. ఉదాహరణకు, డేటాను బ్యాకప్ చేయడానికి ప్రతిరూపాన్ని ఉపయోగించవచ్చు లేదా సర్వర్ బలహీనమైన హార్డ్‌వేర్ కాన్ఫిగరేషన్‌ను కలిగి ఉంటుంది. ఆర్కెస్ట్రేటర్ మద్దతు ఇస్తుంది మాన్యువల్ నియమాలతో మీరు మీ అభ్యర్థి ఎంపిక ప్రాధాన్యతలను అత్యంత ప్రాధాన్యత నుండి విస్మరించవచ్చు.

ప్రతిస్పందన మరియు రికవరీ సమయం

ఏదైనా సంఘటన జరిగినప్పుడు, సిస్టమ్ పనికిరాని సమయాన్ని తగ్గించడం చాలా ముఖ్యం, కాబట్టి ఆర్కెస్ట్రేటర్ ద్వారా క్లస్టర్ టోపోలాజీని సృష్టించడం మరియు నవీకరించడంపై ప్రభావం చూపే MySQL పారామితులను పరిశీలిద్దాం:

• slave_net_timeout - కనెక్షన్ పోయినట్లు మరియు మళ్లీ కనెక్ట్ అయినట్లు గుర్తించబడటానికి ముందు మాస్టర్ నుండి కొత్త డేటా లేదా హార్ట్‌బీట్ సిగ్నల్ రావడానికి ప్రతిరూపం వేచి ఉండే సెకన్ల సంఖ్య. తక్కువ విలువ, మాస్టర్‌తో కమ్యూనికేషన్ విచ్ఛిన్నమైందని ప్రతిరూపం వేగంగా నిర్ధారిస్తుంది. మేము ఈ విలువను 5 సెకన్లకు సెట్ చేసాము.
• MASTER_CONNECT_RETRY - మళ్లీ కనెక్షన్ ప్రయత్నాల మధ్య సెకన్ల సంఖ్య. నెట్‌వర్క్ సమస్యల సందర్భంలో, ఈ పరామితి యొక్క తక్కువ విలువ త్వరిత రీకనెక్షన్‌ని అనుమతిస్తుంది మరియు క్లస్టర్ రికవరీ ప్రక్రియ ప్రారంభం నుండి నిరోధిస్తుంది. సిఫార్సు చేయబడిన విలువ 1 సెకను.
• MASTER_RETRY_COUNT - గరిష్ట సంఖ్యలో మళ్లీ కనెక్షన్ ప్రయత్నాలు.
• MASTER_HEARTBEAT_PERIOD — మాస్టర్ హార్ట్ బీట్ సిగ్నల్ పంపిన సెకన్లలో విరామం. డిఫాల్ట్ విలువలో సగం slave_net_timeout.

ఆర్కెస్ట్రేటర్ ఎంపికలు:

• DelayMasterPromotionIfSQLThreadNotUpToDate - సమానంగా ఉంటే true, ఆపై ప్రతిరూపం యొక్క SQL థ్రెడ్ రిలే లాగ్ నుండి వర్తించని అన్ని లావాదేవీలను పూర్తి చేసే వరకు అభ్యర్థి ప్రతిరూపంపై ప్రధాన పాత్ర వర్తించదు. అన్ని అభ్యర్థుల ప్రతిరూపాలు వెనుకబడినప్పుడు లావాదేవీలను కోల్పోకుండా ఉండటానికి మేము ఈ ఎంపికను ఉపయోగిస్తాము.
• InstancePollSeconds - టోపోలాజీని నిర్మించడం మరియు నవీకరించడం యొక్క ఫ్రీక్వెన్సీ.
• RecoveryPollSeconds - టోపోలాజీ విశ్లేషణ యొక్క ఫ్రీక్వెన్సీ. సమస్య గుర్తించబడితే, టోపోలాజీ రికవరీ ప్రారంభించబడుతుంది. ఈ స్థిరమైన, 1 సెకనుకు సమానం.

ప్రతి క్లస్టర్ నోడ్‌కు ఒకసారి ఆర్కెస్ట్రేటర్ ద్వారా పోల్ చేయబడుతుంది InstancePollSeconds సెకన్లు సమస్య గుర్తించబడినప్పుడు, క్లస్టర్ స్థితి బలవంతంగా ఉంటుంది నవీకరించబడింది, ఆపై రికవరీ చేయడానికి తుది నిర్ణయం తీసుకోబడుతుంది. విభిన్న డేటాబేస్ మరియు ఆర్కెస్ట్రేటర్ పారామితులతో ప్రయోగాలు చేయడం ద్వారా, మేము ప్రతిస్పందన మరియు పునరుద్ధరణ సమయాన్ని 30 సెకన్లకు తగ్గించగలిగాము.

పరీక్షా బల్ల

మేము స్థానికుని అభివృద్ధితో HA పథకాన్ని పరీక్షించడం ప్రారంభించాము పరీక్షా బల్ల మరియు పరీక్ష మరియు ఉత్పత్తి పరిసరాలలో మరింత అమలు. స్థానిక స్టాండ్ డాకర్ ఆధారంగా పూర్తిగా ఆటోమేటెడ్ మరియు ఆర్కెస్ట్రాటర్ మరియు నెట్‌వర్క్ యొక్క కాన్ఫిగరేషన్‌తో ప్రయోగాలు చేయడానికి, క్లస్టర్‌ను 2-3 సర్వర్‌ల నుండి అనేక డజన్ల వరకు స్కేల్ చేయడానికి మరియు సురక్షితమైన వాతావరణంలో వ్యాయామాలను నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది.

వ్యాయామాల సమయంలో, మేము సమస్య ఎమ్యులేషన్ పద్ధతుల్లో ఒకదాన్ని ఎంచుకుంటాము: ఉపయోగించి మాస్టర్‌ను తక్షణమే షూట్ చేయండి kill -9, ప్రక్రియను మెత్తగా ముగించి, సర్వర్‌ని ఆపివేయండి (docker-compose stop), ఉపయోగించి నెట్‌వర్క్ సమస్యలను అనుకరించండి iptables -j REJECT లేదా iptables -j DROP. మేము ఈ క్రింది ఫలితాలను ఆశిస్తున్నాము:

• ఆర్కెస్ట్రేటర్ మాస్టర్‌తో సమస్యలను గుర్తించి, టోపోలాజీని 10 సెకన్లలోపు నవీకరిస్తారు;
• రికవరీ విధానం స్వయంచాలకంగా ప్రారంభమవుతుంది: నెట్‌వర్క్ కాన్ఫిగరేషన్ మారుతుంది, మాస్టర్ పాత్ర ప్రతిరూపానికి వెళుతుంది, టోపోలాజీ పునర్నిర్మించబడుతుంది;
• కొత్త మాస్టర్ వ్రాయదగినదిగా మారుతుంది, పునర్నిర్మాణ ప్రక్రియలో ప్రత్యక్ష ప్రతిరూపాలు కోల్పోవు;
• డేటా కొత్త మాస్టర్‌కు వ్రాయడం మరియు ప్రతిరూపం చేయడం ప్రారంభమవుతుంది;
• మొత్తం రికవరీ సమయం 30 సెకన్ల కంటే ఎక్కువ ఉండదు.

మీకు తెలిసినట్లుగా, విభిన్న హార్డ్‌వేర్ మరియు నెట్‌వర్క్ కాన్ఫిగరేషన్‌లు, సింథటిక్ మరియు రియల్ లోడ్‌లో తేడాలు మొదలైన వాటి కారణంగా సిస్టమ్ టెస్ట్ మరియు ప్రొడక్షన్ పరిసరాలలో భిన్నంగా ప్రవర్తించవచ్చు. అందువల్ల, నెట్‌వర్క్ కనెక్టివిటీ కోల్పోయినప్పుడు లేదా దాని వ్యక్తిగత భాగాలు క్షీణించినప్పుడు సిస్టమ్ ఎలా ప్రవర్తిస్తుందో తనిఖీ చేస్తూ, వాస్తవ పరిస్థితులలో మేము కాలానుగుణంగా వ్యాయామాలు చేస్తాము. భవిష్యత్తులో, మేము రెండు పర్యావరణాల కోసం పూర్తిగా ఒకే విధమైన మౌలిక సదుపాయాలను నిర్మించాలనుకుంటున్నాము మరియు దాని పరీక్షను ఆటోమేట్ చేయాలనుకుంటున్నాము.

కనుగొన్న

ప్రధాన నిల్వ వ్యవస్థ నోడ్ యొక్క ఆరోగ్యం SRE మరియు కార్యకలాపాల బృందం యొక్క ప్రధాన విధుల్లో ఒకటి. VIP ఆధారంగా ఆర్కెస్ట్రేటర్ మరియు HA పరిష్కారం యొక్క అమలు క్రింది ఫలితాలను సాధించడానికి మాకు అనుమతి ఇచ్చింది:

• డేటాబేస్ క్లస్టర్ యొక్క టోపోలాజీతో సమస్యలను విశ్వసనీయంగా గుర్తించడం;
• మాస్టర్-సంబంధిత సంఘటనలకు ఆటోమేటిక్ మరియు వేగవంతమైన ప్రతిస్పందన, సిస్టమ్ పనికిరాని సమయాన్ని తగ్గిస్తుంది.

అయితే, పరిష్కారం దాని పరిమితులు మరియు నష్టాలను కలిగి ఉంది:

• HA స్కీమ్‌ను అనేక డేటా సెంటర్‌లకు స్కేలింగ్ చేయడానికి వాటి మధ్య ఒకే L2 నెట్‌వర్క్ అవసరం;
• కొత్త మాస్టర్‌పై VIPని కేటాయించే ముందు, మేము దానిని పాతదానిపై విడుదల చేయాలి. ప్రక్రియ క్రమంగా ఉంటుంది, ఇది రికవరీ సమయాన్ని పెంచుతుంది;
• VIPని విడుదల చేయడానికి సర్వర్‌కు SSH యాక్సెస్ లేదా రిమోట్ విధానాలకు కాల్ చేసే ఏదైనా ఇతర పద్ధతి అవసరం. రికవరీ ప్రక్రియకు కారణమైన సమస్యలను సర్వర్ లేదా డేటాబేస్ ఎదుర్కొంటున్నందున, VIP తొలగింపు విజయవంతంగా పూర్తవుతుందని మేము ఖచ్చితంగా చెప్పలేము. మరియు ఇది ఒకే వర్చువల్ IP చిరునామా మరియు సమస్యతో రెండు సర్వర్ల రూపానికి దారి తీస్తుంది split brain.

తప్పించుకొవడానికి split brain, మీరు పద్ధతిని ఉపయోగించవచ్చు స్టోనిత్ ("షూట్ ది అదర్ నోడ్ ఇన్ ది హెడ్"), ఇది సమస్య నోడ్‌ను పూర్తిగా వేరు చేస్తుంది లేదా నిలిపివేస్తుంది. క్లస్టర్ అధిక లభ్యతను అమలు చేయడానికి ఇతర మార్గాలు ఉన్నాయి: VIP మరియు DNS కలయిక, సర్వీస్ డిస్కవరీ మరియు ప్రాక్సీ సేవలు, సింక్రోనస్ రెప్లికేషన్ మరియు వాటి స్వంత ప్రతికూలతలు మరియు ప్రయోజనాలను కలిగి ఉన్న ఇతర పద్ధతులు.

నేను MySQL ఫెయిల్‌ఓవర్ క్లస్టర్‌ని సృష్టించే మా విధానం గురించి మాట్లాడాను. ఇది అమలు చేయడం సులభం మరియు ప్రస్తుత పరిస్థితుల్లో విశ్వసనీయత యొక్క ఆమోదయోగ్యమైన స్థాయిని అందిస్తుంది. మొత్తం వ్యవస్థ సాధారణంగా మరియు ముఖ్యంగా మౌలిక సదుపాయాలు అభివృద్ధి చెందుతున్నప్పుడు, ఈ విధానం నిస్సందేహంగా అభివృద్ధి చెందుతుంది.

మూలం: www.habr.com