Patroni యొక్క ప్రధాన లక్ష్యం PostgreSQL కోసం అధిక లభ్యతను అందించడం. కానీ Patroni కేవలం ఒక టెంప్లేట్, ఒక రెడీమేడ్ సాధనం కాదు (సాధారణంగా, డాక్యుమెంటేషన్లో చెప్పబడింది). మొదటి చూపులో, టెస్ట్ ల్యాబ్‌లో Patroniని సెటప్ చేయడం ద్వారా, ఇది ఎంత గొప్ప సాధనమో మరియు క్లస్టర్‌ను విచ్ఛిన్నం చేయడానికి మా ప్రయత్నాలను ఎంత సులభంగా నిర్వహిస్తుందో మీరు చూడవచ్చు. అయితే, ఆచరణలో, ఉత్పత్తి వాతావరణంలో, ప్రతిదీ ఎల్లప్పుడూ పరీక్ష ప్రయోగశాలలో వలె అందంగా మరియు సొగసైనదిగా జరగదు.
నా గురించి కొంచెం చెబుతాను. నేను సిస్టమ్ అడ్మినిస్ట్రేటర్‌గా ప్రారంభించాను. వెబ్ డెవలప్‌మెంట్‌లో పనిచేశారు. నేను 2014 నుండి డేటా ఎగ్రేట్‌లో పని చేస్తున్నాను. కంపెనీ పోస్ట్‌గ్రెస్ రంగంలో కన్సల్టింగ్‌లో నిమగ్నమై ఉంది. మరియు మేము ఖచ్చితంగా పోస్ట్‌గ్రెస్‌కు సేవ చేస్తాము మరియు మేము ప్రతిరోజూ పోస్ట్‌గ్రెస్‌తో పని చేస్తాము, కాబట్టి మేము ఆపరేషన్‌కు సంబంధించి విభిన్న నైపుణ్యాలను కలిగి ఉన్నాము.
మరియు 2018 చివరిలో, మేము నెమ్మదిగా పాట్రోనిని ఉపయోగించడం ప్రారంభించాము. మరియు కొంత అనుభవం సేకరించబడింది. మేము దానిని ఏదో ఒకవిధంగా నిర్ధారించాము, దానిని ట్యూన్ చేసాము, మా ఉత్తమ అభ్యాసాలకు వచ్చాము. మరియు ఈ నివేదికలో నేను వాటి గురించి మాట్లాడతాను.
Postgres కాకుండా, నాకు Linux అంటే చాలా ఇష్టం. నేను దాని చుట్టూ దూర్చు మరియు అన్వేషించడానికి ఇష్టపడతాను, నేను కోర్లను సేకరించడానికి ఇష్టపడతాను. నేను వర్చువలైజేషన్, కంటైనర్‌లు, డాకర్, కుబెర్నెట్‌లను ఇష్టపడుతున్నాను. పాత అడ్మిన్ అలవాట్లు ప్రభావితం చేస్తున్నందున ఇవన్నీ నాకు ఆసక్తిని కలిగిస్తున్నాయి. నేను పర్యవేక్షణతో వ్యవహరించాలనుకుంటున్నాను. మరియు నాకు అడ్మినిస్ట్రేషన్‌కి సంబంధించిన పోస్ట్‌గ్రెస్ విషయాలు అంటే రెప్లికేషన్, బ్యాకప్ అంటే చాలా ఇష్టం. మరియు నా ఖాళీ సమయంలో నేను గోలో వ్రాస్తాను. నేను సాఫ్ట్‌వేర్ ఇంజనీర్‌ని కాదు, గోలో నా కోసం రాసుకుంటాను. మరియు అది నాకు ఆనందాన్ని ఇస్తుంది.
- పోస్ట్‌గ్రెస్‌కు HA (అధిక లభ్యత) లేదని మీలో చాలా మందికి తెలుసునని నేను భావిస్తున్నాను. HA పొందడానికి, మీరు ఏదైనా ఇన్‌స్టాల్ చేయాలి, దాన్ని కాన్ఫిగర్ చేయాలి, ప్రయత్నం చేసి దాన్ని పొందాలి.
- అనేక సాధనాలు ఉన్నాయి మరియు వాటిలో HA చాలా చక్కగా మరియు చాలా చక్కగా పరిష్కరించే వాటిలో Patroni ఒకటి. కానీ అన్నింటినీ టెస్ట్ ల్యాబ్‌లో ఉంచి, అమలు చేయడం ద్వారా, ఇవన్నీ పనిచేస్తాయని మనం చూడవచ్చు, కొన్ని సమస్యలను పునరుత్పత్తి చేయవచ్చు, పాత్రోని వాటిని ఎలా అందిస్తారో చూడండి. మరియు ఇవన్నీ అద్భుతంగా పనిచేస్తాయని మేము చూస్తాము.
- కానీ ఆచరణలో, మేము వివిధ సమస్యలను ఎదుర్కొన్నాము. మరియు నేను ఈ సమస్యల గురించి మాట్లాడుతాను.
- మేము దానిని ఎలా గుర్తించాము, మేము ఏమి సర్దుబాటు చేసాము - ఇది మాకు సహాయపడిందో లేదో నేను మీకు చెప్తాను.
- Patroniని ఎలా ఇన్‌స్టాల్ చేయాలో నేను మీకు చెప్పను, ఎందుకంటే మీరు ఇంటర్నెట్‌లో గూగుల్ చేయవచ్చు, ఇది ఎలా మొదలవుతుంది, ఎలా కాన్ఫిగర్ చేయబడిందో అర్థం చేసుకోవడానికి మీరు కాన్ఫిగరేషన్ ఫైల్‌లను చూడవచ్చు. మీరు పథకాలు, నిర్మాణాలు, ఇంటర్నెట్‌లో దాని గురించి సమాచారాన్ని కనుగొనడం వంటివి అర్థం చేసుకోవచ్చు.
- నేను మరొకరి అనుభవం గురించి మాట్లాడను. మేము ఎదుర్కొన్న సమస్యల గురించి మాత్రమే మాట్లాడుతాను.
- మరియు నేను Patroni మరియు PostgreSQL వెలుపల ఉన్న సమస్యల గురించి మాట్లాడను. ఉదాహరణకు, బ్యాలెన్సింగ్‌తో సంబంధం ఉన్న సమస్యలు ఉంటే, మా క్లస్టర్ కూలిపోయినప్పుడు, నేను దాని గురించి మాట్లాడను.
మరియు మేము మా నివేదికను ప్రారంభించడానికి ముందు ఒక చిన్న నిరాకరణ.
మేము ఎదుర్కొన్న ఈ సమస్యలన్నీ, మేము వాటిని మొదటి 6-7-8 నెలల ఆపరేషన్‌లో కలిగి ఉన్నాము. కాలక్రమేణా, మేము మా అంతర్గత ఉత్తమ అభ్యాసాలకు వచ్చాము. మరియు మా సమస్యలు మాయమయ్యాయి. అందువల్ల, నివేదిక దాదాపు ఆరు నెలల క్రితం ప్రకటించబడింది, ఇది నా తలపై తాజాగా ఉంది మరియు నేను అన్నింటినీ ఖచ్చితంగా గుర్తుంచుకున్నాను.
నివేదికను సిద్ధం చేసే క్రమంలో, నేను ఇప్పటికే పాత పోస్ట్‌మార్టమ్‌లను లేవనెత్తాను, లాగ్‌లను చూశాను. మరియు సమస్యల విశ్లేషణ సమయంలో కొన్ని వివరాలు మరచిపోవచ్చు లేదా కొన్ని వివరాలను పూర్తిగా పరిశోధించలేము, కాబట్టి కొన్ని పాయింట్లలో సమస్యలు పూర్తిగా పరిగణించబడలేదని లేదా కొంత సమాచారం లేకపోవడం అనిపించవచ్చు. కాబట్టి ఈ క్షణం నన్ను క్షమించమని నేను మిమ్మల్ని అడుగుతున్నాను.
పాత్రోని అంటే ఏమిటి?
- ఇది HA నిర్మించడానికి ఒక టెంప్లేట్. అది డాక్యుమెంటేషన్లో చెప్పింది. మరియు నా దృక్కోణం నుండి, ఇది చాలా సరైన వివరణ. పాత్రోని మీ సమస్యలన్నింటినీ పరిష్కరించే వెండి బుల్లెట్ కాదు, అంటే, మీరు పని చేయడానికి మరియు ప్రయోజనాలను తీసుకురావడానికి మీరు ప్రయత్నం చేయాలి.
- ఇది ప్రతి డేటాబేస్ సేవలో ఇన్‌స్టాల్ చేయబడిన ఏజెంట్ సేవ మరియు మీ పోస్ట్‌గ్రెస్ కోసం ఒక రకమైన init సిస్టమ్. ఇది పోస్ట్‌గ్రెస్‌ను ప్రారంభిస్తుంది, ఆపివేస్తుంది, పునఃప్రారంభిస్తుంది, రీకాన్ఫిగర్ చేస్తుంది మరియు మీ క్లస్టర్ యొక్క టోపోలాజీని మారుస్తుంది.
- దీని ప్రకారం, క్లస్టర్ యొక్క స్థితిని నిల్వ చేయడానికి, దాని ప్రస్తుత ప్రాతినిధ్యం, కనిపించే విధంగా, కొంత రకమైన నిల్వ అవసరం. మరియు ఈ దృక్కోణం నుండి, పాత్రోని బాహ్య వ్యవస్థలో స్థితిని నిల్వ చేసే మార్గాన్ని తీసుకున్నాడు. ఇది పంపిణీ చేయబడిన కాన్ఫిగరేషన్ నిల్వ వ్యవస్థ. ఇది Etcd, కాన్సుల్, ZooKeeper లేదా kubernetes Etcd కావచ్చు, అంటే ఈ ఎంపికలలో ఒకటి.
- మరియు Patroni యొక్క లక్షణాలలో ఒకటి మీరు ఆటోఫైలర్‌ను బాక్స్ నుండి బయటకు తీయడం, దాన్ని సెటప్ చేయడం ద్వారా మాత్రమే. మేము పోలిక కోసం Repmgr తీసుకుంటే, ఫైలర్ అక్కడ చేర్చబడుతుంది. Repmgrతో, మనకు స్విచ్‌ఓవర్ వస్తుంది, కానీ మనకు ఆటోఫైలర్ కావాలంటే, మనం దానిని అదనంగా కాన్ఫిగర్ చేయాలి. Patroni ఇప్పటికే బాక్స్ వెలుపల ఆటోఫైలర్‌ని కలిగి ఉంది.
- మరియు అనేక ఇతర విషయాలు ఉన్నాయి. ఉదాహరణకు, కాన్ఫిగరేషన్ల నిర్వహణ, కొత్త ప్రతిరూపాలను పోయడం, బ్యాకప్ మొదలైనవి. కానీ ఇది నివేదిక పరిధికి మించినది, నేను దాని గురించి మాట్లాడను.
మరియు ఒక చిన్న ఫలితం ఏమిటంటే, ప్యాట్రోని యొక్క ప్రధాన పని ఆటోఫైల్‌ను బాగా మరియు విశ్వసనీయంగా చేయడం, తద్వారా మా క్లస్టర్ పనిచేస్తూనే ఉంటుంది మరియు అప్లికేషన్ క్లస్టర్ టోపోలాజీలో మార్పులను గమనించదు.
కానీ మనం Patroniని ఉపయోగించడం ప్రారంభించినప్పుడు, మా సిస్టమ్ కొంచెం క్లిష్టంగా మారుతుంది. ఇంతకు ముందు మనకు Postgres ఉంటే, అప్పుడు Patroniని ఉపయోగిస్తున్నప్పుడు మనం Patroniని పొందుతాము, రాష్ట్రం నిల్వ చేయబడిన DCSని పొందుతాము. మరియు ప్రతిదీ ఏదో ఒకవిధంగా పని చేయాలి. కాబట్టి ఏమి తప్పు కావచ్చు?
విచ్ఛిన్నం కావచ్చు:
- పోస్ట్‌గ్రెస్ విరిగిపోవచ్చు. ఇది మాస్టర్ లేదా ప్రతిరూపం కావచ్చు, వాటిలో ఒకటి విఫలం కావచ్చు.
- పాత్రోని కూడా విరిగిపోవచ్చు.
- రాష్ట్రం నిల్వ చేయబడిన DCS విచ్ఛిన్నం కావచ్చు.
- మరియు నెట్‌వర్క్ విచ్ఛిన్నం కావచ్చు.
ఈ అంశాలన్నీ నేను నివేదికలో పరిశీలిస్తాను.
కేసులు చాలా క్లిష్టంగా మారినందున నేను వాటిని పరిశీలిస్తాను, కేసు అనేక భాగాలను కలిగి ఉంటుంది అనే కోణం నుండి కాదు. మరియు ఆత్మాశ్రయ భావాల కోణం నుండి, ఈ కేసు నాకు కష్టంగా ఉంది, దానిని విడదీయడం కష్టం ... మరియు దీనికి విరుద్ధంగా, కొన్ని కేసు తేలికైనది మరియు దానిని విడదీయడం సులభం.
మరియు మొదటి కేసు చాలా సులభం. మేము డేటాబేస్ క్లస్టర్‌ని తీసుకొని అదే క్లస్టర్‌లో మా DCS నిల్వను అమలు చేసినప్పుడు ఇది జరుగుతుంది. ఇది అత్యంత సాధారణ తప్పు. నిర్మాణాలను నిర్మించడంలో ఇది తప్పు, అంటే, ఒకే చోట వేర్వేరు భాగాలను కలపడం.
కాబట్టి, ఒక ఫైలర్ ఉన్నాడు, ఏమి జరిగిందో పరిష్కరించుకోవడానికి వెళ్దాం.
ఫైలర్ ఎప్పుడు జరిగిందో ఇక్కడ మేము ఆసక్తి కలిగి ఉన్నాము. అంటే, క్లస్టర్ స్థితి మారిన ఈ సమయంలో మేము ఆసక్తి కలిగి ఉన్నాము.
కానీ ఫైలర్ ఎల్లప్పుడూ తక్షణమే కాదు, అంటే దీనికి ఏ యూనిట్ సమయం పట్టదు, ఆలస్యం కావచ్చు. ఇది దీర్ఘకాలం ఉంటుంది.
అందువల్ల, దీనికి ప్రారంభ సమయం మరియు ముగింపు సమయం ఉంది, అనగా ఇది నిరంతర సంఘటన. మరియు మేము అన్ని ఈవెంట్‌లను మూడు విరామాలుగా విభజిస్తాము: ఫైలర్‌కు ముందు, ఫైలర్ సమయంలో మరియు ఫైలర్ తర్వాత మాకు సమయం ఉంటుంది. అంటే, మేము ఈ టైమ్‌లైన్‌లోని అన్ని ఈవెంట్‌లను పరిశీలిస్తాము.
మరియు మొదటి విషయం ఏమిటంటే, ఫైలర్ జరిగినప్పుడు, ఏమి జరిగిందో, ఫైలర్‌కు దారితీసిన దానికి కారణం ఏమిటో మనం వెతుకుతాము.
మనం లాగ్‌లను చూస్తే, అవి క్లాసిక్ పాట్రోని లాగ్‌లుగా ఉంటాయి. సర్వర్ మాస్టర్ అయ్యాడని, మాస్టర్ పాత్ర ఈ నోడ్‌కు చేరిందని అతను వాటిలో మనకు చెప్పాడు. ఇక్కడ అది హైలైట్ చేయబడింది.
తరువాత, ఫైలర్ ఎందుకు జరిగిందో మనం అర్థం చేసుకోవాలి, అనగా ప్రధాన పాత్ర ఒక నోడ్ నుండి మరొకదానికి మారడానికి కారణమైన సంఘటనలు ఏవి జరిగాయి. మరియు ఈ సందర్భంలో, ప్రతిదీ సులభం. నిల్వ సిస్టమ్‌తో పరస్పర చర్య చేయడంలో మాకు లోపం ఉంది. అతను DCSతో పనిచేయలేడని, అంటే పరస్పర చర్యలో కొంత సమస్య ఉందని మాస్టర్ గ్రహించాడు. ఇక తాను మాస్టర్‌గా ఉండలేనని చెప్పి రాజీనామా చేస్తానన్నాడు. ఈ లైన్ “తనను తగ్గించింది” సరిగ్గా అదే చెబుతుంది.
మేము ఫైలర్‌కు ముందు జరిగిన సంఘటనలను పరిశీలిస్తే, విజార్డ్‌ను కొనసాగించడానికి సమస్యకు కారణమైన కారణాలను మనం అక్కడ చూడవచ్చు.
మనం Patroni లాగ్‌లను పరిశీలిస్తే, మనకు చాలా లోపాలు, సమయం ముగిసింది, అంటే Patroni ఏజెంట్ DCSతో పని చేయలేరు. ఈ సందర్భంలో, ఇది పోర్ట్ 8500లో కమ్యూనికేట్ చేస్తున్న కాన్సుల్ ఏజెంట్.
మరియు ఇక్కడ సమస్య ఏమిటంటే Patroni మరియు డేటాబేస్ ఒకే హోస్ట్‌లో రన్ అవుతున్నాయి. మరియు కాన్సుల్ సర్వర్లు అదే నోడ్‌లో ప్రారంభించబడ్డాయి. సర్వర్‌పై లోడ్‌ను సృష్టించడం ద్వారా, మేము కాన్సుల్ సర్వర్‌లకు కూడా సమస్యలను సృష్టించాము. వారు సరిగ్గా కమ్యూనికేట్ చేయలేకపోయారు.
కొంత సమయం తరువాత, భారం తగ్గినప్పుడు, మా పాత్రోని మళ్ళీ ఏజెంట్లతో కమ్యూనికేట్ చేయగలిగాడు. సాధారణ పని తిరిగి ప్రారంభమైంది. మరియు అదే Pgdb-2 సర్వర్ మళ్లీ మాస్టర్‌గా మారింది. అంటే, ఒక చిన్న కుదుపు ఉంది, దీని కారణంగా నోడ్ మాస్టర్ యొక్క అధికారాలను వదులుకుంది, ఆపై వాటిని మళ్లీ స్వాధీనం చేసుకుంది, అంటే, ప్రతిదీ ఉన్నట్లుగా తిరిగి వచ్చింది.
మరియు ఇది తప్పుడు అలారంగా పరిగణించబడుతుంది లేదా పాత్రోని ప్రతిదీ సరిగ్గా చేసినట్లు పరిగణించవచ్చు. అంటే క్లస్టర్ స్థితిని కొనసాగించలేనని గ్రహించి తన అధికారాన్ని తొలగించుకున్నాడు.
మరియు ఇక్కడ కాన్సుల్ సర్వర్లు బేస్‌ల మాదిరిగానే హార్డ్‌వేర్‌లో ఉన్నందున సమస్య తలెత్తింది. దీని ప్రకారం, ఏదైనా లోడ్: ఇది డిస్క్‌లు లేదా ప్రాసెసర్‌లపై లోడ్ అయినా, ఇది కాన్సుల్ క్లస్టర్‌తో పరస్పర చర్యను కూడా ప్రభావితం చేస్తుంది.
మరియు అది కలిసి జీవించకూడదని మేము నిర్ణయించుకున్నాము, మేము కాన్సుల్ కోసం ప్రత్యేక క్లస్టర్‌ను కేటాయించాము. మరియు పాత్రోని అప్పటికే ఒక ప్రత్యేక కాన్సుల్‌తో పని చేస్తున్నాడు, అంటే, ప్రత్యేక పోస్ట్‌గ్రెస్ క్లస్టర్, ప్రత్యేక కాన్సుల్ క్లస్టర్ ఉంది. ఇది కలిసి జీవించకుండా ఉండేందుకు వీటన్నింటిని ఎలా తీసుకువెళ్లాలి మరియు ఉంచాలి అనే ప్రాథమిక సూచన.
ఒక ఎంపికగా, మీరు ttl, loop_wait, retry_timeout అనే పారామితులను ట్విస్ట్ చేయవచ్చు, అనగా ఈ పారామితులను పెంచడం ద్వారా ఈ స్వల్పకాలిక లోడ్ పీక్‌లను తట్టుకోవడానికి ప్రయత్నించండి. కానీ ఇది చాలా సరిఅయిన ఎంపిక కాదు, ఎందుకంటే ఈ లోడ్ చాలా కాలం ఉంటుంది. మరియు మేము ఈ పారామితుల యొక్క ఈ పరిమితులను దాటి వెళ్తాము. మరియు అది నిజంగా సహాయం చేయకపోవచ్చు.
మొదటి సమస్య, మీరు అర్థం చేసుకున్నట్లుగా, చాలా సులభం. మేము తీసుకొని DCS ని బేస్‌తో కలిపి ఉంచాము, మాకు సమస్య వచ్చింది.
రెండవ సమస్య మొదటిదానికి సమానంగా ఉంటుంది. DCS సిస్టమ్‌తో మనకు మళ్లీ ఇంటర్‌ఆపరేబిలిటీ సమస్యలు ఉన్నందున ఇది అదే విధంగా ఉంటుంది.
మేము లాగ్‌లను పరిశీలిస్తే, మనకు మళ్లీ కమ్యూనికేషన్ లోపం ఉన్నట్లు కనిపిస్తుంది. మరియు నేను DCSతో ఇంటరాక్ట్ కాలేను కాబట్టి ప్రస్తుత మాస్టర్ రెప్లికా మోడ్‌లోకి వెళ్తానని పాత్రోని చెప్పారు.
పాత మాస్టర్ ప్రతిరూపంగా మారతాడు, ఇక్కడ పాత్రోని పని చేస్తుంది. ఇది లావాదేవీల లాగ్‌ను రివైండ్ చేయడానికి pg_rewindని అమలు చేస్తుంది మరియు కొత్త మాస్టర్‌ను తెలుసుకోవడానికి కొత్త మాస్టర్‌కి కనెక్ట్ అవుతుంది. ఇక్కడ పాత్రోని అతను తప్పక పని చేస్తాడు.
ఇక్కడ మనం ఫైలర్‌కు ముందు ఉన్న ప్రదేశాన్ని తప్పక కనుగొనాలి, అంటే మనకు ఫైలర్‌ని కలిగి ఉండటానికి కారణమైన లోపాలు. మరియు ఈ విషయంలో, Patroni లాగ్స్ పని చేయడానికి చాలా సౌకర్యవంతంగా ఉంటాయి. అతను ఒక నిర్దిష్ట విరామంలో అదే సందేశాలను వ్రాస్తాడు. మరియు మేము ఈ లాగ్‌ల ద్వారా త్వరగా స్క్రోలింగ్ చేయడం ప్రారంభిస్తే, లాగ్‌లు మారినట్లు లాగ్‌ల నుండి చూస్తాము, అంటే కొన్ని సమస్యలు ప్రారంభమయ్యాయని అర్థం. మేము త్వరగా ఈ స్థలానికి తిరిగి వస్తాము, ఏమి జరుగుతుందో చూడండి.
మరియు సాధారణ పరిస్థితిలో, లాగ్‌లు ఇలాంటివి కనిపిస్తాయి. తాళం యజమాని తనిఖీ చేయబడ్డాడు. మరియు యజమాని, ఉదాహరణకు, మారినట్లయితే, అప్పుడు కొన్ని సంఘటనలు సంభవించవచ్చు, అది పాట్రోని తప్పనిసరిగా ప్రతిస్పందించవలసి ఉంటుంది. అయితే ఈ విషయంలో మేం బాగానే ఉన్నాం. లోపాలు ప్రారంభమైన స్థలం కోసం మేము వెతుకుతున్నాము.
మరియు లోపాలు కనిపించడం ప్రారంభించిన పాయింట్‌కి స్క్రోల్ చేసిన తర్వాత, మనకు ఆటో-ఫైల్‌ఓవర్ ఉందని మేము చూస్తాము. మరియు మా లోపాలు DCSతో పరస్పర చర్యకు సంబంధించినవి కాబట్టి మరియు మా విషయంలో మేము కాన్సుల్‌ని ఉపయోగించాము కాబట్టి, మేము అక్కడ ఏమి జరిగిందో కాన్సుల్ లాగ్‌లను కూడా పరిశీలిస్తాము.
ఫైలర్ యొక్క సమయాన్ని మరియు కాన్సుల్ లాగ్‌లలోని సమయాన్ని పోల్చి చూస్తే, కాన్సుల్ క్లస్టర్‌లోని మా పొరుగువారు కాన్సుల్ క్లస్టర్‌లోని ఇతర సభ్యుల ఉనికిని అనుమానించడం ప్రారంభించినట్లు మేము చూస్తాము.
మరియు మీరు ఇతర కాన్సుల్ ఏజెంట్ల లాగ్‌లను పరిశీలిస్తే, అక్కడ ఒక రకమైన నెట్‌వర్క్ పతనం జరుగుతున్నట్లు కూడా మీరు చూడవచ్చు. మరియు కాన్సుల్ క్లస్టర్‌లోని సభ్యులందరూ ఒకరి ఉనికిని మరొకరు అనుమానిస్తున్నారు. మరియు ఇది ఫైలర్‌కు ప్రేరణ.
ఈ లోపాలకి ముందు ఏమి జరిగిందో మీరు చూస్తే, అన్ని రకాల లోపాలు ఉన్నాయని మీరు చూడవచ్చు, ఉదాహరణకు, గడువు, RPC పడిపోయింది, అంటే, కాన్సుల్ క్లస్టర్ సభ్యుల పరస్పర చర్యలో ఒక రకమైన సమస్య స్పష్టంగా ఉంది. .
నెట్‌వర్క్‌ను రిపేర్ చేయడం సరళమైన సమాధానం. కానీ నాకు, పోడియంపై నిలబడి, ఇది చెప్పడం సులభం. కానీ పరిస్థితులు ఎల్లప్పుడూ వినియోగదారుడు నెట్‌వర్క్‌ను రిపేరు చేయలేరు. అతను DCలో నివసించవచ్చు మరియు నెట్‌వర్క్‌ను రిపేరు చేయలేకపోవచ్చు, పరికరాలను ప్రభావితం చేయవచ్చు. కాబట్టి కొన్ని ఇతర ఎంపికలు అవసరం.
ఎంపికలు ఉన్నాయి:
- నా అభిప్రాయం ప్రకారం, డాక్యుమెంటేషన్లో కూడా వ్రాయబడిన సరళమైన ఎంపిక, కాన్సుల్ తనిఖీలను నిలిపివేయడం, అంటే ఖాళీ శ్రేణిని పాస్ చేయడం. మరియు మేము ఎటువంటి చెక్కులను ఉపయోగించవద్దని కాన్సుల్ ఏజెంట్‌కి చెబుతాము. ఈ తనిఖీలతో, మేము ఈ నెట్‌వర్క్ తుఫానులను విస్మరించవచ్చు మరియు ఫైలర్‌ను ప్రారంభించలేము.
- raft_multiplierని రెండుసార్లు తనిఖీ చేయడం మరొక ఎంపిక. ఇది కాన్సుల్ సర్వర్ యొక్క పరామితి. డిఫాల్ట్‌గా, ఇది 5కి సెట్ చేయబడింది. స్టేజింగ్ ఎన్విరాన్‌మెంట్‌ల కోసం డాక్యుమెంటేషన్ ద్వారా ఈ విలువ సిఫార్సు చేయబడింది. వాస్తవానికి, ఇది కాన్సుల్ నెట్‌వర్క్ సభ్యుల మధ్య సందేశాల ఫ్రీక్వెన్సీని ప్రభావితం చేస్తుంది. వాస్తవానికి, ఈ పరామితి కాన్సుల్ క్లస్టర్ సభ్యుల మధ్య సేవా కమ్యూనికేషన్ వేగాన్ని ప్రభావితం చేస్తుంది. మరియు ఉత్పత్తి కోసం, ఇది ఇప్పటికే తగ్గించడానికి సిఫార్సు చేయబడింది, తద్వారా నోడ్స్ మరింత తరచుగా సందేశాలను మార్పిడి చేస్తాయి.
- ఆపరేటింగ్ సిస్టమ్ యొక్క ప్రాసెస్ షెడ్యూలర్ కోసం ఇతర ప్రక్రియలలో కాన్సుల్ ప్రాసెస్‌ల ప్రాధాన్యతను పెంచడం మేము ముందుకు తెచ్చిన మరొక ఎంపిక. అటువంటి "మంచి" పరామితి ఉంది, ఇది షెడ్యూల్ చేసేటప్పుడు OS షెడ్యూలర్ పరిగణనలోకి తీసుకునే ప్రక్రియల ప్రాధాన్యతను నిర్ణయిస్తుంది. మేము కాన్సుల్ ఏజెంట్లకు మంచి విలువను కూడా తగ్గించాము, అనగా. ప్రాధాన్యతను పెంచింది, తద్వారా ఆపరేటింగ్ సిస్టమ్ కాన్సుల్ ప్రక్రియలకు పని చేయడానికి మరియు వారి కోడ్‌ని అమలు చేయడానికి ఎక్కువ సమయాన్ని ఇస్తుంది. మా విషయంలో, ఇది మా సమస్యను పరిష్కరించింది.
- కాన్సుల్‌ని ఉపయోగించడం మరొక ఎంపిక. నాకు Etcdకి పెద్ద మద్దతు ఇచ్చే స్నేహితుడు ఉన్నాడు. మరియు మేము అతనితో క్రమం తప్పకుండా వాదిస్తాము, ఏది మంచి Etcd లేదా Consul. కానీ ఏది ఉత్తమమో, కాన్సుల్‌కు ఒక ఏజెంట్‌ని కలిగి ఉన్నారని మేము సాధారణంగా అతనితో అంగీకరిస్తాము, అది డేటాబేస్‌తో ప్రతి నోడ్‌లో అమలు చేయబడాలి. అంటే, కాన్సుల్ క్లస్టర్‌తో Patroni యొక్క పరస్పర చర్య ఈ ఏజెంట్ ద్వారా జరుగుతుంది. మరియు ఈ ఏజెంట్ అడ్డంకిగా మారుతుంది. ఏజెంట్‌కు ఏదైనా జరిగితే, అప్పుడు పాత్రోని ఇకపై కాన్సుల్ క్లస్టర్‌తో కలిసి పని చేయలేరు. మరియు ఇది సమస్య. Etcd ప్లాన్‌లో ఏజెంట్ ఎవరూ లేరు. Patroni నేరుగా Etcd సర్వర్‌ల జాబితాతో పని చేయవచ్చు మరియు ఇప్పటికే వారితో కమ్యూనికేట్ చేయవచ్చు. ఈ విషయంలో, మీరు మీ కంపెనీలో Etcdని ఉపయోగిస్తే, కాన్సుల్ కంటే Etcd ఉత్తమ ఎంపిక కావచ్చు. కానీ మా కస్టమర్‌ల వద్ద మేము ఎల్లప్పుడూ క్లయింట్ ఎంచుకున్న మరియు ఉపయోగించే వాటికే పరిమితం అవుతాము. మరియు క్లయింట్‌లందరికీ చాలా వరకు మేము కాన్సుల్‌ని కలిగి ఉన్నాము.
- మరియు చివరి పాయింట్ పరామితి విలువలను సవరించడం. మా స్వల్పకాలిక నెట్‌వర్క్ సమస్యలు తక్కువగా ఉంటాయని మరియు ఈ పారామితుల పరిధి వెలుపల ఉండకూడదనే ఆశతో మేము ఈ పారామితులను పెంచవచ్చు. ఈ విధంగా మనం కొన్ని నెట్‌వర్క్ సమస్యలు ఏర్పడితే ఆటోఫైల్ చేయడానికి Patroni యొక్క దూకుడును తగ్గించవచ్చు.
Patroniని ఉపయోగించే చాలా మందికి ఈ ఆదేశం గురించి బాగా తెలుసు.
ఈ ఆదేశం క్లస్టర్ యొక్క ప్రస్తుత స్థితిని చూపుతుంది. మరియు మొదటి చూపులో, ఈ చిత్రం సాధారణమైనదిగా అనిపించవచ్చు. మాకు మాస్టర్ ఉన్నారు, మాకు ప్రతిరూపం ఉంది, ప్రతిరూపణ లాగ్ లేదు. అయితే ఈ క్లస్టర్‌లో రెండు కాదు మూడు నోడ్‌లు ఉండాలని మనకు తెలిసే వరకు ఈ చిత్రం సాధారణమైనది.
దాని ప్రకారం, ఒక ఆటోఫైల్ ఉంది. మరియు ఈ ఆటోఫైల్ తర్వాత, మా ప్రతిరూపం అదృశ్యమైంది. ఆమె ఎందుకు అదృశ్యమైందో మనం కనుగొని, ఆమెను తిరిగి తీసుకురావాలి, పునరుద్ధరించాలి. మరియు మేము మళ్లీ లాగ్‌లకు వెళ్లి, మనకు ఆటో-ఫైల్‌ఓవర్ ఎందుకు ఉందో చూద్దాం.
ఈ సందర్భంలో, రెండవ ప్రతిరూపం మాస్టర్ అయ్యింది. ఇక్కడ అంతా బాగానే ఉంది.
మరియు మేము పడిపోయిన మరియు క్లస్టర్‌లో లేని ప్రతిరూపాన్ని చూడాలి. మేము Patroni లాగ్‌లను తెరిచి, pg_rewind దశలో క్లస్టర్‌కి కనెక్ట్ చేసే ప్రక్రియలో మాకు సమస్య ఉందని చూస్తాము. క్లస్టర్‌కి కనెక్ట్ చేయడానికి, మీరు లావాదేవీల లాగ్‌ను రివైండ్ చేయాలి, మాస్టర్ నుండి అవసరమైన లావాదేవీల లాగ్‌ను అభ్యర్థించాలి మరియు మాస్టర్‌ను కలుసుకోవడానికి దాన్ని ఉపయోగించాలి.
ఈ సందర్భంలో, మా వద్ద లావాదేవీ లాగ్ లేదు మరియు ప్రతిరూపం ప్రారంభించబడదు. దీని ప్రకారం, మేము పోస్ట్‌గ్రెస్‌ను లోపంతో ఆపివేస్తాము. అందువలన ఇది క్లస్టర్‌లో లేదు.
ఇది క్లస్టర్‌లో ఎందుకు లేదు మరియు ఎందుకు లాగ్‌లు లేవని మనం అర్థం చేసుకోవాలి. మేము కొత్త మాస్టర్ వద్దకు వెళ్లి, అతను లాగ్లలో ఏమి ఉందో చూస్తాము. pg_rewind చేసినప్పుడు, చెక్‌పాయింట్ సంభవించిందని తేలింది. మరియు కొన్ని పాత లావాదేవీల లాగ్‌లు కేవలం పేరు మార్చబడ్డాయి. పాత మాస్టర్ కొత్త మాస్టర్‌కి కనెక్ట్ చేసి, ఈ లాగ్‌లను ప్రశ్నించడానికి ప్రయత్నించినప్పుడు, అవి ఇప్పటికే పేరు మార్చబడ్డాయి, అవి ఉనికిలో లేవు.
ఈ సంఘటనలు జరిగినప్పుడు నేను టైమ్‌స్టాంప్‌లను పోల్చాను. మరియు అక్కడ తేడా అక్షరాలా 150 మిల్లీసెకన్లు, అంటే, చెక్‌పాయింట్ 369 మిల్లీసెకన్లలో పూర్తయింది, WAL విభాగాలు పేరు మార్చబడ్డాయి. మరియు అక్షరాలా 517లో, 150 మిల్లీసెకన్ల తర్వాత, పాత ప్రతిరూపంపై రివైండ్ చేయడం ప్రారంభమైంది. అంటే, అక్షరాలా 150 మిల్లీసెకన్లు మాకు సరిపోతాయి, తద్వారా ప్రతిరూపం కనెక్ట్ చేయబడదు మరియు సంపాదించలేదు.
ఎంపికలు ఏమిటి?
మేము మొదట రెప్లికేషన్ స్లాట్‌లను ఉపయోగించాము. బాగుందని అనుకున్నాం. ఆపరేషన్ యొక్క మొదటి దశలో మేము స్లాట్‌లను ఆపివేసినప్పటికీ. స్లాట్లు చాలా WAL సెగ్మెంట్‌లను కూడబెట్టుకుంటే, మేము మాస్టర్‌ను డ్రాప్ చేయవచ్చు అని మాకు అనిపించింది. అతను పడిపోతాడు. స్లాట్లు లేకుండా కొంత కాలం బాధపడ్డాం. మరియు మాకు స్లాట్లు అవసరమని మేము గ్రహించాము, మేము స్లాట్‌లను తిరిగి ఇచ్చాము.
కానీ ఇక్కడ ఒక సమస్య ఉంది, మాస్టర్ ప్రతిరూపానికి వెళ్ళినప్పుడు, అది స్లాట్‌లను తొలగిస్తుంది మరియు స్లాట్‌లతో పాటు WAL విభాగాలను తొలగిస్తుంది. మరియు ఈ సమస్యను తొలగించడానికి, మేము wal_keep_segments పరామితిని పెంచాలని నిర్ణయించుకున్నాము. ఇది 8 విభాగాలకు డిఫాల్ట్ అవుతుంది. మేము దానిని 1కి పెంచాము మరియు మాకు ఎంత ఖాళీ స్థలం ఉందో పరిశీలించాము. మరియు మేము వాల్_కీప్_సెగ్మెంట్ల కోసం 000 గిగాబైట్‌లను విరాళంగా అందించాము. అంటే, మారుతున్నప్పుడు, మేము ఎల్లప్పుడూ అన్ని నోడ్‌లలో 16 గిగాబైట్ల లావాదేవీ లాగ్‌ల రిజర్వ్‌ను కలిగి ఉంటాము.
మరియు ప్లస్ - ఇది ఇప్పటికీ దీర్ఘకాలిక నిర్వహణ పనులకు సంబంధించినది. ప్రతిరూపాలలో ఒకదానిని మనం అప్‌డేట్ చేయాలి అనుకుందాం. మరియు మేము దానిని ఆఫ్ చేయాలనుకుంటున్నాము. మేము సాఫ్ట్‌వేర్‌ను నవీకరించాలి, బహుశా ఆపరేటింగ్ సిస్టమ్, మరేదైనా కావచ్చు. మరియు మనం ప్రతిరూపాన్ని ఆఫ్ చేసినప్పుడు, ఆ ప్రతిరూపానికి సంబంధించిన స్లాట్ కూడా తీసివేయబడుతుంది. మరియు మేము చిన్న wal_keep_segmentsని ఉపయోగిస్తే, ఎక్కువ కాలం ప్రతిరూపం లేకపోవడంతో, లావాదేవీ లాగ్‌లు పోతాయి. మేము ప్రతిరూపాన్ని లేవనెత్తుతాము, అది ఎక్కడ ఆగిపోయిందో ఆ లావాదేవీ లాగ్‌లను అభ్యర్థిస్తుంది, కానీ అవి మాస్టర్‌లో ఉండకపోవచ్చు. మరియు ప్రతిరూపం కూడా కనెక్ట్ చేయలేరు. అందువల్ల, మేము మ్యాగజైన్‌ల పెద్ద స్టాక్‌ను ఉంచుతాము.
మాకు ప్రొడక్షన్ బేస్ ఉంది. ఇప్పటికే ప్రాజెక్టులు పురోగతిలో ఉన్నాయి.
ఒక ఫైలర్ ఉన్నాడు. మేము లోపలికి వెళ్లి చూసాము - ప్రతిదీ క్రమంలో ఉంది, ప్రతిరూపాలు స్థానంలో ఉన్నాయి, ప్రతిరూపణ లాగ్ లేదు. లాగ్లలో కూడా లోపాలు లేవు, ప్రతిదీ క్రమంలో ఉంది.
కొంత డేటా ఉండాలని ఉత్పత్తి బృందం చెబుతోంది, కానీ మేము దానిని ఒక మూలం నుండి చూస్తాము, కానీ మేము దానిని డేటాబేస్లో చూడలేము. మరి వారికి ఏం జరిగిందో అర్థం చేసుకోవాలి.
వాటిని pg_rewind కోల్పోయిందని స్పష్టమైంది. మేము ఈ విషయాన్ని వెంటనే అర్థం చేసుకున్నాము, కాని ఏమి జరుగుతుందో చూడటానికి వెళ్ళాము.
లాగ్లలో, ఫైలర్ ఎప్పుడు జరిగిందో, ఎవరు మాస్టర్ అయ్యారో మనం ఎల్లప్పుడూ కనుగొనవచ్చు మరియు పాత మాస్టర్ ఎవరు మరియు అతను ఎప్పుడు ప్రతిరూపంగా మారాలనుకుంటున్నారో మనం గుర్తించగలము, అనగా లావాదేవీల లాగ్‌ల మొత్తాన్ని తెలుసుకోవడానికి మనకు ఈ లాగ్‌లు అవసరం. పోయింది.
మా పాత మాస్టర్ రీబూట్ చేసారు. మరియు పాత్రోని ఆటోరన్‌లో నమోదు చేయబడింది. పాత్రోనిని ప్రారంభించారు. ఆ తర్వాత పోస్ట్‌గ్రెస్‌ను ప్రారంభించాడు. మరింత ఖచ్చితంగా, పోస్ట్‌గ్రెస్‌ని ప్రారంభించే ముందు మరియు దానిని ప్రతిరూపంగా మార్చే ముందు, Patroni pg_rewind ప్రక్రియను ప్రారంభించింది. తదనుగుణంగా, అతను లావాదేవీల లాగ్లలో కొంత భాగాన్ని చెరిపివేసి, కొత్త వాటిని డౌన్‌లోడ్ చేసి కనెక్ట్ చేశాడు. ఇక్కడ పాత్రోని తెలివిగా, అంటే, ఊహించిన విధంగా పనిచేశాడు. క్లస్టర్ పునరుద్ధరించబడింది. మాకు 3 నోడ్‌లు ఉన్నాయి, ఫైలర్ 3 నోడ్‌ల తర్వాత - ప్రతిదీ బాగుంది.
మేము కొంత డేటాను కోల్పోయాము. మరి మనం ఎంత నష్టపోయామో అర్థం చేసుకోవాలి. మేము రివైండ్ చేసిన క్షణం కోసం చూస్తున్నాము. అటువంటి జర్నల్ ఎంట్రీలలో మనం దానిని కనుగొనవచ్చు. రివైండ్ స్టార్ట్ చేసి, అక్కడ ఏదో చేసి ముగించారు.
లావాదేవీ లాగ్‌లో పాత మాస్టర్ వదిలిపెట్టిన స్థానాన్ని మనం కనుగొనాలి. ఈ సందర్భంలో, ఇది గుర్తు. మరియు మనకు రెండవ గుర్తు అవసరం, అనగా పాత మాస్టర్ కొత్తదాని నుండి భిన్నంగా ఉండే దూరం.
మేము సాధారణ pg_wal_lsn_diff తీసుకొని ఈ రెండు మార్కులను సరిపోల్చండి. మరియు ఈ సందర్భంలో, మేము 17 మెగాబైట్లను పొందుతాము. చాలా లేదా కొంచెం, ప్రతి ఒక్కరూ తనకు తానుగా నిర్ణయిస్తారు. ఎందుకంటే ఎవరికైనా 17 మెగాబైట్లు ఎక్కువ కాదు, ఎవరికైనా ఇది చాలా మరియు ఆమోదయోగ్యం కాదు. ఇక్కడ, ప్రతి వ్యక్తి వ్యాపారం యొక్క అవసరాలకు అనుగుణంగా తనను తాను నిర్ణయిస్తాడు.
కానీ మన కోసం మనం ఏమి కనుగొన్నాము?
ముందుగా, మనమే నిర్ణయించుకోవాలి - సిస్టమ్ రీబూట్ అయిన తర్వాత ఆటోస్టార్ట్ చేయడానికి మనకు ఎల్లప్పుడూ Patroni అవసరమా? మేము పాత మాస్టర్ వద్దకు వెళ్లాలని తరచుగా జరుగుతుంది, అతను ఎంత దూరం వెళ్ళాడో చూడండి. బహుశా లావాదేవీ లాగ్ యొక్క విభాగాలను తనిఖీ చేయండి, అక్కడ ఏమి ఉందో చూడండి. మరియు మనం ఈ డేటాను కోల్పోవచ్చా లేదా ఈ డేటాను బయటకు తీయడానికి పాత మాస్టర్‌ను స్వతంత్ర మోడ్‌లో అమలు చేయాలా అని అర్థం చేసుకోవడానికి.
మరియు ఆ తర్వాత మాత్రమే మనం ఈ డేటాను విస్మరించవచ్చా లేదా దాన్ని పునరుద్ధరించగలమా అని నిర్ణయించుకోవాలి, ఈ నోడ్‌ని మా క్లస్టర్‌కి ప్రతిరూపంగా కనెక్ట్ చేయండి.
అదనంగా, "maximum_lag_on_failover" పరామితి ఉంది. డిఫాల్ట్‌గా, నా మెమరీ నాకు సేవ చేస్తే, ఈ పరామితి 1 మెగాబైట్ విలువను కలిగి ఉంటుంది.
అతను ఎలా పని చేస్తాడు? రెప్లికేషన్ లాగ్‌లో మా ప్రతిరూపం 1 మెగాబైట్ డేటా వెనుకబడి ఉంటే, ఈ ప్రతిరూపం ఎన్నికల్లో పాల్గొనదు. మరియు అకస్మాత్తుగా ఫైల్‌ఓవర్ ఉంటే, పాత్రోని ఏ ప్రతిరూపాలు వెనుకబడి ఉన్నాయో చూస్తాడు. వారు పెద్ద సంఖ్యలో లావాదేవీల లాగ్‌ల ద్వారా వెనుకబడి ఉంటే, వారు మాస్టర్‌గా మారలేరు. ఇది చాలా మంచి భద్రతా ఫీచర్, ఇది చాలా డేటాను కోల్పోకుండా మిమ్మల్ని నిరోధిస్తుంది.
కానీ పాట్రోని క్లస్టర్ మరియు DCSలో రెప్లికేషన్ లాగ్ నిర్దిష్ట వ్యవధిలో నవీకరించబడటంలో సమస్య ఉంది. 30 సెకన్లు డిఫాల్ట్ ttl విలువ అని నేను అనుకుంటున్నాను.
దీని ప్రకారం, DCSలో ప్రతిరూపాల కోసం ఒక రెప్లికేషన్ లాగ్ ఉన్న పరిస్థితి ఉండవచ్చు, కానీ వాస్తవానికి పూర్తిగా భిన్నమైన లాగ్ ఉండవచ్చు లేదా లాగ్ అస్సలు ఉండకపోవచ్చు, అంటే ఈ విషయం నిజ సమయంలో కాదు. మరియు ఇది ఎల్లప్పుడూ నిజమైన చిత్రాన్ని ప్రతిబింబించదు. మరియు దానిపై ఫాన్సీ లాజిక్ చేయడం విలువైనది కాదు.
మరియు నష్టం ప్రమాదం ఎల్లప్పుడూ ఉంటుంది. మరియు చెత్త సందర్భంలో ఒక సూత్రం, మరియు సగటు సందర్భంలో మరొక సూత్రం. అంటే, మేము Patroni యొక్క అమలును ప్లాన్ చేసినప్పుడు మరియు మనం ఎంత డేటాను కోల్పోవచ్చో అంచనా వేసినప్పుడు, మనం ఈ సూత్రాలపై ఆధారపడాలి మరియు మనం ఎంత డేటాను కోల్పోతామో స్థూలంగా ఊహించుకోవాలి.
మరియు శుభవార్త ఉంది. పాత మాస్టర్ ముందుకు వెళ్ళినప్పుడు, అతను కొన్ని నేపథ్య ప్రక్రియల కారణంగా ముందుకు వెళ్ళవచ్చు. అంటే, ఒక రకమైన ఆటోవాక్యూమ్ ఉంది, అతను డేటాను వ్రాసాడు, వాటిని లావాదేవీల లాగ్‌లో సేవ్ చేశాడు. మరియు మేము ఈ డేటాను సులభంగా విస్మరించవచ్చు మరియు కోల్పోవచ్చు. ఇందులో ఎలాంటి సమస్య లేదు.
గరిష్ట_lag_on_failover సెట్ చేయబడి, ఫైలర్ సంభవించినట్లయితే, లాగ్‌లు ఇలా కనిపిస్తాయి మరియు మీరు కొత్త మాస్టర్‌ని ఎంచుకోవాలి. ప్రతిరూపం తనను తాను ఎన్నికల్లో పాల్గొనే సామర్థ్యం లేదని అంచనా వేసింది. మరియు ఆమె నాయకుడి రేసులో పాల్గొనడానికి నిరాకరిస్తుంది. మరియు ఆమె కొత్త మాస్టర్ ఎంపిక కోసం వేచి ఉంది, తద్వారా ఆమె దానికి కనెక్ట్ అవుతుంది. ఇది డేటా నష్టానికి వ్యతిరేకంగా అదనపు కొలత.
పోస్ట్‌గ్రెస్‌తో తమ ఉత్పత్తికి సమస్యలు ఉన్నాయని వ్రాసిన ఉత్పత్తి బృందం ఇక్కడ ఉంది. అదే సమయంలో, మాస్టర్ కూడా యాక్సెస్ చేయబడదు, ఎందుకంటే ఇది SSH ద్వారా అందుబాటులో లేదు. మరియు ఆటోఫైల్ కూడా జరగదు.
ఈ హోస్ట్ రీబూట్ చేయవలసి వచ్చింది. రీబూట్ కారణంగా, నేను ఇప్పుడు అర్థం చేసుకున్నట్లుగా, మాన్యువల్ ఆటో-ఫైల్ చేయడం సాధ్యమైనప్పటికీ, ఆటో-ఫైల్ జరిగింది. మరియు రీబూట్ చేసిన తర్వాత, ప్రస్తుత మాస్టర్‌తో మనకు ఏమి ఉందో మనం ఇప్పటికే చూడబోతున్నాం.
అదే సమయంలో, మాకు డిస్కులతో సమస్యలు ఉన్నాయని మాకు ముందుగానే తెలుసు, అంటే, ఎక్కడ త్రవ్వాలి మరియు ఏమి చూడాలి అనేదానిని పర్యవేక్షించడం నుండి మాకు ఇప్పటికే తెలుసు.
మేము పోస్ట్‌గ్రెస్ లాగ్‌లోకి ప్రవేశించాము, అక్కడ ఏమి జరుగుతుందో చూడటం ప్రారంభించాము. ఒకటి, రెండు, మూడు సెకన్ల పాటు జరిగే కమిట్‌లను మేము చూశాము, ఇది సాధారణమైనది కాదు. మా ఆటోవాక్యూమ్ చాలా నెమ్మదిగా మరియు వింతగా ప్రారంభమవుతుందని మేము చూశాము. మరియు మేము డిస్క్‌లో తాత్కాలిక ఫైల్‌లను చూశాము. అంటే, ఇవన్నీ డిస్కులతో సమస్యలకు సూచికలు.
మేము సిస్టమ్ dmesg (కెర్నల్ లాగ్) లోకి చూసాము. మరియు డిస్క్‌లలో ఒకదానితో మాకు సమస్యలు ఉన్నాయని మేము చూశాము. డిస్క్ సబ్‌సిస్టమ్ సాఫ్ట్‌వేర్ రైడ్. మేము /proc/mdstatని చూసాము మరియు మేము ఒక డ్రైవ్‌ను కోల్పోయినట్లు చూసాము. అంటే, 8 డిస్క్‌ల రైడ్ ఉంది, మేము ఒకదాన్ని కోల్పోతున్నాము. మీరు స్లయిడ్‌ను జాగ్రత్తగా పరిశీలిస్తే, అవుట్‌పుట్‌లో మనకు అక్కడ sde లేదని మీరు చూడవచ్చు. మా వద్ద, షరతులతో మాట్లాడుతూ, డిస్క్ పడిపోయింది. ఇది డిస్క్ సమస్యలను ప్రేరేపించింది మరియు పోస్ట్‌గ్రెస్ క్లస్టర్‌తో పని చేస్తున్నప్పుడు అప్లికేషన్‌లు కూడా సమస్యలను ఎదుర్కొంటాయి.
మరియు ఈ సందర్భంలో, Patroni మాకు ఏ విధంగానూ సహాయం చేయదు, ఎందుకంటే సర్వర్ యొక్క స్థితిని, డిస్క్ యొక్క స్థితిని పర్యవేక్షించే పని Patroniకి లేదు. మరియు మేము బాహ్య పర్యవేక్షణ ద్వారా అటువంటి పరిస్థితులను పర్యవేక్షించాలి. మేము డిస్క్ పర్యవేక్షణను బాహ్య పర్యవేక్షణకు త్వరగా జోడించాము.
మరియు అలాంటి ఆలోచన ఉంది - ఫెన్సింగ్ లేదా వాచ్‌డాగ్ సాఫ్ట్‌వేర్ మాకు సహాయం చేయగలదా? ఈ విషయంలో అతను మాకు సహాయం చేయలేడని మేము అనుకున్నాము, ఎందుకంటే సమస్యల సమయంలో పాత్రోని DCS క్లస్టర్‌తో పరస్పర చర్య కొనసాగించారు మరియు ఏ సమస్యనూ చూడలేదు. అంటే, DCS మరియు Patroni యొక్క దృక్కోణం నుండి, క్లస్టర్‌తో ప్రతిదీ బాగానే ఉంది, వాస్తవానికి డిస్క్‌తో సమస్యలు ఉన్నప్పటికీ, డేటాబేస్ లభ్యతతో సమస్యలు ఉన్నాయి.
నా అభిప్రాయం ప్రకారం, నేను చాలా కాలం పాటు పరిశోధించిన విచిత్రమైన సమస్యలలో ఇది ఒకటి, నేను చాలా లాగ్‌లను చదివాను, తిరిగి ఎంచుకున్నాను మరియు దానిని క్లస్టర్ సిమ్యులేటర్ అని పిలిచాను.
సమస్య ఏమిటంటే, పాత మాస్టర్ సాధారణ ప్రతిరూపంగా మారలేడు, అంటే పాత్రోని దీన్ని ప్రారంభించాడు, ఈ నోడ్ ప్రతిరూపంగా ఉందని పాత్రోని చూపించాడు, కానీ అదే సమయంలో ఇది సాధారణ ప్రతిరూపం కాదు. ఇప్పుడు మీరు ఎందుకు చూస్తారు. ఆ సమస్య యొక్క విశ్లేషణ నుండి నేను ఉంచినది ఇదే.
మరి ఇదంతా ఎలా మొదలైంది? ఇది మునుపటి సమస్యలో వలె, డిస్క్ బ్రేక్‌లతో ప్రారంభమైంది. మేము రెండవ, రెండు కోసం కమిట్‌లను కలిగి ఉన్నాము.
కనెక్షన్లలో విరామాలు ఉన్నాయి, అంటే, క్లయింట్లు నలిగిపోయాయి.
వివిధ తీవ్రత యొక్క అడ్డంకులు ఉన్నాయి.
మరియు, తదనుగుణంగా, డిస్క్ ఉపవ్యవస్థ చాలా ప్రతిస్పందించదు.
మరియు నాకు అత్యంత రహస్యమైన విషయం ఏమిటంటే, వచ్చిన తక్షణ షట్డౌన్ అభ్యర్థన. పోస్ట్‌గ్రెస్‌లో మూడు షట్డౌన్ మోడ్‌లు ఉన్నాయి:
- క్లయింట్‌లందరూ వారి స్వంతంగా డిస్‌కనెక్ట్ అయ్యే వరకు మేము వేచి ఉన్నప్పుడు ఇది మనోహరంగా ఉంటుంది.
- మేము షట్డౌన్ చేయబోతున్నందున క్లయింట్‌లను డిస్‌కనెక్ట్ చేయమని బలవంతం చేసినప్పుడు వేగంగా ఉంటుంది.
- మరియు వెంటనే. ఈ సందర్భంలో, తక్షణం షట్ డౌన్ చేయమని క్లయింట్‌లను కూడా చెప్పదు, ఇది హెచ్చరిక లేకుండా మూసివేయబడుతుంది. మరియు అన్ని క్లయింట్‌లకు, ఆపరేటింగ్ సిస్టమ్ ఇప్పటికే RST సందేశాన్ని పంపుతుంది (కనెక్షన్ అంతరాయం కలిగిందని మరియు క్లయింట్‌కు పట్టుకోవడానికి ఇంకేమీ లేదని TCP సందేశం).
ఈ సంకేతాన్ని ఎవరు పంపారు? Postgres నేపథ్య ప్రక్రియలు అటువంటి సంకేతాలను ఒకదానికొకటి పంపవు, అనగా ఇది కిల్-9. వారు అలాంటి విషయాలను ఒకరికొకరు పంపరు, వారు అలాంటి వాటికి మాత్రమే ప్రతిస్పందిస్తారు, అనగా ఇది పోస్ట్‌గ్రెస్ యొక్క అత్యవసర పునఃప్రారంభం. ఎవరు పంపారు, నాకు తెలియదు.
నేను "చివరి" కమాండ్‌ని చూశాను మరియు మాతో పాటు ఈ సర్వర్‌లో లాగిన్ అయిన ఒక వ్యక్తిని నేను చూశాను, కానీ నేను ప్రశ్న అడగడానికి చాలా సిగ్గుపడ్డాను. బహుశా అది హత్య -9. నేను లాగ్లలో కిల్ -9ని చూస్తాను, ఎందుకంటే పోస్ట్‌గ్రెస్ ఇది కిల్ -9 పట్టిందని చెప్పారు, కానీ నేను దానిని లాగ్లలో చూడలేదు.
ఇంకా చూస్తే, పాత్రోని లాగ్‌కి చాలా కాలంగా వ్రాయలేదని నేను చూశాను - 54 సెకన్లు. మరియు మేము రెండు టైమ్‌స్టాంప్‌లను పోల్చినట్లయితే, దాదాపు 54 సెకన్ల వరకు సందేశాలు లేవు.
మరియు ఈ సమయంలో ఒక ఆటోఫైల్ ఉంది. పాత్రోని మళ్లీ ఇక్కడ గొప్ప పని చేశాడు. మా పాత మాస్టర్ అందుబాటులో లేరు, అతనికి ఏదో జరిగింది. మరియు కొత్త మాస్టర్ ఎన్నిక ప్రారంభమైంది. ఇక్కడ ప్రతిదీ బాగా పనిచేసింది. మా pgsql01 కొత్త నాయకుడిగా మారింది.
మాస్టర్‌గా మారిన ప్రతిరూపం మాకు ఉంది. మరియు రెండవ ప్రతిస్పందన ఉంది. మరియు రెండవ ప్రతిరూపంతో సమస్యలు ఉన్నాయి. ఆమె రీకాన్ఫిగర్ చేయడానికి ప్రయత్నించింది. నేను అర్థం చేసుకున్నట్లుగా, ఆమె recovery.confని మార్చడానికి ప్రయత్నించింది, పోస్ట్‌గ్రెస్‌ని పునఃప్రారంభించి కొత్త మాస్టర్‌కి కనెక్ట్ చేయబడింది. ఆమె ప్రయత్నిస్తున్న ప్రతి 10 సెకన్లకు సందేశాలు వ్రాస్తారు, కానీ ఆమె విజయవంతం కాలేదు.
మరియు ఈ ప్రయత్నాల సమయంలో, తక్షణ-షట్డౌన్ సిగ్నల్ పాత మాస్టర్ వద్దకు వస్తుంది. మాస్టర్ పునఃప్రారంభించబడింది. పాత మాస్టర్ రీబూట్‌లోకి వెళ్లినందున రికవరీ కూడా ఆగిపోతుంది. అంటే, ప్రతిరూపం దానికి కనెక్ట్ చేయబడదు, ఎందుకంటే ఇది షట్డౌన్ మోడ్‌లో ఉంది.
ఏదో ఒక సమయంలో, ఇది పనిచేసింది, కానీ ప్రతిరూపణ ప్రారంభం కాలేదు.
Recovery.confలో పాత మాస్టర్ అడ్రస్ ఉందని నా అంచనా. మరియు కొత్త మాస్టర్ కనిపించినప్పుడు, రెండవ ప్రతిరూపం ఇప్పటికీ పాత మాస్టర్‌కు కనెక్ట్ చేయడానికి ప్రయత్నించింది.
పాత్రోని రెండవ ప్రతిరూపంపై ప్రారంభించినప్పుడు, నోడ్ ప్రారంభించబడింది కానీ ప్రతిరూపం కాలేదు. మరియు ప్రతిరూపణ లాగ్ ఏర్పడింది, ఇది ఇలా కనిపిస్తుంది. అంటే, మూడు నోడ్‌లు స్థానంలో ఉన్నాయి, కానీ రెండవ నోడ్ వెనుకబడి ఉంది.
అదే సమయంలో, మీరు వ్రాసిన లాగ్‌లను చూస్తే, లావాదేవీ లాగ్‌లు భిన్నంగా ఉన్నందున ప్రతిరూపణ ప్రారంభించబడలేదని మీరు చూడవచ్చు. మరియు recovery.confలో పేర్కొన్న మాస్టర్ అందించే లావాదేవీ లాగ్‌లు మా ప్రస్తుత నోడ్‌కు సరిపోవు.
మరియు ఇక్కడ నేను తప్పు చేసాను. మేము తప్పు మాస్టర్‌కి కనెక్ట్ అవుతున్నామని నా పరికల్పనను పరీక్షించడానికి నేను వచ్చి, recovery.confలో ఏమి ఉందో చూడవలసి వచ్చింది. కానీ అప్పుడు నేను దీనితో వ్యవహరిస్తున్నాను మరియు అది నాకు సంభవించలేదు, లేదా ప్రతిరూపం వెనుకబడి ఉందని మరియు రీఫిల్ చేయవలసి ఉంటుందని నేను చూశాను, అంటే, నేను ఏదో ఒకవిధంగా నిర్లక్ష్యంగా పనిచేశాను. ఇది నా ఉమ్మడి.
30 నిమిషాల తర్వాత, నిర్వాహకుడు అప్పటికే వచ్చారు, అనగా నేను ప్రతిరూపంలో పాత్రోనిని పునఃప్రారంభించాను. నేను ఇప్పటికే దాన్ని ముగించాను, దాన్ని రీఫిల్ చేయవలసి ఉంటుందని నేను అనుకున్నాను. మరియు నేను అనుకున్నాను - నేను పాత్రోనిని పునఃప్రారంభిస్తాను, బహుశా ఏదైనా మంచిగా మారుతుంది. రికవరీ ప్రారంభమైంది. మరియు బేస్ కూడా తెరవబడింది, ఇది కనెక్షన్లను అంగీకరించడానికి సిద్ధంగా ఉంది.
ప్రతిరూపం ప్రారంభమైంది. కానీ ఒక నిమిషం తర్వాత, లావాదేవీ లాగ్‌లు తనకు సరిపోవనే లోపంతో ఆమె పడిపోయింది.
నేను మళ్లీ రీస్టార్ట్ చేయాలని అనుకున్నాను. నేను Patroniని మళ్లీ పునఃప్రారంభించాను మరియు నేను Postgresని పునఃప్రారంభించలేదు, కానీ అది డేటాబేస్‌ను అద్భుతంగా ప్రారంభిస్తుందనే ఆశతో Patroniని పునఃప్రారంభించాను.
ప్రతిరూపణ మళ్లీ ప్రారంభమైంది, కానీ లావాదేవీ లాగ్‌లోని మార్కులు భిన్నంగా ఉన్నాయి, అవి మునుపటి ప్రారంభ ప్రయత్నం వలె లేవు. ప్రతిరూపణ మళ్లీ ఆగిపోయింది. మరియు సందేశం ఇప్పటికే కొద్దిగా భిన్నంగా ఉంది. మరియు ఇది నాకు చాలా సమాచారంగా లేదు.
ఆపై అది నాకు సంభవిస్తుంది - నేను పోస్ట్‌గ్రెస్‌ను పునఃప్రారంభిస్తే, ఈ సమయంలో నేను లావాదేవీ లాగ్‌లోని పాయింట్‌ను కొద్దిగా ముందుకు తరలించడానికి ప్రస్తుత మాస్టర్‌పై చెక్‌పాయింట్‌ను తయారు చేస్తే రికవరీ మరొక క్షణం నుండి ప్రారంభమవుతుంది? అదనంగా, మా వద్ద ఇప్పటికీ WAL స్టాక్‌లు ఉన్నాయి.
నేను పాత్రోనిని పునఃప్రారంభించాను, మాస్టర్‌పై రెండు చెక్‌పాయింట్లు చేసాను, ప్రతిరూపం తెరిచినప్పుడు దానిపై రెండు రీస్టార్ట్ పాయింట్‌లు చేసాను. మరియు అది సహాయపడింది. ఇది ఎందుకు సహాయపడింది మరియు ఎలా పని చేస్తుందో నేను చాలా సేపు ఆలోచించాను. మరియు ప్రతిరూపం ప్రారంభమైంది. మరియు ప్రతిరూపం ఇకపై నలిగిపోలేదు.
నాకు అలాంటి సమస్య చాలా రహస్యమైన వాటిలో ఒకటి, దాని గురించి నేను ఇప్పటికీ అక్కడ నిజంగా ఏమి జరిగిందనే దానిపై పజిల్ చేస్తున్నాను.
ఇక్కడ చిక్కులు ఏమిటి? Patroni ఉద్దేశించిన మరియు ఏ లోపాలు లేకుండా పని చేయవచ్చు. కానీ అదే సమయంలో, ఇది మాతో ప్రతిదీ బాగానే ఉందని 100% హామీ కాదు. ప్రతిరూపం ప్రారంభం కావచ్చు, కానీ అది సెమీ-వర్కింగ్ స్టేట్‌లో ఉండవచ్చు మరియు అప్లికేషన్ అటువంటి ప్రతిరూపంతో పని చేయదు, ఎందుకంటే పాత డేటా ఉంటుంది.
మరియు ఫైలర్ తర్వాత, మీరు ఎల్లప్పుడూ క్లస్టర్‌తో ప్రతిదీ సరిగ్గా ఉందో లేదో తనిఖీ చేయాలి, అనగా, అవసరమైన ప్రతిరూపాల సంఖ్య ఉంది, ప్రతిరూపణ లాగ్ లేదు.
మరియు మేము ఈ సమస్యల ద్వారా వెళుతున్నప్పుడు, నేను సిఫార్సులు చేస్తాను. నేను వాటిని రెండు స్లయిడ్‌లుగా కలపడానికి ప్రయత్నించాను. బహుశా, అన్ని కథలను రెండు స్లైడ్‌లుగా కలిపి మాత్రమే చెప్పవచ్చు.
మీరు Patroniని ఉపయోగించినప్పుడు, మీరు తప్పనిసరిగా పర్యవేక్షణ కలిగి ఉండాలి. ఆటోఫైల్‌ఓవర్ ఎప్పుడు జరిగిందో మీరు ఎల్లప్పుడూ తెలుసుకోవాలి, ఎందుకంటే మీకు ఆటోఫైల్‌ఓవర్ ఉందని మీకు తెలియకపోతే, క్లస్టర్‌పై మీకు నియంత్రణ ఉండదు. మరియు అది చెడ్డది.
ప్రతి ఫైలర్ తర్వాత, మేము ఎల్లప్పుడూ క్లస్టర్‌ను మాన్యువల్‌గా తనిఖీ చేయాలి. మేము ఎల్లప్పుడూ నవీనమైన సంఖ్యలో ప్రతిరూపాలను కలిగి ఉండేలా చూసుకోవాలి, ప్రతిరూపణ లాగ్ లేదు, స్ట్రీమింగ్ రెప్లికేషన్‌కు సంబంధించిన లాగ్లలో ఎటువంటి లోపాలు లేవు, పాత్రోనితో, DCS సిస్టమ్‌తో.
ఆటోమేషన్ విజయవంతంగా పని చేస్తుంది, Patroni చాలా మంచి సాధనం. ఇది పని చేయగలదు, కానీ ఇది క్లస్టర్‌ను కావలసిన స్థితికి తీసుకురాదు. మరి ఆ విషయం కనుక్కోకపోతే మనమే ఇబ్బందుల్లో పడతాం.
మరియు పాత్రోని వెండి బుల్లెట్ కాదు. పోస్ట్‌గ్రెస్ ఎలా పని చేస్తుందో, రెప్లికేషన్ ఎలా పని చేస్తుందో మరియు పోస్ట్‌గ్రెస్‌తో పాట్రోని ఎలా పని చేస్తుందో మరియు నోడ్‌ల మధ్య కమ్యూనికేషన్ ఎలా అందించబడుతుందో మనం ఇంకా అర్థం చేసుకోవాలి. మీ చేతులతో సమస్యలను పరిష్కరించడానికి ఇది అవసరం.
రోగనిర్ధారణ సమస్యను నేను ఎలా సంప్రదించాలి? మేము వేర్వేరు క్లయింట్‌లతో పని చేస్తాము మరియు ఎవరికీ ELK స్టాక్ లేదు మరియు మేము 6 కన్సోల్‌లు మరియు 2 ట్యాబ్‌లను తెరవడం ద్వారా లాగ్‌లను క్రమబద్ధీకరించాలి. ఒక ట్యాబ్‌లో, ఇవి ప్రతి నోడ్‌కు సంబంధించిన Patroni లాగ్‌లు, మరొక ట్యాబ్‌లో, ఇవి కాన్సుల్ లాగ్‌లు లేదా అవసరమైతే Postgres. దీన్ని నిర్ధారించడం చాలా కష్టం.
నేను ఏ విధానాలను అభివృద్ధి చేసాను? మొదట, ఫైలర్ వచ్చినప్పుడు నేను ఎల్లప్పుడూ చూస్తాను. మరియు నాకు ఇది ఒక పరీవాహక ప్రాంతం. ఫైలర్‌కు ముందు, ఫైలర్ సమయంలో మరియు ఫైలర్ తర్వాత ఏమి జరిగిందో నేను చూస్తున్నాను. ఫైల్‌ఓవర్‌కు రెండు మార్కులు ఉన్నాయి: ఇది ప్రారంభ మరియు ముగింపు సమయం.
తరువాత, నేను ఫైలర్‌కు ముందు ఈవెంట్‌ల కోసం లాగ్‌లను చూస్తాను, ఇది ఫైలర్‌కు ముందు ఉంటుంది, అంటే ఫైలర్ ఎందుకు జరిగిందో నేను వెతుకుతాను.
మరియు ఇది ఏమి జరిగిందో మరియు భవిష్యత్తులో ఏమి చేయవచ్చో అర్థం చేసుకునే చిత్రాన్ని ఇస్తుంది, తద్వారా అలాంటి పరిస్థితులు ఏర్పడకుండా ఉంటాయి (మరియు ఫలితంగా, ఫైలర్ లేదు).
మరియు మనం సాధారణంగా ఎక్కడ చూస్తాము? నేను చూస్తున్నాను:
- ముందుగా, Patroni లాగ్‌లకు.
- తరువాత, నేను Patroni లాగ్లలో కనుగొనబడిన వాటిపై ఆధారపడి పోస్ట్‌గ్రెస్ లాగ్‌లు లేదా DCS లాగ్‌లను చూస్తాను.
- మరియు సిస్టమ్ లాగ్‌లు కూడా కొన్నిసార్లు ఫైలర్‌కు కారణమైన దాని గురించి అవగాహన కల్పిస్తాయి.
పాత్రోని గురించి నేను ఎలా భావిస్తున్నాను? నాకు పాత్రోనితో చాలా మంచి అనుబంధం ఉంది. నా అభిప్రాయం ప్రకారం, ఈ రోజులో ఇదే అత్యుత్తమమైనది. నాకు చాలా ఇతర ఉత్పత్తులు తెలుసు. అవి Stolon, Repmgr, Pg_auto_failover, PAF. 4 సాధనాలు. నేను వాటన్నింటినీ ప్రయత్నించాను. పాత్రోని నాకు ఇష్టమైనది.
వారు నన్ను అడిగితే: "నేను పాత్రోనిని సిఫార్సు చేస్తున్నానా?". నేను అవును అంటాను, ఎందుకంటే నాకు పాత్రోని ఇష్టం. మరియు నేను దానిని ఎలా ఉడికించాలో నేర్చుకున్నాను.
నేను పేర్కొన్న సమస్యలతో పాటు Patroniలో ఏ ఇతర సమస్యలు ఉన్నాయో చూడాలని మీకు ఆసక్తి ఉంటే, మీరు ఎల్లప్పుడూ పేజీని తనిఖీ చేయవచ్చు GitHubలో. అనేక విభిన్న కథలు ఉన్నాయి మరియు అనేక ఆసక్తికరమైన విషయాలు అక్కడ చర్చించబడ్డాయి. మరియు ఫలితంగా, కొన్ని దోషాలు ప్రవేశపెట్టబడ్డాయి మరియు పరిష్కరించబడ్డాయి, అంటే, ఇది ఆసక్తికరమైన పఠనం.
వ్యక్తులు తమను తాము పాదాలకు కాల్చుకోవడం గురించి కొన్ని ఆసక్తికరమైన కథనాలు ఉన్నాయి. చాలా ఇన్ఫర్మేటివ్. అలా చేయాల్సిన అవసరం లేదని మీరు చదివి అర్థం చేసుకున్నారు. నేనే టిక్ చేసాను.
మరియు నేను ఈ ప్రాజెక్ట్‌ను అభివృద్ధి చేసినందుకు జలాండోకి, అంటే అలెగ్జాండర్ కుకుష్కిన్ మరియు అలెక్సీ క్లూకిన్‌లకు పెద్ద కృతజ్ఞతలు చెప్పాలనుకుంటున్నాను. అలెక్సీ క్లూకిన్ సహ రచయితలలో ఒకరు, అతను ఇకపై జలాండోలో పని చేయడు, కానీ ఈ ఉత్పత్తితో పనిచేయడం ప్రారంభించిన ఇద్దరు వ్యక్తులు.
మరియు పాత్రోని చాలా మంచి విషయం అని నేను అనుకుంటున్నాను. ఆమె ఉనికిలో ఉన్నందుకు నేను సంతోషంగా ఉన్నాను, ఇది ఆమెతో ఆసక్తికరంగా ఉంది. మరియు Patroniకి ప్యాచ్‌లు వ్రాసే సహకారులందరికీ ధన్యవాదాలు. పాత్రోని వయస్సుతో మరింత పరిణతి చెందుతుందని, చల్లగా మరియు సమర్థవంతంగా మారుతుందని నేను ఆశిస్తున్నాను. ఇది ఇప్పటికే పని చేస్తోంది, కానీ ఇది మరింత మెరుగవుతుందని నేను ఆశిస్తున్నాను. అందువలన, మీరు Patroni ఉపయోగించడానికి ప్లాన్ ఉంటే, అప్పుడు బయపడకండి. ఇది మంచి పరిష్కారం, దీనిని అమలు చేయవచ్చు మరియు ఉపయోగించవచ్చు.
అంతే. మీకు ఏవైనా ప్రశ్నలు ఉంటే, అడగండి.
మీ ప్రశ్నలు
నివేదికకు ధన్యవాదాలు! ఫైల్ చేసిన తర్వాత మీరు అక్కడ చాలా జాగ్రత్తగా చూడవలసి వస్తే, మనకు ఆటోమేటిక్ ఫైలర్ ఎందుకు అవసరం?
ఎందుకంటే ఇది కొత్త విషయం. మేము ఆమెతో ఒక సంవత్సరం మాత్రమే ఉన్నాము. సురక్షితంగా ఉండటం మంచిది. మేము లోపలికి రావాలనుకుంటున్నాము మరియు ప్రతిదీ నిజంగా జరగాల్సిన విధంగా పని చేస్తుందో చూడాలి. ఇది పెద్దల అపనమ్మకం స్థాయి - ఒకటికి రెండుసార్లు సరిచూసుకుని చూడటం మంచిది.
ఉదాహరణకు, మేము ఉదయం వెళ్లి చూసాము, సరియైనదా?
ఉదయం కాదు, మేము సాధారణంగా ఆటోఫైల్ గురించి దాదాపు వెంటనే తెలుసుకుంటాము. మేము నోటిఫికేషన్‌లను స్వీకరిస్తాము, ఆటోఫైల్ సంభవించినట్లు మేము చూస్తాము. మేము దాదాపు వెంటనే వెళ్లి చూస్తాము. అయితే ఈ తనిఖీలన్నీ పర్యవేక్షణ స్థాయికి తీసుకురావాలి. మీరు REST API ద్వారా Patroniని యాక్సెస్ చేస్తే, ఒక చరిత్ర ఉంది. చరిత్ర ద్వారా మీరు ఫైలర్ జరిగిన సమయముద్రలను చూడవచ్చు. దీని ఆధారంగా పర్యవేక్షణ చేయవచ్చు. మీరు చరిత్రను చూడవచ్చు, ఎన్ని సంఘటనలు ఉన్నాయి. మాకు మరిన్ని ఈవెంట్‌లు ఉంటే, ఆటోఫైల్ ఏర్పడింది. మీరు వెళ్లి చూడగలరు. లేదా మా మానిటరింగ్ ఆటోమేషన్ మా వద్ద అన్ని ప్రతిరూపాలు ఉన్నాయని తనిఖీ చేసింది, ఎటువంటి లాగ్ లేదు మరియు అంతా బాగానే ఉంది.
ధన్యవాదాలు!
గొప్ప కథనానికి చాలా ధన్యవాదాలు! మనం DCS క్లస్టర్‌ని పోస్ట్‌గ్రెస్ క్లస్టర్‌కి దూరంగా ఎక్కడికో తరలించినట్లయితే, ఈ క్లస్టర్‌ని కూడా కాలానుగుణంగా సర్వీస్ చేయాల్సిన అవసరం ఉందా? DCS క్లస్టర్‌లోని కొన్ని భాగాలను ఆఫ్ చేయాల్సిన ఉత్తమ పద్ధతులు ఏమిటి, వాటితో ఏదైనా చేయాలి మొదలైనవి? ఈ మొత్తం నిర్మాణం ఎలా మనుగడలో ఉంది? మరియు మీరు ఈ పనులను ఎలా చేస్తారు?
ఒక సంస్థ కోసం, సమస్యల మాతృకను తయారు చేయడం అవసరం, వాటిలో ఒకటి లేదా అనేక భాగాలు విఫలమైతే ఏమి జరుగుతుంది. ఈ మాతృక ప్రకారం, మేము అన్ని భాగాలను వరుసగా పరిశీలిస్తాము మరియు ఈ భాగాలు విఫలమైనప్పుడు దృశ్యాలను రూపొందిస్తాము. దీని ప్రకారం, ప్రతి వైఫల్యం దృష్టాంతంలో, మీరు రికవరీ కోసం కార్యాచరణ ప్రణాళికను కలిగి ఉండవచ్చు. మరియు DCS విషయంలో, ఇది ప్రామాణిక మౌలిక సదుపాయాలలో భాగంగా వస్తుంది. మరియు నిర్వాహకులు దీనిని నిర్వహిస్తారు మరియు మేము ఇప్పటికే దీనిని నిర్వహించే నిర్వాహకులు మరియు ప్రమాదాల విషయంలో దాన్ని పరిష్కరించగల వారి సామర్థ్యంపై ఆధారపడతాము. DCS లేకపోతే, మేము దానిని అమలు చేస్తాము, కానీ అదే సమయంలో మేము దానిని ప్రత్యేకంగా పర్యవేక్షించము, ఎందుకంటే మేము మౌలిక సదుపాయాలకు బాధ్యత వహించము, కానీ ఎలా మరియు ఏమి పర్యవేక్షించాలో మేము సిఫార్సులను అందిస్తాము.
అంటే, హోస్ట్‌లతో ఏదైనా చేసే ముందు నేను పాట్రోనిని డిసేబుల్ చెయ్యాలి, ఫైలర్‌ని డిసేబుల్ చేయాలి, అన్నింటినీ డిసేబుల్ చేయాలి అని నేను సరిగ్గా అర్థం చేసుకున్నానా?
DCS క్లస్టర్‌లో మనకు ఎన్ని నోడ్‌లు ఉన్నాయో దానిపై ఆధారపడి ఉంటుంది. అనేక నోడ్‌లు ఉంటే మరియు మేము నోడ్‌లలో ఒకదాన్ని మాత్రమే నిలిపివేస్తే (ప్రతిరూపం), అప్పుడు క్లస్టర్ కోరమ్‌ను నిర్వహిస్తుంది. మరియు పాత్రోని పని చేస్తూనే ఉంది. మరియు ఏదీ ప్రేరేపించబడలేదు. మేము మరిన్ని నోడ్‌లను ప్రభావితం చేసే కొన్ని సంక్లిష్టమైన ఆపరేషన్‌లను కలిగి ఉంటే, అవి లేకపోవడం కోరమ్‌ను నాశనం చేయగలదు, అప్పుడు - అవును, పాట్రోనిని పాజ్‌లో ఉంచడం అర్ధమే. దీనికి సంబంధిత కమాండ్ ఉంది - patronictl పాజ్, patronictl రెజ్యూమ్. మేము పాజ్ చేస్తాము మరియు ఆ సమయంలో ఆటోఫైలర్ పని చేయదు. మేము DCS క్లస్టర్‌లో మెయింటెనెన్స్ చేస్తాము, ఆపై మేము పాజ్‌ని తీసివేసి, జీవించడం కొనసాగిస్తాము.
Спасибо!
మీ నివేదికకు చాలా ధన్యవాదాలు! డేటా పోయినందుకు ఉత్పత్తి బృందం ఎలా భావిస్తుంది?
ఉత్పత్తి బృందాలు పట్టించుకోవు మరియు టీమ్ లీడ్‌లు ఆందోళన చెందుతున్నారు.
ఏ హామీలు ఉన్నాయి?
హామీలు చాలా కష్టం. అలెగ్జాండర్ కుకుష్కిన్ "RPO మరియు RTOలను ఎలా లెక్కించాలి" అనే నివేదికను కలిగి ఉన్నారు, అనగా రికవరీ సమయం మరియు మనం ఎంత డేటాను కోల్పోవచ్చు. మనం ఈ స్లయిడ్‌లను కనుగొని వాటిని అధ్యయనం చేయాలని నేను భావిస్తున్నాను. నాకు గుర్తున్నంతవరకు, ఈ విషయాలను ఎలా లెక్కించాలనే దానిపై నిర్దిష్ట దశలు ఉన్నాయి. మనం ఎన్ని లావాదేవీలను కోల్పోవచ్చు, ఎంత డేటాను కోల్పోవచ్చు. ఒక ఎంపికగా, మేము Patroni స్థాయిలో సింక్రోనస్ రెప్లికేషన్‌ను ఉపయోగించవచ్చు, కానీ ఇది డబుల్ ఎడ్జ్డ్ కత్తి: మనకు డేటా విశ్వసనీయత ఉంటుంది లేదా మేము వేగాన్ని కోల్పోతాము. సింక్రోనస్ రెప్లికేషన్ ఉంది, కానీ ఇది డేటా నష్టం నుండి 100% రక్షణకు హామీ ఇవ్వదు.
అలెక్సీ, గొప్ప నివేదికకు ధన్యవాదాలు! సున్నా స్థాయి రక్షణ కోసం Patroniని ఉపయోగించడంలో ఏదైనా అనుభవం ఉందా? అంటే, సింక్రోనస్ స్టాండ్‌బైతో కలిపి? ఇది మొదటి ప్రశ్న. మరియు రెండవ ప్రశ్న. మీరు విభిన్న పరిష్కారాలను ఉపయోగించారు. మేము Repmgrని ఉపయోగించాము, కానీ ఆటోఫైలర్ లేకుండా, ఇప్పుడు మేము ఆటోఫైలర్‌ని చేర్చాలని ప్లాన్ చేస్తున్నాము. మరియు మేము Patroni ఒక ప్రత్యామ్నాయ పరిష్కారంగా పరిగణించండి. Repmgrతో పోలిస్తే మీరు ప్రయోజనాలుగా ఏమి చెప్పగలరు?
మొదటి ప్రశ్న సింక్రోనస్ రెప్లికాస్ గురించి. ఇక్కడ ఎవరూ సింక్రోనస్ రెప్లికేషన్‌ను ఉపయోగించరు, ఎందుకంటే అందరూ భయపడుతున్నారు (అనేక మంది క్లయింట్లు ఇప్పటికే దీన్ని ఉపయోగిస్తున్నారు, సూత్రప్రాయంగా, వారు పనితీరు సమస్యలను గమనించలేదు - స్పీకర్ నోట్) అయితే సింక్రోనస్ రెప్లికేషన్ క్లస్టర్‌లో కనీసం మూడు నోడ్‌లు ఉండాలనే నియమాన్ని మేము అభివృద్ధి చేసాము, ఎందుకంటే మనకు రెండు నోడ్‌లు ఉంటే మరియు మాస్టర్ లేదా రెప్లికా విఫలమైతే, ప్యాట్రోని ఈ నోడ్‌ని స్వతంత్ర మోడ్‌కి మారుస్తుంది, తద్వారా అప్లికేషన్ కొనసాగుతుంది. పని. ఈ సందర్భంలో, డేటా కోల్పోయే ప్రమాదం ఉంది.
రెండవ ప్రశ్నకు సంబంధించి, మేము Repmgrని ఉపయోగించాము మరియు చారిత్రక కారణాల కోసం ఇప్పటికీ కొంతమంది క్లయింట్‌లతో చేస్తాము. ఏం చెప్పగలం? Patroni ఆటోఫైలర్ అవుట్ ఆఫ్ ది బాక్స్‌తో వస్తుంది, Repmgr ఆటోఫైలర్‌తో వస్తుంది, అది ఎనేబుల్ చేయాల్సిన అదనపు ఫీచర్‌గా ఉంటుంది. మేము ప్రతి నోడ్‌లో Repmgr డెమోన్‌ను అమలు చేయాలి మరియు ఆపై మనం ఆటోఫైలర్‌ను కాన్ఫిగర్ చేయవచ్చు.
Postgres నోడ్స్ సజీవంగా ఉన్నాయో లేదో Repmgr తనిఖీ చేస్తుంది. Repmgr ప్రక్రియలు ఒకదానికొకటి ఉనికిని తనిఖీ చేస్తాయి, ఇది చాలా సమర్థవంతమైన విధానం కాదు. నెట్‌వర్క్ ఐసోలేషన్ యొక్క సంక్లిష్టమైన సందర్భాలు ఉండవచ్చు, దీనిలో పెద్ద Repmgr క్లస్టర్ అనేక చిన్నవిగా విడిపోయి పనిని కొనసాగించవచ్చు. నేను చాలా కాలంగా Repmgrని అనుసరించడం లేదు, బహుశా అది పరిష్కరించబడి ఉండవచ్చు ... లేదా కాకపోవచ్చు. కానీ స్టోలన్, పాట్రోని చేసినట్లుగా DCSలో క్లస్టర్ స్థితి గురించిన సమాచారాన్ని తీసివేయడం అత్యంత ఆచరణీయమైన ఎంపిక.
అలెక్సీ, నాకు ఒక ప్రశ్న ఉంది, బహుశా లేమర్ ఒకటి. మొదటి ఉదాహరణలలో ఒకదానిలో, మీరు DCSని స్థానిక మెషీన్ నుండి రిమోట్ హోస్ట్‌కి తరలించారు. నెట్‌వర్క్ అనేది దాని స్వంత లక్షణాలను కలిగి ఉన్న విషయం అని మేము అర్థం చేసుకున్నాము, అది దాని స్వంతదానిపై జీవిస్తుంది. మరియు కొన్ని కారణాల వలన DCS క్లస్టర్ అందుబాటులో లేనట్లయితే ఏమి జరుగుతుంది? నేను కారణాలను చెప్పను, వాటిలో చాలా ఉండవచ్చు: నెట్‌వర్కర్ల వంకర చేతుల నుండి నిజమైన సమస్యల వరకు.
నేను బిగ్గరగా చెప్పలేదు, కానీ DCS క్లస్టర్ తప్పనిసరిగా ఫెయిల్‌ఓవర్ అయి ఉండాలి, అనగా ఇది కోరమ్‌ని చేరుకోవడానికి బేసి సంఖ్యల నోడ్‌లు. DCS క్లస్టర్ అందుబాటులో లేకుంటే, లేదా కోరం చేరుకోలేకపోతే, అంటే ఒక రకమైన నెట్‌వర్క్ స్ప్లిట్ లేదా నోడ్ వైఫల్యం ఏర్పడితే ఏమి జరుగుతుంది? ఈ సందర్భంలో, Patroni క్లస్టర్ చదవడానికి మాత్రమే మోడ్‌లోకి వెళుతుంది. Patroni క్లస్టర్ క్లస్టర్ యొక్క స్థితిని మరియు ఏమి చేయాలో నిర్ణయించలేదు. ఇది DCSని సంప్రదించి, అక్కడ కొత్త క్లస్టర్ స్థితిని నిల్వ చేయదు, కాబట్టి మొత్తం క్లస్టర్ చదవడానికి మాత్రమే వెళ్తుంది. మరియు ఆపరేటర్ నుండి మాన్యువల్ జోక్యం కోసం లేదా DCS కోలుకోవడానికి వేచి ఉంది.
స్థూలంగా చెప్పాలంటే, DCS మనకు ఆధారం వలె ముఖ్యమైన సేవ అవుతుంది?
అవును అవును. చాలా ఆధునిక కంపెనీలలో, సర్వీస్ డిస్కవరీ అనేది మౌలిక సదుపాయాలలో అంతర్భాగం. ఇన్‌ఫ్రాస్ట్రక్చర్‌లో డేటాబేస్ రాకముందే ఇది అమలు చేయబడుతోంది. సాపేక్షంగా చెప్పాలంటే, ఇన్‌ఫ్రాస్ట్రక్చర్ ప్రారంభించబడింది, DCలో అమర్చబడింది మరియు మేము వెంటనే సర్వీస్ డిస్కవరీని కలిగి ఉన్నాము. అది కాన్సుల్ అయితే, దానిపై DNS నిర్మించవచ్చు. ఇది Etcd అయితే, కుబెర్నెటెస్ క్లస్టర్ నుండి కొంత భాగం ఉండవచ్చు, అందులో మిగతావన్నీ అమర్చబడతాయి. సర్వీస్ డిస్కవరీ ఇప్పటికే ఆధునిక మౌలిక సదుపాయాలలో అంతర్భాగంగా ఉన్నట్లు నాకు అనిపిస్తోంది. మరియు వారు డేటాబేస్ల కంటే చాలా ముందుగానే దాని గురించి ఆలోచిస్తారు.
ధన్యవాదాలు!
మూలం: www.habr.com