తన నివేదికలో, ఆండ్రీ బోరోడిన్ కనెక్షన్ పూలర్‌ను రూపకల్పన చేసేటప్పుడు PgBouncer యొక్క స్కేలింగ్ అనుభవాన్ని ఎలా పరిగణనలోకి తీసుకున్నారో మీకు తెలియజేస్తుంది. , వారు దానిని ఉత్పత్తిలోకి తీసుకువచ్చారు. అదనంగా, మేము కొత్త సంస్కరణల్లో చూడాలనుకుంటున్న పుల్లర్ యొక్క ఏ విధులను చర్చిస్తాము: ఇది మా అవసరాలను తీర్చడమే కాదు, వినియోగదారు సంఘాన్ని అభివృద్ధి చేయడం ముఖ్యం. .
వీడియోలు:
అందరికి వందనాలు! నా పేరు ఆండ్రూ.
Yandex వద్ద, నేను ఓపెన్ సోర్స్ డేటాబేస్‌లను అభివృద్ధి చేస్తాను. మరియు ఈ రోజు మనకు కనెక్షన్ పూలర్ కనెక్షన్ల గురించి ఒక అంశం ఉంది.
కనెక్షన్ పూలర్‌ని రష్యన్‌లో ఎలా కాల్ చేయాలో మీకు తెలిస్తే, నాకు చెప్పండి. నేను నిజంగా సాంకేతిక సాహిత్యంలో ఏర్పాటు చేయవలసిన మంచి సాంకేతిక పదాన్ని కనుగొనాలనుకుంటున్నాను.
అంశం చాలా క్లిష్టంగా ఉంది, ఎందుకంటే అనేక డేటాబేస్‌లలో కనెక్షన్ పూలర్ అంతర్నిర్మితంగా ఉంది మరియు మీరు దాని గురించి కూడా తెలుసుకోవలసిన అవసరం లేదు. అయితే, ప్రతిచోటా కొన్ని సెట్టింగ్‌లు ఉన్నాయి, కానీ పోస్ట్‌గ్రెస్‌లో అది ఆ విధంగా పని చేయదు. మరియు సమాంతరంగా (హైలోడ్++ 2019లో) పోస్ట్‌గ్రెస్‌లో ప్రశ్నలను సెటప్ చేయడం గురించి నికోలాయ్ సమోఖ్వలోవ్ ద్వారా ఒక నివేదిక ఉంది. మరియు నేను అర్థం చేసుకున్నట్లుగా, ఇప్పటికే వారి ప్రశ్నలను సంపూర్ణంగా కాన్ఫిగర్ చేసిన వ్యక్తులు ఇక్కడకు వచ్చారు మరియు వీరు నెట్‌వర్క్ మరియు వనరుల వినియోగానికి సంబంధించిన మరింత అరుదైన సిస్టమ్ సమస్యలను ఎదుర్కొంటున్న వ్యక్తులు. మరియు కొన్ని ప్రదేశాలలో సమస్యలు స్పష్టంగా లేవు అనే కోణంలో చాలా కష్టంగా ఉండవచ్చు.
Yandex లో Postgres ఉంది. అనేక Yandex సేవలు Yandex.Cloudలో నివసిస్తున్నాయి. పోస్ట్‌గ్రెస్‌లో సెకనుకు కనీసం మిలియన్ అభ్యర్థనలను రూపొందించే అనేక పెటాబైట్‌ల డేటా మా వద్ద ఉంది.
మరియు మేము అన్ని సేవలకు చాలా ప్రామాణికమైన క్లస్టర్‌ను అందిస్తాము - ఇది నోడ్ యొక్క ప్రధాన ప్రాథమిక నోడ్, సాధారణ రెండు ప్రతిరూపాలు (సమకాలిక మరియు అసమకాలిక), బ్యాకప్, ప్రతిరూపంపై అభ్యర్థనలను చదవడం స్కేలింగ్.
ప్రతి క్లస్టర్ నోడ్ పోస్ట్‌గ్రెస్, దానిపై పోస్ట్‌గ్రెస్ మరియు మానిటరింగ్ సిస్టమ్‌లతో పాటు, కనెక్షన్ పూలర్ కూడా ఇన్‌స్టాల్ చేయబడింది. కనెక్షన్ పూలర్ ఫెన్సింగ్ కోసం మరియు దాని ప్రధాన ప్రయోజనం కోసం ఉపయోగించబడుతుంది.
కనెక్షన్ పూలర్ యొక్క ప్రధాన ప్రయోజనం ఏమిటి?
డేటాబేస్‌తో పని చేస్తున్నప్పుడు పోస్ట్‌గ్రెస్ ప్రాసెస్ మోడల్‌ను స్వీకరిస్తుంది. దీని అర్థం ఒక కనెక్షన్ ఒక ప్రక్రియ, ఒక పోస్ట్‌గ్రెస్ బ్యాకెండ్. మరియు ఈ బ్యాకెండ్‌లో విభిన్నమైన కాష్‌లు చాలా ఉన్నాయి, ఇవి వేర్వేరు కనెక్షన్ల కోసం విభిన్నంగా చేయడానికి చాలా ఖరీదైనవి.
అదనంగా, Postgres కోడ్‌లో procArray అనే శ్రేణి ఉంది. ఇది నెట్‌వర్క్ కనెక్షన్ల గురించి ప్రాథమిక డేటాను కలిగి ఉంది. మరియు దాదాపు అన్ని procArray ప్రాసెసింగ్ అల్గారిథమ్‌లు సరళ సంక్లిష్టతను కలిగి ఉంటాయి; అవి నెట్‌వర్క్ కనెక్షన్ల మొత్తం శ్రేణిపై నడుస్తాయి. ఇది చాలా శీఘ్ర చక్రం, కానీ ఎక్కువ ఇన్‌కమింగ్ నెట్‌వర్క్ కనెక్షన్‌లతో విషయాలు కొంచెం ఖరీదైనవి. మరియు విషయాలు కొంచెం ఖరీదైనవి అయినప్పుడు, మీరు చాలా నెట్‌వర్క్ కనెక్షన్ల కోసం చాలా ఎక్కువ ధరను చెల్లించవచ్చు.
3 సాధ్యమైన విధానాలు ఉన్నాయి:
- అప్లికేషన్ వైపు.
- డేటాబేస్ వైపు.
- మరియు మధ్య, అంటే, అన్ని రకాల కలయికలు.
దురదృష్టవశాత్తూ, అంతర్నిర్మిత పూలర్ ప్రస్తుతం అభివృద్ధిలో ఉంది. PostgreSQL ప్రొఫెషనల్‌లోని మా స్నేహితులు దీన్ని ఎక్కువగా చేస్తారు. ఎప్పుడు కనిపిస్తుందో ఊహించడం కష్టం. వాస్తవానికి, ఆర్కిటెక్ట్ ఎంచుకోవడానికి మాకు రెండు పరిష్కారాలు ఉన్నాయి. ఇవి అప్లికేషన్-సైడ్ పూల్ మరియు ప్రాక్సీ పూల్.
అప్లికేషన్ సైడ్ పూల్ సులభమయిన మార్గం. మరియు దాదాపు అన్ని క్లయింట్ డ్రైవర్లు మీకు ఒక మార్గాన్ని అందిస్తారు: మీ మిలియన్ల కొద్దీ కనెక్షన్‌లను డేటాబేస్‌కు అనేక డజన్ల కనెక్షన్‌లుగా కోడ్‌లో ప్రదర్శించండి.
ఉత్పన్నమయ్యే సమస్య ఏమిటంటే, ఒక నిర్దిష్ట సమయంలో మీరు బ్యాకెండ్‌ను స్కేల్ చేయాలనుకుంటున్నారు, మీరు దానిని అనేక వర్చువల్ మెషీన్‌లకు అమలు చేయాలనుకుంటున్నారు.
అప్పుడు మీకు అనేక లభ్యత జోన్‌లు, అనేక డేటా సెంటర్లు ఉన్నాయని మీరు గ్రహించారు. మరియు క్లయింట్ వైపు పూలింగ్ విధానం పెద్ద సంఖ్యలో దారి తీస్తుంది. పెద్దవి దాదాపు 10 కనెక్షన్లు. ఇది సాధారణంగా పని చేయగల అంచు.
మేము ప్రాక్సీ పూలర్ల గురించి మాట్లాడినట్లయితే, చాలా పనులు చేయగల ఇద్దరు పూలర్లు ఉన్నారు. వారు పూలర్లు మాత్రమే కాదు. అవి పూలర్లు + మరింత కూల్ ఫంక్షనాలిటీ. ఈ и .
కానీ, దురదృష్టవశాత్తు, ప్రతి ఒక్కరికీ ఈ అదనపు కార్యాచరణ అవసరం లేదు. మరియు ఇది పూలర్లు సెషన్ పూలింగ్‌కు మాత్రమే మద్దతిస్తాయనే వాస్తవానికి దారి తీస్తుంది, అనగా ఒక ఇన్‌కమింగ్ క్లయింట్, ఒక అవుట్‌గోయింగ్ క్లయింట్ డేటాబేస్‌కు.
ఇది మా ప్రయోజనాల కోసం చాలా సరిఅయినది కాదు, కాబట్టి మేము లావాదేవీల పూలింగ్‌ను అమలు చేసే PgBouncerని ఉపయోగిస్తాము, అనగా సర్వర్ కనెక్షన్లు లావాదేవీ వ్యవధికి మాత్రమే క్లయింట్ కనెక్షన్‌లకు సరిపోలుతాయి.
మరియు మా పనిభారంలో, ఇది నిజం. కానీ కొన్ని సమస్యలు ఉన్నాయి.
మీరు సెషన్‌ని నిర్ధారించాలనుకున్నప్పుడు సమస్యలు మొదలవుతాయి, ఎందుకంటే మీ ఇన్‌కమింగ్ కనెక్షన్‌లన్నీ స్థానికంగా ఉంటాయి. అందరూ లూప్‌బ్యాక్‌తో వచ్చారు మరియు సెషన్‌ను కనుగొనడం ఏదో ఒకవిధంగా కష్టమవుతుంది.
వాస్తవానికి మీరు application_name_add_hostని ఉపయోగించవచ్చు. అప్లికేషన్_పేరుకు IP చిరునామాను జోడించడానికి బౌన్సర్ వైపు ఇది ఒక మార్గం. కానీ అప్లికేషన్_పేరు అదనపు కనెక్షన్ ద్వారా సెట్ చేయబడింది.
ఈ గ్రాఫ్‌లో, పసుపు రేఖ నిజమైన అభ్యర్థనలు మరియు బ్లూ లైన్ అనేది డేటాబేస్‌లోకి వెళ్లే అభ్యర్థనలు. మరియు ఈ వ్యత్యాసం ఖచ్చితంగా అప్లికేషన్_నేమ్ యొక్క ఇన్‌స్టాలేషన్, ఇది ట్రేసింగ్ కోసం మాత్రమే అవసరం, కానీ ఇది ఉచితం కాదు.
అదనంగా, బౌన్సర్‌లో మీరు ఒక పూల్‌ను పరిమితం చేయలేరు, అనగా నిర్దిష్ట డేటాబేస్‌కు నిర్దిష్ట వినియోగదారుకు డేటాబేస్ కనెక్షన్ల సంఖ్య.
ఇది దేనికి దారి తీస్తుంది? మీరు C++లో వ్రాసిన లోడ్ చేయబడిన సేవను కలిగి ఉన్నారు మరియు డేటాబేస్‌తో ఏదైనా భయంకరమైన పనిని చేయని నోడ్‌లో ఎక్కడో ఒక చిన్న సేవ సమీపంలో ఉంది, కానీ దాని డ్రైవర్ వెర్రివాడు. ఇది 20 కనెక్షన్‌లను తెరుస్తుంది మరియు మిగతావన్నీ వేచి ఉంటాయి. మీ కోడ్ కూడా సాధారణమైనది.
మేము బౌన్సర్ కోసం ఒక చిన్న ప్యాచ్‌ని వ్రాసాము, అది ఈ సెట్టింగ్‌ని జోడించింది, అంటే క్లయింట్‌లను పూల్‌కి పరిమితం చేయడం.
పోస్ట్‌గ్రెస్ వైపు దీన్ని చేయడం సాధ్యమవుతుంది, అనగా, కనెక్షన్ల సంఖ్య ద్వారా డేటాబేస్‌లోని పాత్రలను పరిమితం చేయండి.
అయితే మీకు సర్వర్‌కు కనెక్షన్లు ఎందుకు లేవని అర్థం చేసుకునే సామర్థ్యాన్ని మీరు కోల్పోతారు. PgBouncer కనెక్షన్ లోపాన్ని విసిరివేయదు, ఇది ఎల్లప్పుడూ అదే సమాచారాన్ని అందిస్తుంది. మరియు మీరు అర్థం చేసుకోలేరు: బహుశా మీ పాస్‌వర్డ్ మార్చబడి ఉండవచ్చు, బహుశా డేటాబేస్ పోయింది, బహుశా ఏదో తప్పు కావచ్చు. కానీ రోగ నిర్ధారణ లేదు. సెషన్‌ను ఏర్పాటు చేయలేకపోతే, దాన్ని ఎందుకు ఏర్పాటు చేయలేదో మీకు తెలియదు.
ఒక నిర్దిష్ట సమయంలో, మీరు అప్లికేషన్ గ్రాఫ్‌లను చూస్తారు మరియు అప్లికేషన్ పనిచేయడం లేదని చూడండి.
పైభాగంలో చూడండి మరియు బౌన్సర్ సింగిల్-థ్రెడ్ అని చూడండి. సేవా జీవితంలో ఇదొక మలుపు. మీరు డేటాబేస్ను ఏడాదిన్నరలో స్కేల్ చేయడానికి సిద్ధమవుతున్నారని మీరు గ్రహించారు మరియు మీరు పూలర్‌ను స్కేల్ చేయాలి.
మేము మరింత PgBouncers అవసరం అని నిర్ధారణకు వచ్చాము.
బౌన్సర్‌కి కాస్త పాచ్‌ చేయబడింది.
మరియు వారు TCP పోర్ట్‌ను తిరిగి ఉపయోగించడం ద్వారా అనేక బౌన్సర్‌లను పెంచుకునేలా చేశారు. మరియు ఆపరేటింగ్ సిస్టమ్ స్వయంచాలకంగా రౌండ్-రాబిన్ ఉపయోగించి వాటి మధ్య ఇన్‌కమింగ్ TCP కనెక్షన్‌లను బదిలీ చేస్తుంది.
ఇది క్లయింట్‌లకు పారదర్శకంగా ఉంటుంది, అంటే మీకు ఒక బౌన్సర్ ఉన్నట్లు కనిపిస్తోంది, కానీ మీరు నడుస్తున్న బౌన్సర్‌ల మధ్య నిష్క్రియ కనెక్షన్ల ఫ్రాగ్మెంటేషన్‌ను కలిగి ఉన్నారు.
మరియు ఒక నిర్దిష్ట సమయంలో ఈ 3 బౌన్సర్లు ఒక్కొక్కరు తమ కోర్ని 100% మేర తిన్నారని మీరు గమనించవచ్చు. మీకు చాలా కొద్ది మంది బౌన్సర్లు కావాలి. ఎందుకు?
ఎందుకంటే మీకు TLS ఉంది. మీకు ఎన్‌క్రిప్టెడ్ కనెక్షన్ ఉంది. మరియు మీరు TLSతో మరియు లేకుండా పోస్ట్‌గ్రెస్‌ను బెంచ్‌మార్క్ చేస్తే, ఎన్‌క్రిప్షన్ ఎనేబుల్ చేయబడి, స్థాపించబడిన కనెక్షన్ల సంఖ్య దాదాపు రెండు ఆర్డర్‌ల పరిమాణంలో తగ్గుతుందని మీరు కనుగొంటారు, ఎందుకంటే TLS హ్యాండ్‌షేక్ CPU వనరులను వినియోగిస్తుంది.
మరియు ఎగువన మీరు ఇన్‌కమింగ్ కనెక్షన్ల వేవ్ ఉన్నప్పుడు అమలు చేయబడిన కొన్ని క్రిప్టోగ్రాఫిక్ ఫంక్షన్‌లను చూడవచ్చు. మా ప్రైమరీ లభ్యత జోన్‌ల మధ్య మారవచ్చు కాబట్టి, ఇన్‌కమింగ్ కనెక్షన్ల వేవ్ చాలా సాధారణ పరిస్థితి. అంటే, కొన్ని కారణాల వల్ల పాత ప్రాథమికం అందుబాటులో లేదు, మొత్తం లోడ్ మరొక డేటా కేంద్రానికి పంపబడింది. వారందరూ ఒకే సమయంలో TLSకి హలో చెప్పడానికి వస్తారు.
మరియు పెద్ద సంఖ్యలో TLS హ్యాండ్‌షేక్ ఇకపై బౌన్సర్‌కి హలో చెప్పకపోవచ్చు, కానీ అతని గొంతును పిండుతుంది. గడువు ముగిసినందున, ఇన్‌కమింగ్ కనెక్షన్ల వేవ్ డంప్డ్‌గా మారవచ్చు. మీరు ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్ లేకుండా బేస్‌కి మళ్లీ ప్రయత్నిస్తే, అవి మళ్లీ మళ్లీ పొందికైన వేవ్‌లో రావు.
16 కోర్లను 16% లోడ్ చేసే 100 PgBouncers యొక్క ఉదాహరణ ఇక్కడ ఉంది.
మేము క్యాస్కేడ్ PgBouncer వద్దకు వచ్చాము. బౌన్సర్‌తో మా లోడ్‌పై సాధించగలిగే అత్యుత్తమ కాన్ఫిగరేషన్ ఇది. మా బాహ్య బౌన్సర్లు TCP హ్యాండ్‌షేక్ కోసం ఉపయోగించబడతాయి మరియు అంతర్గత బౌన్సర్లు నిజమైన పూలింగ్ కోసం ఉపయోగించబడతాయి, తద్వారా బాహ్య కనెక్షన్‌లను ఎక్కువగా విచ్ఛిన్నం చేయకూడదు.
ఈ కాన్ఫిగరేషన్‌లో, మృదువైన పునఃప్రారంభం సాధ్యమవుతుంది. మీరు ఈ 18 బౌన్సర్‌లను ఒక్కొక్కటిగా పునఃప్రారంభించవచ్చు. కానీ అలాంటి కాన్ఫిగరేషన్‌ను నిర్వహించడం చాలా కష్టం. Sysadmins, DevOps మరియు వాస్తవానికి ఈ సర్వర్‌కు బాధ్యత వహించే వ్యక్తులు ఈ ఏర్పాటుతో చాలా సంతోషంగా ఉండరు.
మా మెరుగుదలలన్నీ ఓపెన్ సోర్స్‌కి ప్రమోట్ చేయవచ్చని అనిపించవచ్చు, కానీ బౌన్సర్‌కు అంతగా మద్దతు లేదు. ఉదాహరణకు, ఒక పోర్ట్‌లో అనేక PgBouncers అమలు చేయగల సామర్థ్యం ఒక నెల క్రితం కట్టుబడి ఉంది. చాలా సంవత్సరాల క్రితం ఈ ఫీచర్‌తో పుల్ అభ్యర్థన వచ్చింది.
లేదా మరొక ఉదాహరణ. Postgresలో, మీరు అనవసరమైన ప్రమాణీకరణ లేకుండా రహస్యాన్ని వేరే కనెక్షన్‌కి పంపడం ద్వారా ప్రోగ్రెస్‌లో ఉన్న అభ్యర్థనను రద్దు చేయవచ్చు. కానీ కొంతమంది క్లయింట్లు కేవలం TCP రీసెట్‌ను పంపుతారు, అనగా వారు నెట్‌వర్క్ కనెక్షన్‌ను విచ్ఛిన్నం చేస్తారు. బౌన్సర్ ఏమి చేస్తాడు? అతను ఏమీ చేయడు. ఇది అభ్యర్థనను అమలు చేయడం కొనసాగిస్తుంది. మీరు చిన్న అభ్యర్థనలతో డేటాబేస్ను సృష్టించిన భారీ సంఖ్యలో కనెక్షన్‌లను స్వీకరించినట్లయితే, బౌన్సర్ నుండి కనెక్షన్‌ని డిస్‌కనెక్ట్ చేయడం సరిపోదు; మీరు డేటాబేస్లో నడుస్తున్న అభ్యర్థనలను కూడా పూర్తి చేయాలి.
ఇది ప్యాచ్ చేయబడింది మరియు ఈ సమస్య ఇంకా బౌన్సర్ యొక్క అప్‌స్ట్రీమ్‌లో విలీనం చేయబడలేదు.
కాబట్టి మేము మా స్వంత కనెక్షన్ పూలర్ అవసరమని నిర్ధారణకు వచ్చాము, ఇది అభివృద్ధి చేయబడుతుంది, ప్యాచ్ చేయబడుతుంది, దీనిలో సమస్యలను త్వరగా సరిదిద్దవచ్చు మరియు ఇది తప్పనిసరిగా బహుళ-థ్రెడ్ చేయబడాలి.
మేము మల్టీథ్రెడింగ్‌ను ప్రధాన పనిగా సెట్ చేసాము. మేము ఇన్‌కమింగ్ TLS కనెక్షన్ల వేవ్‌ను బాగా నిర్వహించగలగాలి.
దీన్ని చేయడానికి, మేము మెషినారియం అనే ప్రత్యేక లైబ్రరీని అభివృద్ధి చేయాల్సి వచ్చింది, ఇది నెట్‌వర్క్ కనెక్షన్ యొక్క మెషిన్ స్టేట్‌లను సీక్వెన్షియల్ కోడ్‌గా వివరించడానికి రూపొందించబడింది. మీరు libpq సోర్స్ కోడ్‌ని చూస్తే, మీకు కొన్ని క్లిష్టమైన కాల్‌లు కనిపిస్తాయి, అవి మీకు ఫలితాన్ని అందించగలవు మరియు “నన్ను తర్వాత కాల్ చేయండి. ప్రస్తుతం నాకు IO ఉంది, కానీ IO పోయినప్పుడు నేను ప్రాసెసర్‌పై లోడ్ కలిగి ఉంటాను. మరియు ఇది బహుళ-స్థాయి పథకం. నెట్‌వర్క్ కమ్యూనికేషన్ సాధారణంగా స్టేట్ మెషీన్ ద్వారా వివరించబడుతుంది. "నేను ఇంతకు ముందు సైజు N యొక్క ప్యాకెట్ హెడర్‌ను స్వీకరించినట్లయితే, ఇప్పుడు నేను N బైట్‌ల కోసం వేచి ఉన్నాను," "నేను SYNC ప్యాకెట్‌ను పంపినట్లయితే, ఇప్పుడు నేను ఫలిత మెటాడేటాతో కూడిన ప్యాకెట్ కోసం వేచి ఉన్నాను" వంటి అనేక నియమాలు ఉన్నాయి. చిట్టడవి లైన్ స్కాన్‌గా మార్చబడినట్లుగా, ఫలితం చాలా కష్టమైన, ప్రతికూలమైన కోడ్. మేము దానిని స్టేట్ మెషీన్‌కు బదులుగా, ప్రోగ్రామర్ సాధారణ ఇంపెరేటివ్ కోడ్ రూపంలో పరస్పర చర్య యొక్క ప్రధాన మార్గాన్ని వివరిస్తుంది. ఈ అత్యవసర కోడ్‌లో మీరు నెట్‌వర్క్ నుండి డేటా కోసం వేచి ఉండటం ద్వారా అమలు క్రమానికి అంతరాయం కలిగించాల్సిన ప్రదేశాలను చొప్పించవలసి ఉంటుంది, అమలు సందర్భాన్ని మరొక కరోటిన్ (గ్రీన్ థ్రెడ్)కి పంపుతుంది. ఈ విధానం మేము చిట్టడవిలో చాలా ఆశించిన మార్గాన్ని వరుసగా వ్రాసి, ఆపై దానికి శాఖలను జోడించే వాస్తవాన్ని పోలి ఉంటుంది.
ఫలితంగా, TCP అంగీకరించే మరియు రౌండ్-రాబిన్ చాలా మంది కార్మికులకు TPC కనెక్షన్‌ని అందించే ఒక థ్రెడ్ మాకు ఉంది.
ఈ సందర్భంలో, ప్రతి క్లయింట్ కనెక్షన్ ఎల్లప్పుడూ ఒక ప్రాసెసర్‌పై నడుస్తుంది. మరియు ఇది కాష్-ఫ్రెండ్లీగా చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
మరియు అదనంగా, మేము సిస్టమ్ TCP స్టాక్ నుండి ఉపశమనం పొందేందుకు చిన్న ప్యాకెట్ల సేకరణను ఒక పెద్ద ప్యాకెట్‌గా కొద్దిగా మెరుగుపరిచాము.
అదనంగా, మేము ఒడిస్సీని కాన్ఫిగర్ చేసినప్పుడు, నెట్‌వర్క్ కనెక్షన్ వైఫల్యం సంభవించినప్పుడు రద్దు చేసి, రోల్‌బ్యాక్‌ను పంపగలము, అనగా అభ్యర్థన కోసం ఎవరూ వేచి ఉండకపోతే, ఒడిస్సీ డేటాబేస్‌కు ప్రయత్నించవద్దని చెబుతుంది అనే కోణంలో మేము లావాదేవీల పూలింగ్‌ను మెరుగుపరిచాము. విలువైన వనరులను వృధా చేసే అభ్యర్థనను నెరవేర్చండి.
మరియు సాధ్యమైనప్పుడల్లా, మేము అదే క్లయింట్‌కు కనెక్షన్‌లను ఉంచుతాము. ఇది application_name_add_hostని మళ్లీ ఇన్‌స్టాల్ చేయడాన్ని నివారిస్తుంది. ఇది సాధ్యమైతే, డయాగ్నస్టిక్స్ కోసం అవసరమైన పారామితులను మేము అదనంగా రీసెట్ చేయవలసిన అవసరం లేదు.
మేము Yandex.Cloud యొక్క ప్రయోజనాలకు అనుగుణంగా పని చేస్తాము. మరియు మీరు నిర్వహించబడే PostgreSQLని ఉపయోగిస్తే మరియు కనెక్షన్ పూలర్‌ను ఇన్‌స్టాల్ చేసి ఉంటే, మీరు లాజికల్ రెప్లికేషన్‌ని ఉపయోగించి బయటికి లాజికల్ రెప్లికేషన్‌ను సృష్టించవచ్చు, అంటే, మీకు కావాలంటే మమ్మల్ని వదిలివేయండి. బౌన్సర్ లాజికల్ రెప్లికేషన్ ఫ్లోను బయట విడుదల చేయదు.
లాజికల్ రెప్లికేషన్‌ని సెటప్ చేయడానికి ఇది ఒక ఉదాహరణ.
అదనంగా, భౌతిక ప్రతిరూపణకు బాహ్యంగా మాకు మద్దతు ఉంది. క్లౌడ్‌లో, వాస్తవానికి, ఇది అసాధ్యం, ఎందుకంటే క్లస్టర్ దాని గురించి మీకు చాలా ఎక్కువ సమాచారాన్ని ఇస్తుంది. కానీ మీ ఇన్‌స్టాలేషన్‌లలో, ఒడిస్సీలోని కనెక్షన్ పూలర్ ద్వారా మీకు భౌతిక ప్రతిరూపం అవసరమైతే, ఇది సాధ్యమే.
ఒడిస్సీ PgBouncerతో పూర్తిగా అనుకూలమైన పర్యవేక్షణను కలిగి ఉంది. దాదాపు అన్ని ఒకే విధమైన ఆదేశాలను అమలు చేసే ఒకే కన్సోల్ మాకు ఉంది. ఏదైనా తప్పిపోయినట్లయితే, పుల్ అభ్యర్థనను పంపండి లేదా GitHubలో కనీసం సమస్యను పంపండి మరియు మేము అవసరమైన ఆదేశాలను పూర్తి చేస్తాము. కానీ మేము ఇప్పటికే PgBouncer కన్సోల్ యొక్క ప్రధాన కార్యాచరణను కలిగి ఉన్నాము.
మరియు, వాస్తవానికి, మాకు ఫార్వార్డింగ్ లోపం ఉంది. మేము డేటాబేస్ ద్వారా నివేదించబడిన లోపాన్ని తిరిగి ఇస్తాము. మీరు డేటాబేస్లో ఎందుకు చేర్చబడలేదు అనే దాని గురించి మీరు సమాచారాన్ని స్వీకరిస్తారు మరియు మీరు అందులో చేర్చబడలేదు.
మీకు PgBouncerతో 100% అనుకూలత అవసరమైతే ఈ ఫీచర్ నిలిపివేయబడుతుంది. మనం సురక్షితంగా ఉండటానికి బౌన్సర్ వలె ప్రవర్తించగలము.
డిజైన్
ఒడిస్సీ సోర్స్ కోడ్ గురించి కొన్ని మాటలు.
ఉదాహరణకు, "పాజ్ / రెజ్యూమ్" ఆదేశాలు ఉన్నాయి. వారు సాధారణంగా డేటాబేస్ను నవీకరించడానికి ఉపయోగిస్తారు. మీరు పోస్ట్‌గ్రెస్‌ని అప్‌డేట్ చేయవలసి వస్తే, మీరు దానిని కనెక్షన్ పూలర్‌లో పాజ్ చేయవచ్చు, pg_upgrade చేసి, ఆపై పునఃప్రారంభించవచ్చు. మరియు క్లయింట్ వైపు నుండి డేటాబేస్ కేవలం మందగించినట్లు కనిపిస్తుంది. ఈ కార్యాచరణను కమ్యూనిటీకి చెందిన వ్యక్తులు మాకు అందించారు. ఆమె ఇంకా స్తంభింపలేదు, కానీ త్వరలో ప్రతిదీ అవుతుంది. (ఇప్పటికే స్తంభింపజేయబడింది)
- ఇప్పటికే స్తంభింపజేసింది
అదనంగా, PgBouncerలోని కొత్త ఫీచర్లలో ఒకటి SCRAM ప్రమాణీకరణకు మద్దతు, ఇది Yandex.Cloudలో పని చేయని వ్యక్తి ద్వారా కూడా మాకు అందించబడింది. రెండూ క్లిష్టమైన కార్యాచరణ మరియు ముఖ్యమైనవి.
అందువల్ల, మీరు ఇప్పుడు కొద్దిగా కోడ్ రాయాలనుకుంటే, ఒడిస్సీ దేనితో తయారు చేయబడిందో నేను మీకు చెప్పాలనుకుంటున్నాను.
మీరు ఒడిస్సీ మూలాధారాన్ని కలిగి ఉన్నారు, ఇది రెండు ప్రధాన లైబ్రరీలపై ఆధారపడి ఉంటుంది. కివి లైబ్రరీ అనేది పోస్ట్‌గ్రెస్ సందేశ ప్రోటోకాల్ యొక్క అమలు. అంటే, పోస్ట్‌గ్రెస్ యొక్క స్థానిక ప్రోటో 3 అనేది ఫ్రంట్-ఎండ్‌లు మరియు బ్యాక్-ఎండ్‌లు మార్పిడి చేయగల ప్రామాణిక సందేశాలు. అవి కివి లైబ్రరీలో అమలు చేయబడతాయి.
మెషినేరియం లైబ్రరీ అనేది థ్రెడ్ ఇంప్లిమెంటేషన్ లైబ్రరీ. ఈ మెషినారియం యొక్క చిన్న భాగం అసెంబ్లీ భాషలో వ్రాయబడింది. కానీ భయపడవద్దు, కేవలం 15 లైన్లు మాత్రమే ఉన్నాయి.
ఒడిస్సీ ఆర్కిటెక్చర్. ఒక ప్రధాన యంత్రం ఉంది, దానిపై కొరౌటిన్లు నడుస్తున్నాయి. ఈ యంత్రం ఇన్‌కమింగ్ TCP కనెక్షన్‌లను అంగీకరించడం మరియు వాటిని కార్మికుల మధ్య పంపిణీ చేయడం అమలు చేస్తుంది.
అనేక క్లయింట్‌ల కోసం హ్యాండ్లర్ ఒక కార్మికుడిలో పని చేయవచ్చు. పూల్‌లో ఇకపై అవసరం లేని కనెక్షన్‌లను తొలగించడానికి ప్రధాన థ్రెడ్ కన్సోల్ మరియు క్రోన్ టాస్క్‌ల ప్రాసెసింగ్‌ను కూడా అమలు చేస్తుంది.
ఒడిస్సీ ప్రామాణిక పోస్ట్‌గ్రెస్ టెస్ట్ సూట్‌ని ఉపయోగించి పరీక్షించబడుతుంది. మేము కేవలం బౌన్సర్ ద్వారా మరియు ఒడిస్సీ ద్వారా ఇన్‌స్టాల్-చెక్‌ని అమలు చేస్తాము, మేము శూన్య DIVని పొందుతాము. తేదీ ఫార్మాటింగ్‌కు సంబంధించిన అనేక పరీక్షలు బౌన్సర్ మరియు ఒడిస్సీలో సరిగ్గా ఉత్తీర్ణత సాధించవు.
అదనంగా, వారి స్వంత పరీక్షను కలిగి ఉన్న అనేక డ్రైవర్లు ఉన్నారు. మరియు మేము ఒడిస్సీని పరీక్షించడానికి వారి పరీక్షలను ఉపయోగిస్తాము.
అదనంగా, మా క్యాస్కేడ్ కాన్ఫిగరేషన్ కారణంగా, మేము వివిధ బండిల్‌లను పరీక్షించాలి: పోస్ట్‌గ్రెస్ + ఒడిస్సీ, పిజిబౌన్సర్ + ఒడిస్సీ, ఒడిస్సీ + ఒడిస్సీ క్యాస్‌కేడ్‌లోని ఏదైనా భాగాలలో ఒడిస్సీ ముగిసినట్లయితే, అది కూడా పనిచేస్తుందని నిర్ధారించుకోవడానికి. మేము ఆశించినట్లు.
రేక్
మేము ఉత్పత్తిలో ఒడిస్సీని ఉపయోగిస్తాము. మరియు ప్రతిదీ పని చేస్తుందని నేను చెబితే అది సరైంది కాదు. లేదు, అంటే, అవును, కానీ ఎల్లప్పుడూ కాదు. ఉదాహరణకు, ప్రొడక్షన్‌లో ప్రతిదీ ఇప్పుడే పని చేసింది, అప్పుడు PostgreSQL ప్రొఫెషనల్ నుండి మా స్నేహితులు వచ్చి మాకు మెమరీ లీక్ ఉందని చెప్పారు. అవి నిజంగా ఉన్నాయి, మేము వాటిని సరిదిద్దాము. కానీ అది సరళమైనది.
కనెక్షన్ పూలర్‌లో ఇన్‌కమింగ్ TLS కనెక్షన్లు మరియు అవుట్‌గోయింగ్ TLS కనెక్షన్లు ఉన్నాయని మేము కనుగొన్నాము. మరియు కనెక్షన్‌లకు క్లయింట్ సర్టిఫికెట్‌లు మరియు సర్వర్ సర్టిఫికెట్‌లు అవసరం.
బౌన్సర్ మరియు ఒడిస్సీ సర్వర్ సర్టిఫికేట్‌లు వాటి pcache ద్వారా మళ్లీ చదవబడతాయి, అయితే క్లయింట్ సర్టిఫికేట్‌లను pcache నుండి మళ్లీ చదవాల్సిన అవసరం లేదు, ఎందుకంటే మా స్కేలబుల్ ఒడిస్సీ చివరికి ఈ సర్టిఫికేట్‌ను చదవడం ద్వారా సిస్టమ్ పనితీరులో రన్ అవుతుంది. ఇది మాకు ఆశ్చర్యం కలిగించింది, ఎందుకంటే అతను ప్రతిఘటించడానికి ఎక్కువ సమయం పట్టలేదు. మొదట ఇది సరళంగా స్కేల్ చేయబడింది, కానీ 20 ఇన్‌కమింగ్ ఏకకాల కనెక్షన్ల తర్వాత ఈ సమస్య స్వయంగా కనిపించింది.
అంతర్నిర్మిత Lunux సాధనాలను ఉపయోగించి ప్రామాణీకరించగల సామర్థ్యం ప్లగ్ చేయదగిన ప్రమాణీకరణ పద్ధతి. PgBouncerలో ఇది PAM నుండి ప్రతిస్పందన కోసం వేచి ఉండటానికి ప్రత్యేక థ్రెడ్ ఉన్న విధంగా అమలు చేయబడుతుంది మరియు ప్రస్తుత కనెక్షన్‌కు సేవలు అందించే ప్రధాన PgBouncer థ్రెడ్ ఉంది మరియు PAM థ్రెడ్‌లో జీవించమని వారిని అడగవచ్చు.
మేము ఒక సాధారణ కారణం కోసం దీన్ని అమలు చేయలేదు. మాకు చాలా థ్రెడ్‌లు ఉన్నాయి. మనకు ఇది ఎందుకు అవసరం?
మీరు PAM ప్రమాణీకరణ మరియు PAM యేతర ప్రమాణీకరణను కలిగి ఉన్నట్లయితే, PAM ప్రమాణీకరణ యొక్క పెద్ద తరంగం PAM కాని ప్రమాణీకరణను గణనీయంగా ఆలస్యం చేయగలదు. మేము పరిష్కరించని వాటిలో ఇది ఒకటి. కానీ మీరు దాన్ని సరిచేయాలనుకుంటే, మీరు దీన్ని చేయవచ్చు.
మరొక రేక్ ఏమిటంటే, అన్ని ఇన్‌కమింగ్ కనెక్షన్‌లను అంగీకరించే ఒక థ్రెడ్ మా వద్ద ఉంది. ఆపై వారు వర్కర్ పూల్‌కు బదిలీ చేయబడతారు, అక్కడ TLS హ్యాండ్‌షేక్ జరుగుతుంది.
బాటమ్ లైన్, మీరు 20 నెట్‌వర్క్ కనెక్షన్‌లను కలిగి ఉన్నట్లయితే, అవన్నీ ఆమోదించబడతాయి. మరియు క్లయింట్ వైపు libpq సమయం ముగిసింది రిపోర్టింగ్ ప్రారంభమవుతుంది. డిఫాల్ట్‌గా ఇది 000 సెకన్లు ఉన్నట్లు అనిపిస్తుంది.
వారందరూ ఒకే సమయంలో డేటాబేస్‌లోకి ప్రవేశించలేకపోతే, వారు డేటాబేస్‌లోకి ప్రవేశించలేరు, ఎందుకంటే ఇవన్నీ నాన్-ఎక్స్‌పోనెన్షియల్ రీట్రీ ద్వారా కవర్ చేయబడతాయి.
మేము ఆమోదించే TCP కనెక్షన్ల సంఖ్యను మేము థ్రోట్లింగ్ చేసాము అనే వాస్తవంతో మేము PgBouncer నుండి స్కీమ్‌ని ఇక్కడ కాపీ చేసాము అనే నిర్ధారణకు వచ్చాము.
మేము కనెక్షన్‌లను అంగీకరిస్తున్నట్లు చూస్తే, చివరికి వారికి హ్యాండ్‌షేక్ చేయడానికి సమయం లేదు, మేము వాటిని CPU వనరులను వృథా చేయకుండా క్యూలో ఉంచుతాము. ఇది వచ్చిన అన్ని కనెక్షన్‌లకు ఏకకాల హ్యాండ్‌షేక్ నిర్వహించబడకపోవడానికి దారి తీస్తుంది. లోడ్ చాలా ఎక్కువగా ఉన్నప్పటికీ కనీసం ఎవరైనా డేటాబేస్‌లోకి ప్రవేశిస్తారు.
రోడ్మ్యాప్
మీరు ఒడిస్సీలో భవిష్యత్తులో ఏమి చూడాలనుకుంటున్నారు? మనల్ని మనం అభివృద్ధి చేసుకోవడానికి మేము సిద్ధంగా ఉన్నాము మరియు సంఘం నుండి మనం ఏమి ఆశిస్తున్నాము?
ఆగస్టు 2019 నాటికి.
ఆగస్టులో ఒడిస్సీ రోడ్మ్యాప్ ఇలా ఉంది:
- మేము SCRAM మరియు PAM ప్రమాణీకరణను కోరుకున్నాము.
- మేము రీడింగ్ అభ్యర్థనలను స్టాండ్‌బైకి ఫార్వార్డ్ చేయాలనుకుంటున్నాము.
- నేను ఆన్‌లైన్ రీస్టార్ట్ చేయాలనుకుంటున్నాను.
- మరియు సర్వర్‌లో పాజ్ చేయగల సామర్థ్యం.
ఈ రోడ్‌మ్యాప్‌లో సగం పూర్తయింది మరియు మేము కాదు. మరియు ఇది మంచిది. కాబట్టి మిగిలి ఉన్న వాటిని చర్చిద్దాం మరియు మరిన్ని జోడించండి.
? అభ్యర్థనలను అమలు చేయకుండా గాలిని వేడి చేసే ప్రతిరూపాలు మా వద్ద ఉన్నాయి. ఫెయిల్‌ఓవర్ మరియు స్విచ్‌ఓవర్ అందించడం మాకు అవసరం. డేటా సెంటర్లలో ఒకదానిలో సమస్యల విషయంలో, నేను వాటిని కొన్ని ఉపయోగకరమైన పనితో ఆక్రమించాలనుకుంటున్నాను. ఎందుకంటే మనం ఒకే సెంట్రల్ ప్రాసెసర్‌లను, అదే మెమరీని వేర్వేరుగా కాన్ఫిగర్ చేయలేము, లేకపోతే ప్రతిరూపం పనిచేయదు.
సూత్రప్రాయంగా, పోస్ట్‌గ్రెస్‌లో, 10 నుండి ప్రారంభించి, కనెక్ట్ చేసేటప్పుడు సెషన్_అట్‌ర్స్‌ని పేర్కొనడం సాధ్యమవుతుంది. మీరు కనెక్షన్‌లోని అన్ని డేటాబేస్ హోస్ట్‌లను జాబితా చేయవచ్చు మరియు మీరు డేటాబేస్‌కి ఎందుకు వెళ్తున్నారో చెప్పవచ్చు: వ్రాయండి లేదా చదవండి మాత్రమే. మరియు డ్రైవర్ తనకు బాగా నచ్చిన జాబితాలో మొదటి హోస్ట్‌ను ఎంచుకుంటాడు, ఇది సెషన్_అట్‌ర్స్ అవసరాలను తీరుస్తుంది.
కానీ ఈ విధానంలో సమస్య ఏమిటంటే ఇది ప్రతిరూపణ లాగ్‌ను నియంత్రించదు. మీరు మీ సేవ కోసం ఆమోదయోగ్యం కాని సమయానికి వెనుకబడి ఉన్న ప్రతిరూపాన్ని కలిగి ఉండవచ్చు. ప్రతిరూపంలో రీడ్ క్వెరీల పూర్తి-ఫీచర్ ఎగ్జిక్యూషన్‌ని ఎనేబుల్ చేయడానికి, ఒడిస్సీని చదవలేనప్పుడు రన్ చేయకుండా ఉండే సామర్థ్యాన్ని మనం తప్పనిసరిగా సపోర్ట్ చేయాలి.
ఒడిస్సీ తప్పనిసరిగా డేటాబేస్‌కి ఎప్పటికప్పుడు వెళ్లి, ప్రైమరీ నుండి ప్రతిరూపణ దూరాన్ని అడగాలి. మరియు అది పరిమితి విలువను చేరుకున్నట్లయితే, డేటాబేస్‌లోకి కొత్త అభ్యర్థనలను అనుమతించవద్దు, కనెక్షన్‌లను మళ్లీ ప్రారంభించాల్సిన అవసరం ఉందని క్లయింట్‌కు చెప్పండి మరియు అభ్యర్థనలను అమలు చేయడానికి మరొక హోస్ట్‌ని ఎంచుకోండి. ఇది డేటాబేస్ రెప్లికేషన్ లాగ్‌ను త్వరగా పునరుద్ధరించడానికి మరియు అభ్యర్థనతో ప్రతిస్పందించడానికి మళ్లీ తిరిగి రావడానికి అనుమతిస్తుంది.
ఇది ఓపెన్ సోర్స్ అయినందున అమలు కోసం సమయ ఫ్రేమ్ ఇవ్వడం కష్టం. కానీ, నేను PgBouncer నుండి నా సహోద్యోగుల వలె 2,5 సంవత్సరాలు కాదని ఆశిస్తున్నాను. ఇది నేను ఒడిస్సీలో చూడాలనుకుంటున్న లక్షణం.
. ఇప్పుడు మీరు రెండు విధాలుగా సిద్ధం చేసిన ప్రకటనను సృష్టించవచ్చు. మొదట, మీరు SQL ఆదేశాన్ని అమలు చేయవచ్చు, అవి "సిద్ధం". ఈ SQL ఆదేశాన్ని అర్థం చేసుకోవడానికి, మనం బౌన్సర్ వైపు ఉన్న SQLని అర్థం చేసుకోవడం నేర్చుకోవాలి. ఇది ఓవర్ కిల్ అవుతుంది, ఎందుకంటే ఇది ఓవర్ కిల్, ఎందుకంటే మనకు మొత్తం పార్సర్ అవసరం. మేము ప్రతి SQL ఆదేశాన్ని అన్వయించలేము.
కానీ ప్రోటో3లో మెసేజ్ ప్రోటోకాల్ స్థాయిలో సిద్ధమైన ప్రకటన ఉంది. మరియు సిద్ధం చేసిన ప్రకటన సృష్టించబడుతుందనే సమాచారం నిర్మాణాత్మక రూపంలో వచ్చినప్పుడు ఇది స్థలం. మరియు కొన్ని సర్వర్ కనెక్షన్‌లో క్లయింట్ సిద్ధం చేసిన స్టేట్‌మెంట్‌లను సృష్టించమని కోరినట్లు మేము అర్థం చేసుకోవడానికి మద్దతు ఇవ్వగలము. మరియు లావాదేవీ మూసివేయబడినప్పటికీ, మేము ఇప్పటికీ సర్వర్ మరియు క్లయింట్ మధ్య కనెక్టివిటీని నిర్వహించాలి.
కానీ ఇక్కడ డైలాగ్‌లో వైరుధ్యం తలెత్తుతుంది, ఎందుకంటే క్లయింట్ ఎలాంటి సిద్ధం చేసిన స్టేట్‌మెంట్‌లను సృష్టించాడో మీరు అర్థం చేసుకోవాలి మరియు ఈ సర్వర్ కనెక్షన్‌ని సృష్టించిన క్లయింట్‌లందరి మధ్య సర్వర్ కనెక్షన్‌ను పంచుకోవాలి, అంటే అటువంటి సిద్ధం చేసిన స్టేట్‌మెంట్‌ను ఎవరు సృష్టించారు.
మరొక సర్వర్ కనెక్షన్‌లో ఇంతకు ముందే అటువంటి సిద్ధం చేసిన స్టేట్‌మెంట్‌ను సృష్టించిన క్లయింట్ మీ వద్దకు వస్తే, అతని కోసం దాన్ని సృష్టించండి అని ఆండ్రెస్ ఫ్రూండ్ చెప్పారు. క్లయింట్‌కు బదులుగా డేటాబేస్లో ప్రశ్నలను అమలు చేయడం కొంచెం తప్పుగా అనిపిస్తుంది, అయితే డేటాబేస్‌తో పరస్పర చర్య చేయడానికి ప్రోటోకాల్‌ను వ్రాసే డెవలపర్ దృష్టికోణంలో, అతనికి కేవలం నెట్‌వర్క్ కనెక్షన్ ఇచ్చినట్లయితే అది సౌకర్యవంతంగా ఉంటుంది. అటువంటి సిద్ధమైన ప్రశ్న ఉంది.
మరియు మనం అమలు చేయవలసిన మరో ఫీచర్. మేము ఇప్పుడు PgBouncerకు అనుకూలమైన పర్యవేక్షణను కలిగి ఉన్నాము. మేము సగటు ప్రశ్న అమలు సమయాన్ని తిరిగి ఇవ్వగలము. కానీ సగటు సమయం ఆసుపత్రిలో సగటు ఉష్ణోగ్రత: కొన్ని చల్లగా ఉంటాయి, కొన్ని వెచ్చగా ఉంటాయి - సగటున, ప్రతి ఒక్కరూ ఆరోగ్యంగా ఉన్నారు. ఇది నిజం కాదు.
మేము పర్సంటైల్‌లకు మద్దతును అమలు చేయాలి, ఇది వనరులను వృధా చేసే నెమ్మదిగా ప్రశ్నలు ఉన్నాయని మరియు పర్యవేక్షణను మరింత ఆమోదయోగ్యంగా మారుస్తుందని సూచిస్తుంది.
చాలా ముఖ్యమైన విషయం ఏమిటంటే నాకు వెర్షన్ 1.0 కావాలి (వెర్షన్ 1.1 ఇప్పటికే విడుదల చేయబడింది). వాస్తవం ఏమిటంటే ఒడిస్సీ ఇప్పుడు వెర్షన్ 1.0rcలో ఉంది, అనగా విడుదల అభ్యర్థి. మరియు మెమరీ లీక్ మినహా నేను జాబితా చేసిన అన్ని సమస్యలు సరిగ్గా అదే సంస్కరణతో పరిష్కరించబడ్డాయి.
వెర్షన్ 1.0 మనకు అర్థం ఏమిటి? మేము ఒడిస్సీని మా స్థావరాలకు మారుస్తున్నాము. ఇది ఇప్పటికే మా డేటాబేస్‌లలో రన్ అవుతోంది, అయితే ఇది సెకనుకు 1 అభ్యర్థనల స్థాయికి చేరుకున్నప్పుడు, ఇది విడుదల వెర్షన్ మరియు ఇది 000 అని పిలవబడే సంస్కరణ అని చెప్పవచ్చు.
కమ్యూనిటీలోని చాలా మంది వ్యక్తులు వెర్షన్ 1.0లో పాజ్ మరియు SCRAMని చేర్చాలని కోరారు. కానీ దీని అర్థం మేము తదుపరి సంస్కరణను ఉత్పత్తికి విడుదల చేయవలసి ఉంటుంది, ఎందుకంటే SCRAM లేదా పాజ్ ఇంకా చంపబడలేదు. కానీ, చాలా మటుకు, ఈ సమస్య చాలా త్వరగా పరిష్కరించబడుతుంది.
నేను మీ పుల్ అభ్యర్థన కోసం ఎదురు చూస్తున్నాను. బౌన్సర్‌తో మీకు ఎలాంటి సమస్యలు ఉన్నాయో కూడా నేను వినాలనుకుంటున్నాను. వాటిని చర్చిద్దాం. మీకు అవసరమైన కొన్ని ఫంక్షన్‌లను మేము అమలు చేయవచ్చు.
ఇది నా భాగం ముగింపు, నేను మీ మాట వినాలనుకుంటున్నాను. ధన్యవాదాలు!
మీ ప్రశ్నలు
నేను నా స్వంత అప్లికేషన్_పేరును సెట్ చేస్తే, అది ఒడిస్సీలో లావాదేవీ పూలింగ్‌తో సహా సరిగ్గా ఫార్వార్డ్ చేయబడుతుందా?
ఒడిస్సీ లేదా బౌన్సర్?
ఒడిస్సీలో. బౌన్సర్‌లో అది విసిరివేయబడింది.
మేము ఒక సెట్ చేస్తాము.
మరియు నా నిజమైన కనెక్షన్ ఇతర కనెక్షన్‌లపైకి దూసుకెళ్లినట్లయితే, అది ప్రసారం చేయబడుతుందా?
మేము జాబితాలో జాబితా చేయబడిన అన్ని పారామితుల సమితిని చేస్తాము. అప్లికేషన్_పేరు ఈ జాబితాలో ఉందో లేదో నేను చెప్పలేను. నేను అతన్ని అక్కడ చూశానని అనుకుంటున్నాను. మేము అన్ని ఒకే పారామితులను సెట్ చేస్తాము. ఒక అభ్యర్థనతో, ప్రారంభ సమయంలో క్లయింట్ ద్వారా ఇన్‌స్టాల్ చేయబడిన ప్రతిదాన్ని సెట్ చేస్తుంది.
నివేదిక అందించినందుకు ధన్యవాదాలు, ఆండ్రీ! మంచి నివేదిక! ఒడిస్సీ ప్రతి నిమిషం వేగంగా మరియు వేగంగా అభివృద్ధి చెందుతుందని నేను సంతోషిస్తున్నాను. నేను ఇలాగే కొనసాగించాలనుకుంటున్నాను. మేము ఇప్పటికే బహుళ డేటా-సోర్స్ కనెక్షన్‌ని కలిగి ఉండమని మిమ్మల్ని కోరాము, తద్వారా ఒడిస్సీ ఏకకాలంలో వివిధ డేటాబేస్‌లకు కనెక్ట్ చేయగలదు, అంటే మాస్టర్ స్లేవ్, ఆపై వైఫల్యం తర్వాత స్వయంచాలకంగా కొత్త మాస్టర్‌కి కనెక్ట్ అవుతుంది.
అవును, నాకు ఈ చర్చ గుర్తున్నట్లుంది. ఇప్పుడు అనేక నిల్వలు ఉన్నాయి. కానీ వాటి మధ్య మారడం లేదు. మా వైపు, మేము సర్వర్ ఇప్పటికీ సజీవంగా ఉందని పోల్ చేయాలి మరియు వైఫల్యం సంభవించిందని అర్థం చేసుకోవాలి, వారు pg_recovery అని పిలుస్తారు. మేము మాస్టారు వద్దకు రాలేదని నాకు ప్రామాణికమైన అవగాహన ఉంది. మరియు మనం తప్పుల నుండి ఏదో ఒకవిధంగా అర్థం చేసుకోవాలి లేదా ఏది? అంటే, ఆలోచన ఆసక్తికరంగా ఉంది, ఇది చర్చించబడుతోంది. మరిన్ని వ్యాఖ్యలు వ్రాయండి. మీకు సి తెలిసిన కార్మికులు ఉంటే, అది చాలా బాగుంది.
ప్రతిరూపాల అంతటా స్కేలింగ్ సమస్య కూడా మాకు ఆసక్తిని కలిగిస్తుంది, ఎందుకంటే మేము అప్లికేషన్ డెవలపర్‌ల కోసం ప్రతిరూపమైన క్లస్టర్‌ల స్వీకరణను వీలైనంత సులభతరం చేయాలనుకుంటున్నాము. కానీ ఇక్కడ నేను మరిన్ని వ్యాఖ్యలను కోరుకుంటున్నాను, అంటే సరిగ్గా ఎలా చేయాలి, ఎలా బాగా చేయాలి.
ప్రశ్న ప్రతిరూపాల గురించి కూడా. మీకు మాస్టర్ మరియు అనేక ప్రతిరూపాలు ఉన్నాయని తేలింది. మరియు వారు కనెక్షన్ల కోసం మాస్టర్ కంటే తక్కువ తరచుగా ప్రతిరూపానికి వెళతారని స్పష్టమవుతుంది, ఎందుకంటే వారికి తేడాలు ఉండవచ్చు. డేటాలో వ్యత్యాసం మీ వ్యాపారాన్ని సంతృప్తిపరచదని మరియు అది పునరావృతమయ్యే వరకు మీరు అక్కడికి వెళ్లరని మీరు చెప్పారు. అదే సమయంలో, మీరు చాలా కాలం పాటు అక్కడికి వెళ్లకపోతే, ఆపై వెళ్లడం ప్రారంభించినట్లయితే, అవసరమైన డేటా వెంటనే అందుబాటులో ఉండదు. అంటే, మేము నిరంతరం మాస్టర్ వద్దకు వెళితే, అక్కడ కాష్ వేడెక్కుతుంది, కానీ ప్రతిరూపంలో కాష్ కొద్దిగా వెనుకబడి ఉంటుంది.
అవును ఇది నిజం. pcache మీకు కావలసిన డేటా బ్లాక్‌లను కలిగి ఉండదు, నిజమైన కాష్‌లో మీకు కావలసిన పట్టికల గురించి సమాచారం ఉండదు, ప్లాన్‌లలో అన్వయించబడిన ప్రశ్నలు ఉండవు, ఏమీ ఉండవు.
మరియు మీకు ఒక రకమైన క్లస్టర్ ఉన్నప్పుడు మరియు మీరు అక్కడ కొత్త ప్రతిరూపాన్ని జోడించినప్పుడు, అది ప్రారంభమైనప్పుడు, ప్రతిదీ దానిలో చెడ్డది, అనగా అది దాని కాష్‌ని పెంచుతుంది.
నాకు ఆలోచన వచ్చింది. కాష్‌ను వేడెక్కేలా చేసే ప్రతిరూపంపై మొదట చిన్న శాతం ప్రశ్నలను అమలు చేయడం సరైన విధానం. స్థూలంగా చెప్పాలంటే, మేము మాస్టర్ కంటే 10 సెకన్ల కంటే ఎక్కువ వెనుకబడి ఉండాలనే షరతును కలిగి ఉన్నాము. మరియు ఈ పరిస్థితి ఒక వేవ్‌లో చేర్చబడలేదు, కానీ కొంతమంది ఖాతాదారులకు సజావుగా ఉంటుంది.
అవును, బరువు పెంచండి.
ఇది మంచి ఆలోచన. అయితే ముందుగా మనం ఈ షట్‌డౌన్‌ను అమలు చేయాలి. మొదట మనం ఆఫ్ చేయాలి, ఆపై ఎలా ఆన్ చేయాలనే దాని గురించి ఆలోచిస్తాము. సజావుగా ఎనేబుల్ చేయడానికి ఇది గొప్ప ఫీచర్.
Nginxకి ఈ ఎంపిక ఉంది slowly start సర్వర్ కోసం క్లస్టర్‌లో. మరియు అతను క్రమంగా లోడ్ పెంచుతుంది.
అవును, గొప్ప ఆలోచన, మేము దాని గురించి తెలుసుకున్నప్పుడు దీన్ని ప్రయత్నిస్తాము.
మూలం: www.habr.com