పరిచయం

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

ఈ నిర్ణయం సహేతుకమైన ప్రశ్నను లేవనెత్తింది: ఫెయిల్‌ఓవర్ క్లస్టర్ ఎంతవరకు తప్పును తట్టుకుంటుంది? దీనిని పరిశోధించడానికి, నేను క్లస్టర్ నోడ్‌లలో వివిధ వైఫల్యాలను అనుకరించే టెస్ట్ బెంచ్‌ను అభివృద్ధి చేసాను, సేవ పునరుద్ధరించబడే వరకు వేచి ఉంది, విఫలమైన నోడ్‌ను తిరిగి పొందుతుంది మరియు లూప్‌లో పరీక్షను కొనసాగిస్తుంది. ఈ ప్రాజెక్ట్‌ను మొదట hapgsql అని పిలిచేవారు, కానీ కాలక్రమేణా నేను ఒక అచ్చును కలిగి ఉన్న పేరుతో విసుగు చెందాను. అందువల్ల, నేను తప్పు-తట్టుకునే డేటాబేస్‌లను పిలవడం ప్రారంభించాను (మరియు ఫ్లోట్ IP వాటిని సూచించడం) క్రోగన్ (అన్ని ముఖ్యమైన అవయవాలు నకిలీ చేయబడిన కంప్యూటర్ గేమ్‌లోని పాత్ర), మరియు నోడ్‌లు, క్లస్టర్‌లు మరియు ప్రాజెక్ట్ కూడా తుచంక (క్రోగన్లు నివసించే గ్రహం).

ఇప్పుడు యాజమాన్యం అనుమతించింది MIT లైసెన్స్ కింద ఓపెన్ సోర్స్ కమ్యూనిటీకి ప్రాజెక్ట్‌ను తెరవండి. README త్వరలో ఆంగ్లంలోకి అనువదించబడుతుంది (ఎందుకంటే ప్రధాన వినియోగదారులు పేస్‌మేకర్ మరియు PostgreSQL డెవలపర్‌లు అవుతారని భావిస్తున్నారు), మరియు README యొక్క పాత రష్యన్ వెర్షన్‌ను (పాక్షికంగా) ఈ కథనం రూపంలో అందించాలని నేను నిర్ణయించుకున్నాను.

క్లస్టర్‌లు వర్చువల్ మెషీన్‌లలో అమలు చేయబడతాయి VirtualBox. మొత్తం 12 వర్చువల్ మెషీన్‌లు (మొత్తం 36GiB) అమలు చేయబడతాయి, ఇవి 4 ఫాల్ట్-టాలరెంట్ క్లస్టర్‌లను ఏర్పరుస్తాయి (వివిధ ఎంపికలు). మొదటి రెండు క్లస్టర్‌లు రెండు PostgreSQL సర్వర్‌లను కలిగి ఉంటాయి, ఇవి వేర్వేరు డేటా సెంటర్‌లలో ఉన్నాయి మరియు ఒక సాధారణ సర్వర్ సాక్షి c కోరం పరికరం (మూడవ డేటా సెంటర్‌లో చౌకైన వర్చువల్ మెషీన్‌లో హోస్ట్ చేయబడింది), ఇది అనిశ్చితిని పరిష్కరిస్తుంది 50% / 50%, మీ ఓటును పార్టీలలో ఒకదానికి ఇవ్వడం. మూడు డేటా సెంటర్లలో మూడవ క్లస్టర్: ఒక మాస్టర్, ఇద్దరు బానిసలు, నం కోరం పరికరం. నాల్గవ క్లస్టర్‌లో నాలుగు PostgreSQL సర్వర్‌లు ఉంటాయి, ఒక్కో డేటా సెంటర్‌కు రెండు: ఒక మాస్టర్, మిగిలిన ప్రతిరూపాలు, అలాగే ఉపయోగాలు సాక్షి c కోరం పరికరం. నాల్గవది రెండు సర్వర్లు లేదా ఒక డేటా సెంటర్ వైఫల్యాన్ని తట్టుకోగలదు. అవసరమైతే ఈ పరిష్కారాన్ని పెద్ద సంఖ్యలో ప్రతిరూపాలకు స్కేల్ చేయవచ్చు.

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

సంస్కరణలు

v0. VirtualBox 7లో CentOS 11 మరియు PostgreSQL 6.1తో పని చేస్తుంది.

క్లస్టర్ నిర్మాణం

అన్ని క్లస్టర్‌లు బహుళ డేటా సెంటర్‌లలో ఉండేలా రూపొందించబడ్డాయి, అవి ఒకే ఫ్లాట్ నెట్‌వర్క్‌గా మిళితం చేయబడతాయి మరియు ఒకే డేటా సెంటర్ వైఫల్యం లేదా నెట్‌వర్క్ ఐసోలేషన్‌ను తట్టుకోవాలి. అందుకే అసాధ్యం వ్యతిరేకంగా రక్షణ కోసం ఉపయోగించండి స్ప్లిట్-మెదడు ప్రామాణిక పేస్‌మేకర్ టెక్నాలజీ అని పిలుస్తారు స్టోనిత్ (షూట్ ది అదర్ నోడ్ ఇన్ ది హెడ్) లేదా ఫెన్సింగ్. దాని సారాంశం: క్లస్టర్‌లోని నోడ్‌లు ఏదైనా నోడ్‌లో ఏదో తప్పుగా ఉన్నాయని అనుమానించడం ప్రారంభిస్తే, అది స్పందించడం లేదు లేదా తప్పుగా ప్రవర్తిస్తోంది, అప్పుడు వారు దానిని "బాహ్య" పరికరాల ద్వారా బలవంతంగా ఆఫ్ చేస్తారు, ఉదాహరణకు, IPMI లేదా UPS నియంత్రణ కార్డ్ . కానీ ఒకే వైఫల్యం సంభవించినప్పుడు, IPMI లేదా UPS సర్వర్ పని చేస్తూనే ఉన్న సందర్భాల్లో మాత్రమే ఇది పని చేస్తుంది. మొత్తం డేటా సెంటర్ విఫలమైనప్పుడు (ఉదాహరణకు, శక్తిని కోల్పోయినప్పుడు) మరింత విపత్కర వైఫల్యం నుండి రక్షించడానికి ఇక్కడ మేము ప్లాన్ చేస్తున్నాము. మరియు అటువంటి తిరస్కరణతో, ప్రతిదీ స్టోనిత్-పరికరాలు (IPMI, UPS, మొదలైనవి) కూడా పని చేయవు.

బదులుగా, వ్యవస్థ కోరం ఆలోచనపై ఆధారపడి ఉంటుంది. అన్ని నోడ్‌లకు వాయిస్ ఉంటుంది మరియు అన్ని నోడ్‌లలో సగానికి పైగా చూడగలిగేవి మాత్రమే పని చేయగలవు. ఈ పరిమాణాన్ని "సగం + 1" అంటారు కోరం. కోరం చేరుకోకపోతే, నోడ్ అది నెట్‌వర్క్ ఐసోలేషన్‌లో ఉందని మరియు దాని వనరులను తప్పనిసరిగా ఆఫ్ చేయాలని నిర్ణయించుకుంటుంది, అనగా. ఇది ఏమిటి స్ప్లిట్-మెదడు రక్షణ. ఈ ప్రవర్తనకు బాధ్యత వహించే సాఫ్ట్‌వేర్ పని చేయకపోతే, వాచ్‌డాగ్, ఉదాహరణకు, IPMI ఆధారంగా పని చేయాల్సి ఉంటుంది.

నోడ్‌ల సంఖ్య సమానంగా ఉంటే (రెండు డేటా సెంటర్‌లలో ఒక క్లస్టర్), అప్పుడు అనిశ్చితి అని పిలవబడేవి తలెత్తవచ్చు 50% / 50% (సగం సగం) నెట్‌వర్క్ ఐసోలేషన్ క్లస్టర్‌ను సరిగ్గా సగానికి విభజించినప్పుడు. అందువల్ల, సరి సంఖ్యలో నోడ్‌ల కోసం, మేము జోడిస్తాము కోరం పరికరం మూడవ డేటా సెంటర్‌లో చౌకైన వర్చువల్ మెషీన్‌లో ప్రారంభించబడే అవాంఛనీయ డెమోన్. అతను సెగ్మెంట్లలో ఒకదానికి (అతను చూసే) తన ఓటును ఇచ్చాడు మరియు తద్వారా 50%/50% అనిశ్చితిని పరిష్కరిస్తాడు. కోరం పరికరం ప్రారంభించబడే సర్వర్‌కు నేను పేరు పెట్టాను సాక్షి (repmgr నుండి పదజాలం, నేను దానిని ఇష్టపడ్డాను).

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

తుచంకా1 (కంపాక్షన్‌తో కూడిన సర్క్యూట్)

నిర్మాణం

మేము తక్కువ లోడ్‌తో అనేక చిన్న డేటాబేస్‌లను కలిగి ఉన్నాము, దీని కోసం చదవడానికి మాత్రమే లావాదేవీల కోసం హాట్ స్టాండ్‌బై మోడ్‌లో అంకితమైన స్లేవ్ సర్వర్‌ను నిర్వహించడం లాభదాయకం కాదు (అలాంటి వనరులను వృధా చేయవలసిన అవసరం లేదు).

ప్రతి డేటా సెంటర్‌కి ఒక సర్వర్ ఉంటుంది. ప్రతి సర్వర్‌కు రెండు PostgreSQL ఉదంతాలు ఉంటాయి (PostgreSQL పరిభాషలో వాటిని క్లస్టర్‌లు అంటారు, కానీ గందరగోళాన్ని నివారించడానికి నేను వాటిని సందర్భాలు (ఇతర డేటాబేస్‌లతో సారూప్యత ద్వారా) అని పిలుస్తాను మరియు నేను పేస్‌మేకర్ క్లస్టర్‌ల క్లస్టర్‌లను మాత్రమే పిలుస్తాను). ఒక ఉదాహరణ మాస్టర్ మోడ్‌లో పనిచేస్తుంది మరియు ఇది మాత్రమే సేవలను అందిస్తుంది (దీనికి ఫ్లోట్ IP మాత్రమే దారి తీస్తుంది). రెండవ ఉదాహరణ రెండవ డేటా సెంటర్‌కు బానిసగా పని చేస్తుంది మరియు దాని మాస్టర్ విఫలమైతే మాత్రమే సేవలను అందిస్తుంది. చాలా సమయం రెండు (మాస్టర్)లో ఒక ఉదాహరణ మాత్రమే సేవలను అందిస్తుంది (అభ్యర్థనలను నిర్వహిస్తుంది), అన్ని సర్వర్ వనరులు మాస్టర్ కోసం ఆప్టిమైజ్ చేయబడతాయి (మెమొరీ షేర్డ్_బఫర్స్ కాష్ కోసం కేటాయించబడింది, మొదలైనవి), కానీ రెండవ ఉదాహరణ డేటా సెంటర్లలో ఒకదాని విఫలమైతే (ఫైల్ సిస్టమ్ కాష్ ద్వారా సబ్‌ప్టిమల్ ఆపరేషన్ కోసం) తగినంత వనరులు కూడా ఉన్నాయి. క్లస్టర్ యొక్క సాధారణ ఆపరేషన్ సమయంలో స్లేవ్ సేవలను అందించడు (రీడ్ ఓన్లీ అభ్యర్థనలను నిర్వహించడు), తద్వారా అదే మెషీన్‌లో మాస్టర్‌తో వనరుల కోసం యుద్ధం ఉండదు.

రెండు నోడ్‌ల విషయంలో, అసమకాలిక రెప్లికేషన్‌తో మాత్రమే తప్పు సహనం సాధ్యమవుతుంది, ఎందుకంటే సింక్రోనస్ రెప్లికేషన్‌తో, బానిస యొక్క వైఫల్యం యజమానిని ఆపడానికి దారి తీస్తుంది.

సాక్షిలో వైఫల్యం

సాక్ష్యం ఇవ్వడంలో వైఫల్యం (కోరం పరికరం) నేను Tuchanka1 క్లస్టర్ కోసం మాత్రమే పరిగణిస్తాను, మిగతా వాటితో ఇది ఒకే కథ అవుతుంది. సాక్షి విఫలమైతే, క్లస్టర్ నిర్మాణంలో ఏమీ మారదు, ప్రతిదీ అదే విధంగా పని చేస్తూనే ఉంటుంది. కానీ కోరం 2కి 3 అవుతుంది, అందువల్ల ఏదైనా తదుపరి వైఫల్యం క్లస్టర్‌కు ప్రాణాంతకం అవుతుంది. ఇది ఇంకా అత్యవసరంగా పరిష్కరించాలి.

తుచంకా1 తిరస్కరణ

Tuchanka1 కోసం డేటా సెంటర్‌లలో ఒకదాని వైఫల్యం. ఈ విషయంలో సాక్షి రెండవ డేటా సెంటర్‌లో రెండవ నోడ్‌కి తన ఓటును వేసింది. అక్కడ, మాజీ బానిస మాస్టర్‌గా మారతాడు, ఫలితంగా, ఇద్దరు మాస్టర్‌లు ఒకే సర్వర్‌లో పని చేస్తారు మరియు వారి ఫ్లోట్ IPలు రెండూ వాటిని సూచిస్తాయి.

తుచంక2 (క్లాసికల్)

నిర్మాణం

రెండు నోడ్ల క్లాసిక్ పథకం. యజమాని ఒకదానిపై, బానిస రెండవదానిపై పనిచేస్తాడు. రెండూ అభ్యర్థనలను అమలు చేయగలవు (స్లేవ్ చదవబడుతుంది మాత్రమే), కాబట్టి రెండూ ఫ్లోట్ IP ద్వారా సూచించబడతాయి: krogan2 మాస్టర్, krogan2s1 బానిస. యజమాని మరియు బానిస ఇద్దరూ తప్పు సహనం కలిగి ఉంటారు.

రెండు నోడ్‌ల విషయంలో, అసమకాలిక రెప్లికేషన్‌తో మాత్రమే తప్పు సహనం సాధ్యమవుతుంది, ఎందుకంటే సింక్రోనస్ రెప్లికేషన్‌తో, బానిస యొక్క వైఫల్యం మాస్టర్ యొక్క స్టాప్‌కు దారి తీస్తుంది.

తుచంకా2 తిరస్కరణ

డేటా సెంటర్లలో ఒకటి విఫలమైతే సాక్షి రెండవదానికి ఓట్లు వేస్తారు. పని చేసే ఏకైక డేటా సెంటర్‌లో, మాస్టర్ పెంచబడతారు మరియు రెండు ఫ్లోట్ IPలు దానిని సూచిస్తాయి: మాస్టర్ మరియు స్లేవ్. వాస్తవానికి, మాస్టర్ మరియు స్లేవ్ ఫ్లోట్ IP నుండి అన్ని కనెక్షన్‌లు మరియు అభ్యర్థనలను ఏకకాలంలో ఆమోదించడానికి తగిన వనరులు (కనెక్షన్ పరిమితులు, మొదలైనవి) ఉండే విధంగా ఉదాహరణ తప్పనిసరిగా కాన్ఫిగర్ చేయబడాలి. అంటే, సాధారణ ఆపరేషన్ సమయంలో అది పరిమితుల తగినంత సరఫరాను కలిగి ఉండాలి.

తుచంక4 (చాలా మంది బానిసలు)

నిర్మాణం

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

ఈ పథకం యొక్క మరొక లక్షణం ఏమిటంటే, ఒక సమకాలిక ప్రతిరూపాన్ని నిర్వహించడం ఇప్పటికే సాధ్యమే. ఇది వీలైతే, మాస్టర్ వలె అదే డేటా సెంటర్‌లోని ప్రతిరూపానికి బదులుగా మరొక డేటా సెంటర్‌కు ప్రతిరూపం చేయడానికి కాన్ఫిగర్ చేయబడింది. మాస్టర్ మరియు ప్రతి బానిస ఫ్లోట్ IP ద్వారా సూచించబడతారు. అదృష్టవశాత్తూ, బానిసల మధ్య ఏదో ఒకవిధంగా అభ్యర్థనలను సమతుల్యం చేయడం అవసరం sql ప్రాక్సీ, ఉదాహరణకు, క్లయింట్ వైపు. వివిధ రకాల క్లయింట్‌లకు వివిధ రకాలు అవసరం కావచ్చు sql ప్రాక్సీ, మరియు ఎవరికి ఏది అవసరమో క్లయింట్ డెవలపర్‌లకు మాత్రమే తెలుసు. ఈ కార్యాచరణను బాహ్య డెమోన్ లేదా క్లయింట్ లైబ్రరీ (కనెక్షన్ పూల్) మొదలైన వాటి ద్వారా అమలు చేయవచ్చు. ఇదంతా ఫెయిల్‌ఓవర్ డేటాబేస్ క్లస్టర్ (ఫెయిల్‌ఓవర్ SQL ప్రాక్సీ క్లయింట్ తప్పు సహనంతో పాటు స్వతంత్రంగా అమలు చేయవచ్చు).

తుచంకా4 తిరస్కరణ

ఒక డేటా సెంటర్ (అంటే, రెండు సర్వర్లు) విఫలమైతే, సాక్షి రెండవదానికి ఓటు వేసింది. ఫలితంగా, రెండవ డేటా సెంటర్‌లో రెండు సర్వర్లు నడుస్తున్నాయి: ఒకటి మాస్టర్‌ను నడుపుతోంది మరియు మాస్టర్ ఫ్లోట్ IP దానికి పాయింట్లు (రీడ్-రైట్ అభ్యర్థనలను స్వీకరించడానికి); మరియు రెండవ సర్వర్‌లో సింక్రోనస్ రెప్లికేషన్‌తో స్లేవ్ నడుస్తున్నాడు మరియు స్లేవ్ ఫ్లోట్ IPలలో ఒకటి దానిని సూచిస్తుంది (చదవడానికి మాత్రమే అభ్యర్థనల కోసం).

గమనించదగ్గ మొదటి విషయం ఏమిటంటే, అన్ని స్లేవ్ ఫ్లోట్ IPలు కార్మికులు కాదు, కానీ ఒక్కరు మాత్రమే. మరియు దానితో సరిగ్గా పని చేయడానికి ఇది అవసరం sql ప్రాక్సీ అన్ని అభ్యర్థనలను మిగిలిన ఏకైక ఫ్లోట్ IPకి దారి మళ్లించాయి; మరియు ఉంటే sql ప్రాక్సీ లేదు, అప్పుడు మీరు కనెక్షన్ URLలో కామాలతో వేరు చేయబడిన అన్ని ఫ్లోట్ IP స్లేవ్‌లను జాబితా చేయవచ్చు. ఈ సందర్భంలో, తో libpq కనెక్షన్ మొదటి పని IPకి ఉంటుంది, ఇది ఆటోమేటిక్ టెస్టింగ్ సిస్టమ్‌లో చేయబడుతుంది. బహుశా ఇతర లైబ్రరీలలో, ఉదాహరణకు, JDBC, ఇది పని చేయదు మరియు అవసరం sql ప్రాక్సీ. బానిసల కోసం ఫ్లోట్ IPలను ఒక సర్వర్‌లో ఏకకాలంలో పెంచడం నిషేధించబడినందున ఇది జరుగుతుంది, తద్వారా వాటిలో చాలా వరకు అమలులో ఉన్నట్లయితే అవి స్లేవ్ సర్వర్‌ల మధ్య సమానంగా పంపిణీ చేయబడతాయి.

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

Tuchanka3 (3 డేటా కేంద్రాలు)

నిర్మాణం

ఇది పూర్తిగా పనిచేసే మూడు డేటా సెంటర్‌లు ఉన్న పరిస్థితికి సంబంధించిన క్లస్టర్, వీటిలో ప్రతి ఒక్కటి పూర్తిగా పనిచేసే డేటాబేస్ సర్వర్‌ని కలిగి ఉంటుంది. ఈ విషయంలో కోరం పరికరం అవసరం లేదు. ఒక డేటా సెంటర్‌లో మాస్టర్ సిబ్బంది ఉంటారు, మిగిలిన రెండు బానిసలచే పని చేస్తారు. రెప్లికేషన్ సింక్రోనస్‌గా ఉంటుంది, ఏదైనా టైప్ చేయండి (స్లేవ్1, స్లేవ్2), అంటే, క్లయింట్ కమిట్‌ను అంగీకరించినట్లు మొదటగా ప్రతిస్పందించినప్పుడు క్లయింట్ కమిట్ నిర్ధారణను అందుకుంటారు. వనరులు మాస్టర్ కోసం ఒక ఫ్లోట్ IP మరియు బానిసల కోసం రెండు ద్వారా సూచించబడతాయి. Tuchanka4 కాకుండా, మూడు ఫ్లోట్ IPలు తప్పు-తట్టుకునేవి. చదవడానికి మాత్రమే SQL ప్రశ్నలను బ్యాలెన్స్ చేయడానికి మీరు ఉపయోగించవచ్చు sql ప్రాక్సీ (ప్రత్యేక తప్పు సహనంతో), లేదా ఒక స్లేవ్ ఫ్లోట్ IPని సగం మంది క్లయింట్‌లకు మరియు మిగిలిన సగం రెండవ వారికి కేటాయించండి.

తుచంకా3 తిరస్కరణ

డేటా సెంటర్లలో ఒకటి విఫలమైతే, రెండు మిగిలి ఉన్నాయి. ఒకదానిలో, మాస్టర్ నుండి మాస్టర్ మరియు ఫ్లోట్ IP పెంచబడతాయి, రెండవది - స్లేవ్ మరియు రెండు స్లేవ్ ఫ్లోట్ IPలు (ఉదాహరణకు రెండు స్లేవ్ ఫ్లోట్ IPల నుండి అన్ని కనెక్షన్‌లను అంగీకరించడానికి వనరుల రెట్టింపు నిల్వలు ఉండాలి). యజమానులు మరియు బానిసల మధ్య సమకాలిక ప్రతిరూపం. అలాగే, క్లస్టర్ రెండు డేటా సెంటర్లు (ఏకకాలంలో ధ్వంసం చేయకపోతే) ధ్వంసమైన సందర్భంలో కట్టుబడి మరియు ధృవీకరించబడిన లావాదేవీల గురించి సమాచారాన్ని (సమాచారానికి నష్టం ఉండదు) సేవ్ చేస్తుంది.

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

ఆటోమేటిక్ టెస్టింగ్ సిస్టమ్

వివిధ లోపాలను అనుకరించడం ద్వారా క్లస్టర్ల తప్పు సహనాన్ని పరీక్షించడానికి, ఆటోమేటిక్ టెస్టింగ్ సిస్టమ్ సృష్టించబడింది. స్క్రిప్ట్ ద్వారా ప్రారంభించబడింది test/failure. మీరు పరీక్షించాలనుకుంటున్న క్లస్టర్‌ల సంఖ్యలను స్క్రిప్ట్ పారామీటర్‌లుగా తీసుకోవచ్చు. ఉదాహరణకు ఈ ఆదేశం:

test/failure 2 3

రెండవ మరియు మూడవ క్లస్టర్‌ను మాత్రమే పరీక్షిస్తుంది. పారామితులు పేర్కొనబడకపోతే, అన్ని క్లస్టర్‌లు పరీక్షించబడతాయి. అన్ని క్లస్టర్‌లు సమాంతరంగా పరీక్షించబడతాయి మరియు ఫలితం tmux ప్యానెల్‌లో ప్రదర్శించబడుతుంది. Tmux ఒక ప్రత్యేక tmux సర్వర్‌ని ఉపయోగిస్తుంది, కాబట్టి స్క్రిప్ట్‌ను డిఫాల్ట్ tmux నుండి అమలు చేయవచ్చు, ఫలితంగా సమూహ tmux ఏర్పడుతుంది. టెర్మినల్‌ను పెద్ద విండోలో మరియు చిన్న ఫాంట్‌తో ఉపయోగించమని నేను సిఫార్సు చేస్తున్నాను. పరీక్ష ప్రారంభమయ్యే ముందు, స్క్రిప్ట్ పూర్తయిన సమయంలో అన్ని వర్చువల్ మిషన్‌లు స్నాప్‌షాట్‌కి తిరిగి వస్తాయి setup.

టెర్మినల్ పరీక్షించబడుతున్న క్లస్టర్‌ల సంఖ్యను బట్టి నిలువు వరుసలుగా విభజించబడింది; డిఫాల్ట్‌గా (స్క్రీన్‌షాట్‌లో) నాలుగు ఉన్నాయి. నేను Tuchanka2 యొక్క ఉదాహరణను ఉపయోగించి నిలువు వరుసల విషయాలను వివరిస్తాను. స్క్రీన్‌షాట్‌లోని ప్యానెల్‌లు లెక్కించబడ్డాయి:

1. పరీక్ష గణాంకాలు ఇక్కడ ప్రదర్శించబడతాయి. నిలువు వరుసలు:
   • వైఫల్యం - తప్పును అనుకరించే పరీక్ష పేరు (స్క్రిప్ట్‌లో ఫంక్షన్).
   • స్పందన - క్లస్టర్ దాని కార్యాచరణను పునరుద్ధరించిన సెకన్లలో అంకగణిత సగటు సమయం. క్లస్టర్ దాని కార్యాచరణను పునరుద్ధరిస్తుంది మరియు సేవలను అందించడం కొనసాగించగలిగిన క్షణం వరకు ఇది తప్పును అనుకరించే స్క్రిప్ట్ ప్రారంభం నుండి కొలవబడుతుంది. సమయం చాలా తక్కువగా ఉంటే, ఉదాహరణకు, ఆరు సెకన్లు (ఇది చాలా మంది బానిసలు (తుచంకా 3 మరియు తుచంకా 4) ఉన్న సమూహాలలో జరుగుతుంది), దీని అర్థం లోపం అసమకాలిక బానిసపై ఉందని మరియు పనితీరును ఏ విధంగానూ ప్రభావితం చేయలేదని అర్థం; క్లస్టర్ స్థితి స్విచ్‌లు.
   • విచలనం - విలువ యొక్క స్ప్రెడ్ (ఖచ్చితత్వం) చూపిస్తుంది స్పందన ప్రామాణిక విచలనం పద్ధతిని ఉపయోగించడం.
   • కౌంట్ - ఈ పరీక్ష ఎన్నిసార్లు జరిగింది.
2. క్లస్టర్ ప్రస్తుతం ఏమి చేస్తుందో అంచనా వేయడానికి ఒక చిన్న లాగ్ మిమ్మల్ని అనుమతిస్తుంది. పునరావృతం (పరీక్ష) సంఖ్య, టైమ్‌స్టాంప్ మరియు ఆపరేషన్ పేరు ప్రదర్శించబడతాయి. చాలా పొడవుగా (> 5 నిమిషాలు) నడపడం సమస్యను సూచిస్తుంది.
3. గుండె (హృదయం) - ప్రస్తుత సమయం. పనితీరు యొక్క దృశ్య అంచనా కోసం మాస్టర్ ఫ్లోట్ IP మాస్టర్ ఉపయోగించి ప్రస్తుత సమయం నిరంతరం దాని పట్టికకు వ్రాయబడుతుంది. విజయవంతమైతే, ఫలితం ఈ ప్యానెల్‌లో ప్రదర్శించబడుతుంది.
4. బీట్ (పల్స్) - "ప్రస్తుత సమయం", ఇది గతంలో స్క్రిప్ట్ ద్వారా రికార్డ్ చేయబడింది గుండె మాస్టర్, ఇప్పుడు నుండి చదవండి బానిస దాని ఫ్లోట్ IP ద్వారా. స్లేవ్ మరియు రెప్లికేషన్ యొక్క పనితీరును దృశ్యమానంగా అంచనా వేయడానికి మిమ్మల్ని అనుమతిస్తుంది. Tuchanka1లో ఫ్లోట్ IPతో బానిసలు లేరు (సేవలు అందించే బానిసలు లేరు), కానీ రెండు ఉదాహరణలు (DBలు) ఉన్నాయి, కనుక ఇది ఇక్కడ చూపబడదు బీట్మరియు గుండె రెండవ ఉదాహరణ.
5. యుటిలిటీని ఉపయోగించి క్లస్టర్ ఆరోగ్యాన్ని పర్యవేక్షించడం pcs mon. నోడ్‌ల అంతటా వనరుల నిర్మాణం, పంపిణీ మరియు ఇతర ఉపయోగకరమైన సమాచారాన్ని చూపుతుంది.
6. క్లస్టర్‌లోని ప్రతి వర్చువల్ మిషన్ నుండి సిస్టమ్ పర్యవేక్షణ ఇక్కడ ప్రదర్శించబడుతుంది. క్లస్టర్‌లో ఎన్ని వర్చువల్ మెషీన్‌లు ఉన్నాయి అనేదానిపై ఆధారపడి ఇటువంటి మరిన్ని ప్యానెల్‌లు ఉండవచ్చు. రెండు గ్రాఫ్‌లు CPU లోడ్ (వర్చువల్ మిషన్లు రెండు ప్రాసెసర్లను కలిగి ఉంటాయి), వర్చువల్ మెషీన్ పేరు, సిస్టమ్ లోడ్ (సగటు 5, 10 మరియు 15 నిమిషాల కంటే ఎక్కువ ఉన్నందున లోడ్ యావరేజ్ అని పేరు పెట్టారు), డేటా మరియు మెమరీ కేటాయింపును ప్రాసెస్ చేయండి.
7. స్క్రిప్ట్ నిర్వహిస్తున్న పరీక్ష యొక్క ట్రేస్. ఒక లోపం సంభవించినప్పుడు - ఆపరేషన్ యొక్క ఆకస్మిక అంతరాయం లేదా అంతులేని నిరీక్షణ చక్రం - ఇక్కడ మీరు ఈ ప్రవర్తనకు కారణాన్ని చూడవచ్చు.

పరీక్ష రెండు దశల్లో జరుగుతుంది. మొదట, స్క్రిప్ట్ అన్ని రకాల పరీక్షల ద్వారా వెళుతుంది, ఈ పరీక్షను వర్తింపజేయడానికి యాదృచ్ఛికంగా వర్చువల్ మెషీన్‌ను ఎంచుకుంటుంది. అప్పుడు అంతులేని పరీక్ష చక్రం నిర్వహించబడుతుంది, వర్చువల్ మిషన్లు మరియు తప్పు ప్రతిసారీ యాదృచ్ఛికంగా ఎంపిక చేయబడతాయి. టెస్టింగ్ స్క్రిప్ట్ (దిగువ ప్యానెల్) యొక్క ఆకస్మిక ముగింపు లేదా దేనికోసం వేచి ఉండే అంతులేని లూప్ (> ఒక ఆపరేషన్ కోసం 5 నిమిషాల ఎగ్జిక్యూషన్ సమయం, ఇది ట్రేస్‌లో చూడవచ్చు) ఈ క్లస్టర్‌లోని కొన్ని పరీక్షలు విఫలమయ్యాయని సూచిస్తుంది.

ప్రతి పరీక్ష క్రింది కార్యకలాపాలను కలిగి ఉంటుంది:

1. లోపాన్ని అనుకరించే ఫంక్షన్‌ను ప్రారంభించండి.
2. రెడీ? — క్లస్టర్ పునరుద్ధరించబడే వరకు వేచి ఉంది (అన్ని సేవలు అందించబడినప్పుడు).
3. క్లస్టర్ పునరుద్ధరణ గడువు ముగింపును చూపుతుంది (స్పందన).
4. పరిష్కరించండి - క్లస్టర్ "మరమ్మత్తు చేయబడుతోంది." ఆ తర్వాత అది పూర్తిగా పనిచేసే స్థితికి తిరిగి రావాలి మరియు తదుపరి పనిచేయకపోవడానికి సిద్ధంగా ఉండాలి.

వారు ఏమి చేస్తారనే వివరణతో పరీక్షల జాబితా ఇక్కడ ఉంది:

• ఫోర్క్ బాంబ్: ఫోర్క్ బాంబును ఉపయోగించి "జ్ఞాపకశక్తి లేదు"ని సృష్టిస్తుంది.
• ఔట్‌ఆఫ్‌స్పేస్: హార్డ్ డ్రైవ్ నిండింది. కానీ పరీక్ష ప్రతీకాత్మకమైనది; పరీక్ష సమయంలో సృష్టించబడిన అతితక్కువ లోడ్‌తో, హార్డ్ డ్రైవ్ నిండినప్పుడు PostgreSQL సాధారణంగా విఫలం కాదు.
• పోస్ట్‌గ్రెస్-కిల్: ఆదేశంతో PostgreSQLని చంపుతుంది killall -KILL postgres.
• పోస్ట్‌గ్రెస్-స్టాప్: PostgreSQL కమాండ్‌ని హ్యాంగ్ చేస్తుంది killall -STOP postgres.
• పవర్ ఆఫ్: కమాండ్‌తో వర్చువల్ మిషన్‌ను “డి-ఎనర్జైజ్” చేస్తుంది VBoxManage controlvm "виртуалка" poweroff.
• తిరిగి నిర్దారించు : ఆదేశంతో వర్చువల్ మిషన్‌ను ఓవర్‌లోడ్ చేస్తుంది VBoxManage controlvm "виртуалка" reset.
• SBD-స్టాప్: ఆదేశంతో SBD దెయ్యాన్ని సస్పెండ్ చేస్తుంది killall -STOP sbd.
• షట్ డౌన్: SSH ద్వారా వర్చువల్ మెషీన్‌కు ఆదేశాన్ని పంపుతుంది systemctl poweroff, సిస్టమ్ సరసముగా మూసివేయబడుతుంది.
• అన్‌లింక్ చేయండి: నెట్‌వర్క్ ఐసోలేషన్, కమాండ్ VBoxManage controlvm "виртуалка" setlinkstate1 off.

ప్రామాణిక tmux ఆదేశం "kill-window"ని ఉపయోగించి పరీక్షను పూర్తి చేయడం Ctrl-b &, లేదా "detach-client" కమాండ్ Ctrl-b డి: ఈ సమయంలో పరీక్ష ముగుస్తుంది, tmux మూసివేయబడుతుంది, వర్చువల్ మిషన్లు ఆఫ్ చేయబడతాయి.

పరీక్ష సమయంలో గుర్తించబడిన సమస్యలు

• ఈ క్షణం లో వాచ్‌డాగ్ డెమోన్ sbd గమనించిన డెమోన్‌లను ఆపడానికి పని చేస్తుంది, కానీ వాటిని స్తంభింపజేయదు. మరియు, ఫలితంగా, గడ్డకట్టడానికి మాత్రమే దారితీసే లోపాలు కోరోసింక్ и పేస్ మేకర్, కానీ ఉరి లేదు sbd. చెక్ కోసం కోరోసింక్ ఇప్పటికే ఉంది PR#83 (GitHubలో sbd), థ్రెడ్‌కు అంగీకరించబడింది మాస్టర్. వారు (PR#83లో) పేస్‌మేకర్‌కి కూడా అలాంటిదేదో ఉంటుందని వాగ్దానం చేసారు, నేను ఆశిస్తున్నాను రెడ్‌హాట్ 8 చేస్తాను. కానీ అలాంటి "వైకల్యాలు" ఊహాజనితమైనవి మరియు వాటిని ఉపయోగించి కృత్రిమంగా సులభంగా అనుకరించవచ్చు, ఉదాహరణకు, killall -STOP corosync, కానీ నిజ జీవితంలో ఎప్పుడూ కలవలేదు.

• У పేస్ మేకర్ కోసం వెర్షన్ లో CentOS 7 తప్పుగా సెట్ చేయబడింది sync_timeout у కోరం పరికరంఫలితంగా ఒక నోడ్ విఫలమైతే, కొంత సంభావ్యతతో రెండవ నోడ్ కూడా రీబూట్ చేయబడింది, దానికి మాస్టర్ తరలించవలసి ఉంది. విస్తరణ ద్వారా నయమవుతుంది sync_timeout у కోరం పరికరం విస్తరణ సమయంలో (స్క్రిప్ట్‌లో setup/setup1) ఈ సవరణను డెవలపర్‌లు ఆమోదించలేదు పేస్ మేకర్, బదులుగా వారు ఈ గడువు స్వయంచాలకంగా లెక్కించబడే విధంగా (కొన్ని పేర్కొనబడని భవిష్యత్తులో) మౌలిక సదుపాయాలను పునఃరూపకల్పనకు హామీ ఇచ్చారు.

• డేటాబేస్ కాన్ఫిగరేషన్ దానిని నిర్దేశిస్తే LC_MESSAGES (వచన సందేశాలు) యూనికోడ్ ఉపయోగించవచ్చు, ఉదా. ru_RU.UTF-8, ఆపై ప్రారంభంలో postgres లొకేల్ UTF-8 లేని వాతావరణంలో, ఖాళీ వాతావరణంలో చెప్పండి (ఇక్కడ పేస్ మేకర్+pgsqlms(పాఫ్) పరుగులు postgres) అప్పుడు లాగ్‌లో UTF-8 అక్షరాలకు బదులుగా ప్రశ్న గుర్తులు ఉంటాయి. ఈ సందర్భంలో ఏమి చేయాలో PostgreSQL డెవలపర్‌లు అంగీకరించలేదు. ఇది ఖర్చవుతుంది, మీరు ఇన్స్టాల్ చేయాలి LC_MESSAGES=en_US.UTF-8 డేటాబేస్ ఉదాహరణను కాన్ఫిగర్ చేస్తున్నప్పుడు (సృష్టిస్తున్నప్పుడు).

• wal_receiver_timeout సెట్ చేయబడితే (డిఫాల్ట్‌గా ఇది 60సె), ఆపై tuchanka3 మరియు tuchanka4 క్లస్టర్‌లలోని మాస్టర్‌పై PostgreSQL-STOP పరీక్ష సమయంలో ప్రతిరూపం కొత్త మాస్టర్‌కి మళ్లీ కనెక్ట్ అవ్వదు. అక్కడ ప్రతిరూపం సమకాలీకరించబడుతుంది, కాబట్టి బానిస ఆగిపోవడమే కాదు, కొత్త యజమాని కూడా. PostgreSQLని కాన్ఫిగర్ చేస్తున్నప్పుడు wal_receiver_timeout=0 సెట్ చేయడం ద్వారా పని చేస్తుంది.

• అప్పుడప్పుడు నేను ForkBomb పరీక్ష (మెమరీ ఓవర్‌ఫ్లో)లో PostgreSQLలో రెప్లికేషన్ ఫ్రీజ్‌లను గమనించాను. ForkBomb తర్వాత, కొన్నిసార్లు బానిసలు కొత్త మాస్టర్‌కి మళ్లీ కనెక్ట్ కాకపోవచ్చు. నేను దీనిని tuchanka3 మరియు tuchanka4 క్లస్టర్‌లలో మాత్రమే ఎదుర్కొన్నాను, ఇక్కడ సింక్రోనస్ రెప్లికేషన్ కారణంగా మాస్టర్ స్తంభించిపోయింది. చాలా కాలం తర్వాత (సుమారు రెండు గంటలు) సమస్య దానంతట అదే సమసిపోయింది. దీన్ని సరిచేయడానికి మరింత పరిశోధన అవసరం. లక్షణాలు మునుపటి బగ్‌తో సమానంగా ఉంటాయి, ఇది వేరే కారణం వల్ల వస్తుంది, కానీ అదే పరిణామాలతో.

క్రోగన్ చిత్రం నుండి తీసుకోబడింది విచలనమైన కళ రచయిత అనుమతితో:

మూలం: www.habr.com