د ناکامۍ کلستر PostgreSQL + Patroni. د تطبیق تجربه

په مقاله کې زه به تاسو ته ووایم چې څنګه موږ د PostgreSQL خطا زغم مسلې ته رسیدلي، ولې دا زموږ لپاره مهم شو او په پای کې څه پیښ شوي.

موږ په لوړه کچه بار شوي خدمت لرو: په ټوله نړۍ کې 2,5 ملیون کارونکي ، هره ورځ 50K+ فعال کارونکي. سرورونه د آیرلینډ په یوه سیمه کې په امازون کې موقعیت لري: 100+ مختلف سرورونه په دوامداره توګه په فعالیت کې دي ، چې نږدې 50 یې د ډیټابیسونو سره دي.

بشپړ بیکینډ یو لوی واحد ریاستي جاوا غوښتنلیک دی چې د پیرودونکي سره دوامداره ویب ساکټ اړیکه ساتي. کله چې ډیری کاروونکي په ورته وخت کې په ورته بورډ کې کار کوي، دوی ټول په ریښتیني وخت کې بدلونونه ګوري، ځکه چې موږ هر بدلون ډیټابیس ته لیکو. موږ زموږ ډیټابیسونو ته په هره ثانیه کې شاوخوا 10K غوښتنې لرو. په Redis کې د لوړ بار په وخت کې، موږ په هره ثانیه کې 80-100K غوښتنې لیکو.

ولې موږ له Redis څخه PostgreSQL ته واړوو

په پیل کې، زموږ خدمت د Redis سره کار کاوه، د کلیدي ارزښت پلورنځی چې ټول معلومات د سرور په رام کې ذخیره کوي.

د ریډیس ګټې:

1. د لوړ غبرګون سرعت، ځکه هرڅه په حافظه کې ساتل کیږي؛
2. د بیک اپ او نقل کولو اسانتیا.

زموږ لپاره د ریډیس زیانونه:

1. هیڅ ریښتینې معامله شتون نلري. موږ هڅه وکړه چې دوی زموږ د غوښتنلیک په کچه سمبال کړو. له بده مرغه، دا تل ښه کار نه کوي او د خورا پیچلي کوډ لیکلو ته اړتیا لري.
2. د ډیټا مقدار د حافظې مقدار لخوا محدود دی. لکه څنګه چې د ډیټا مقدار ډیریږي ، حافظه به وده وکړي ، او په پای کې به موږ د ټاکل شوي مثال ځانګړتیاو ته ورسیږو ، کوم چې په AWS کې د مثال ډول بدلولو لپاره زموږ د خدماتو بندولو ته اړتیا لري.
3. دا اړینه ده چې په دوامداره توګه د ټیټ ځنډ کچه وساتئ، ځکه چې. موږ ډیری غوښتنې لرو. زموږ لپاره د ځنډ غوره کچه 17-20 ms ده. د 30-40 ms په کچه، موږ د خپل غوښتنلیک څخه غوښتنو او د خدماتو تخریب ته اوږد ځوابونه ترلاسه کوو. له بده مرغه، دا زموږ سره د سپتمبر په 2018 کې پیښ شو، کله چې د ریډیس سره یو مثال د کوم دلیل لپاره د معمول څخه 2 ځله ډیر ځنډ ترلاسه کړ. د مسلې د حل کولو لپاره، موږ د نیمې ورځې خدمت د غیر ټاکل شوي ساتنې لپاره بند کړ او د ستونزې لرونکي ریډیس مثال یې ځای په ځای کړ.
4. په کوډ کې د کوچنیو غلطیو سره حتی د معلوماتو متناسب ترلاسه کول اسانه دي او بیا د دې معلوماتو سمولو لپاره د کوډ لیکلو ډیر وخت مصرف کړئ.

موږ زیانونه په پام کې ونیول او پوه شو چې موږ اړتیا لرو یو څه ډیر اسانه ته لاړ شو، د عادي معاملو او په ځنډ باندې لږ انحصار سره. څیړنه یې ترسره کړه، ډیری اختیارونه یې تحلیل کړل او PostgreSQL یې غوره کړ.

موږ دمخه د 1,5 کلونو لپاره نوي ډیټابیس ته تللي یو او یوازې د ډیټا یوه کوچنۍ برخه یې لیږدولې ، نو اوس موږ د Redis او PostgreSQL سره یوځای کار کوو. د ډیټابیسونو ترمینځ د ډیټا د حرکت او بدلولو مرحلو په اړه نور معلومات په کې لیکل شوي زما د همکار مقاله.

کله چې موږ لومړی حرکت پیل کړ، زموږ غوښتنلیک په مستقیم ډول د ډیټابیس سره کار وکړ او ماسټر ریډیس او پوسټگری ایس کیو ایل ته یې لاسرسی وموند. د PostgreSQL کلستر د غیر متناسب نقل سره یو ماسټر او نقل لري. دا د ډیټابیس سکیم په څیر ښکاري:

د PgBouncer پلي کول

پداسې حال کې چې موږ حرکت کاوه، محصول هم وده کوله: د کاروونکو شمیر او د سرورونو شمیر چې د PostgreSQL سره کار کوي زیاتوالی موندلی، او موږ د اړیکو نشتوالی پیل کړ. PostgreSQL د هرې اړیکې لپاره جلا پروسه رامینځته کوي او سرچینې مصرفوي. تاسو کولی شئ تر یوې ټاکلې نقطې پورې د ارتباطاتو شمیر زیات کړئ، که نه نو د فرعي غوره ډیټابیس فعالیت ترلاسه کولو فرصت شتون لري. په داسې حالت کې غوره اختیار به د ارتباط مدیر غوره کړي چې د اډې مخې ته ودریږي.

موږ د ارتباط مدیر لپاره دوه اختیارونه درلودل: Pgpool او PgBouncer. مګر لومړی د ډیټابیس سره د کار کولو لیږد موډل ملاتړ نه کوي ، نو موږ PgBouncer غوره کړ.

موږ د کار لاندې سکیم ترتیب کړی دی: زموږ غوښتنلیک یو PgBouncer ته لاسرسی لري، چې تر شا یې د PostgreSQL ماسټران دي، او د هر ماسټر شاته د غیر متناسب نقل سره یو نقل دی.


په ورته وخت کې، موږ نشو کولی په PostgreSQL کې د ډیټا ټوله اندازه ذخیره کړو او د ډیټابیس سره د کار کولو سرعت زموږ لپاره مهم و، نو موږ د غوښتنلیک په کچه د PostgreSQL شارډ کول پیل کړل. پورته ذکر شوی سکیم د دې لپاره نسبتا مناسب دی: کله چې د نوي PostgreSQL شارډ اضافه کړئ، دا د PgBouncer ترتیب تازه کولو لپاره کافي دی او غوښتنلیک کولی شي سمدلاسه د نوي شارډ سره کار وکړي.

د PgBouncer ناکامي

دا سکیم تر هغه وخته پورې کار کاوه کله چې یوازې د PgBouncer مثال مړ شو. موږ په AWS کې یو، چیرې چې ټول مثالونه په هارډویر کې روان دي چې وخت په وخت مړه کیږي. په داسې قضیو کې، مثال په ساده ډول نوي هارډویر ته ځي او بیا کار کوي. دا د PgBouncer سره پیښ شوی، مګر دا شتون نلري. د دې زوال پایله د 25 دقیقو لپاره زموږ د خدماتو نه شتون وه. AWS د داسې حاالتو لپاره د کارونکي اړخ بې ځایه کارولو وړاندیز کوي، کوم چې زموږ په هیواد کې په هغه وخت کې نه و پلي شوی.

له هغې وروسته، موږ د PgBouncer او PostgreSQL کلسترونو د غلطۍ زغم په اړه په جدي توګه فکر وکړ، ځکه چې ورته وضعیت زموږ د AWS حساب کې د هرې بیلګې سره واقع کیدی شي.

موږ د PgBouncer غلطي زغم سکیم په لاندې ډول رامینځته کړی: ټول غوښتنلیک سرورونه د شبکې بار بیلانسر ته لاسرسی لري ، چې شاته دوه PgBouncers شتون لري. هر PgBouncer د هر شارډ ورته PostgreSQL ماسټر ته ګوري. که چیرې د AWS مثال حادثه بیا پیښ شي، ټول ټرافیک د بل PgBouncer له لارې لیږل کیږي. د شبکې بار بیلانس ناکامي د AWS لخوا چمتو کیږي.

دا سکیم د نوي PgBouncer سرورونو اضافه کول اسانه کوي.

د PostgreSQL ناکامۍ کلستر جوړ کړئ

کله چې د دې ستونزې حل کول، موږ مختلف انتخابونه په پام کې نیولي: پخپله لیکل شوي ناکامۍ، repmgr، AWS RDS، Patroni.

پخپله لیکل شوي سکریپټونه

دوی کولی شي د ماسټر کار وڅاري او که دا ناکامه شي نو ماسټر ته نقل ته وده ورکړي او د PgBouncer ترتیب تازه کړي.

د دې طریقې ګټې اعظمي سادگي دي، ځکه چې تاسو پخپله سکریپټونه ولیکئ او په سمه توګه پوهیږئ چې دوی څنګه کار کوي.

ضمیمه:

• شاید ماسټر مړ شوی نه وي، پرځای یې د شبکې ناکامي واقع شوې وي. ناکامي، له دې څخه ناخبره، به ماسټر ته نقل ته وده ورکړي، پداسې حال کې چې زوړ ماسټر به کار ته دوام ورکړي. د پایلې په توګه، موږ به د ماسټر په رول کې دوه سرورونه ترلاسه کړو او موږ به نه پوهیږو چې کوم یو یې تازه تازه معلومات لري. دې حالت ته د سپیټ دماغ هم ویل کیږي.
• موږ بې ځوابه پاتې شو. زموږ په ترتیب کې، ماسټر او یو نقل، د بدلولو وروسته، نقل ماسټر ته حرکت کوي او موږ نور نقلونه نلرو، نو موږ باید په لاسي ډول یو نوی نقل اضافه کړو؛
• موږ د ناکامۍ عملیاتو اضافي څارنې ته اړتیا لرو، پداسې حال کې چې موږ 12 PostgreSQL شارډونه لرو، پدې معنی چې موږ باید د 12 کلسترونو څارنه وکړو. د شارډونو په شمیر کې زیاتوالي سره، تاسو باید د ناکامۍ تازه کول هم په یاد ولرئ.

پخپله لیکل شوی ناکامي خورا پیچلې ښکاري او غیر معمولي ملاتړ ته اړتیا لري. د یو واحد PostgreSQL کلستر سره، دا به ترټولو اسانه انتخاب وي، مګر دا اندازه نه کوي، نو دا زموږ لپاره مناسب نه دی.

Repmgr

د PostgreSQL کلسترونو لپاره د نقل مدیر، کوم چې کولی شي د PostgreSQL کلستر عملیات اداره کړي. په ورته وخت کې ، دا د بکس څخه بهر اتوماتیک ناکامي نلري ، نو د کار لپاره تاسو اړتیا لرئ د بشپړ شوي حل په سر کې خپل "ریپر" ولیکئ. نو هرڅه کولی شي حتی د ځان لیکل شوي سکریپټونو په پرتله خورا پیچلي وګرځي ، نو موږ حتی د Repmgr هڅه نه ده کړې.

AWS RDS

د هر هغه څه ملاتړ کوي چې موږ ورته اړتیا لرو، پوهیږي چې څنګه بیک اپ جوړ کړي او د اړیکو حوض ساتي. دا اتوماتیک سویچنګ لري: کله چې ماسټر مړ شي ، نقل نوی ماسټر کیږي ، او AWS د dns ریکارډ نوي ماسټر ته بدلوي ، پداسې حال کې چې عکسونه په مختلف AZs کې موقعیت کیدی شي.

په زیانونو کې د سم تنظیماتو نشتوالی شامل دي. د ښه ټیوننګ د مثال په توګه: زموږ مثالونه د tcp اړیکو لپاره محدودیتونه لري، کوم چې له بده مرغه په ​​RDS کې نشي ترسره کیدی:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

سربیره پردې، د AWS RDS د عادي مثال قیمت په پرتله نږدې دوه چنده ګران دی، کوم چې د دې حل پریښودلو اصلي دلیل و.

پټروني

دا د ګیتوب په اړه د ښه اسنادو، اتوماتیک ناکامۍ او سرچینې کوډ سره د PostgreSQL اداره کولو لپاره د python ټیمپلیټ دی.

د پټروني ګټې:

• د هر ترتیب پیرامیټر تشریح شوی، دا روښانه ده چې دا څنګه کار کوي؛
• اتوماتیک ناکامي د بکس څخه بهر کار کوي؛
• په python کې لیکل شوي، او دا چې موږ پخپله په python کې ډیر څه لیکو، نو دا به زموږ لپاره اسانه وي چې له ستونزو سره معامله وکړو او شاید حتی د پروژې پراختیا کې مرسته وکړي؛
• په بشپړ ډول د PostgreSQL اداره کوي، تاسو ته اجازه درکوي په یوځل کې د کلستر په ټولو نوډونو کې تنظیمات بدل کړئ، او که کلستر د نوي ترتیب پلي کولو لپاره بیا پیلولو ته اړتیا ولري، نو دا د Patroni په کارولو سره بیا ترسره کیدی شي.

ضمیمه:

• دا د اسنادو څخه روښانه نده چې څنګه د PgBouncer سره په سمه توګه کار وکړي. که څه هم دا سخته ده چې دې ته منفي ووایاست، ځکه چې د پټروني دنده د PostgreSQL اداره کول دي، او څنګه چې پیټروني سره اړیکې به لاړ شي لا دمخه زموږ ستونزه ده؛
• په لویو حجمونو کې د پټروني پلي کولو لږ مثالونه شتون لري، پداسې حال کې چې د پیل څخه د پلي کولو ډیری مثالونه شتون لري.

د پایلې په توګه، موږ Patroni غوره کړه ترڅو د ناکامۍ کلستر جوړ کړي.

د سرپرستي پلي کولو پروسه

د پټروني څخه دمخه ، موږ د یو ماسټر ترتیب کې 12 PostgreSQL شارډونه درلودل او د غیر متناسب نقل سره یو نقل. د اپلیکیشن سرورونو ډیټابیسونو ته د شبکې لوډ بیلانسر له لارې لاسرسی موندلی ، چې تر شا یې د PgBouncer سره دوه مثالونه وو ، او د دوی شاته ټول PostgreSQL سرورونه وو.


د پټروني پلي کولو لپاره، موږ اړتیا درلوده چې د توزیع شوي ذخیره کلستر ترتیب غوره کړو. Patroni د توزیع شوي ترتیب ذخیره کولو سیسټمونو سره کار کوي لکه etcd، Zookeeper، Consul. موږ یوازې په بازار کې د قونسلګرۍ بشپړ کلستر لرو، کوم چې د والټ سره په ګډه کار کوي او موږ یې نور نه کاروو. د خپل ټاکل شوي هدف لپاره د قونسل کارولو پیل کولو عالي دلیل.

Patroni څنګه د قونسل سره کار کوي

موږ د قونسل کلستر لرو، چې درې نوډونه لري، او د پټروني کلستر چې یو مشر او یو نقل لري (په پټروني کې، ماسټر د کلستر مشر بلل کیږي، او غلامان د نقلونو په نوم یادیږي). د پټروني کلستر هره بیلګه په دوامداره توګه قونسل ته د کلستر حالت په اړه معلومات لیږي. له همدې امله ، د قونسل څخه تاسو تل کولی شئ د پټروني کلستر اوسنی ترتیب ومومئ او دا مهال مشر څوک دی.

د پیټروني له قونسل سره د نښلولو لپاره، دا د رسمي اسنادو مطالعه کولو لپاره کافي ده، کوم چې وايي چې تاسو اړتیا لرئ په http یا https بڼه کې کوربه مشخص کړئ، پدې پورې اړه لري چې موږ څنګه د قونسل سره کار کوو، او د ارتباط سکیم، په اختیار کې:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

دا ساده ښکاري، مګر دلته زیانونه پیل کیږي. د قونسل سره، موږ د https له لارې په خوندي پیوستون کار کوو او زموږ د پیوستون ترتیب به داسې ښکاري:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

خو دا کار نه کوي. په پیل کې، پټروني نشي کولی له قونسل سره اړیکه ونیسي، ځکه چې دا هڅه کوي چې په هرصورت http ته لاړ شي.

د پټروني سرچینې کوډ د ستونزې په حل کې مرسته وکړه. ښه خبره دا ده چې په python لیکل شوی. دا معلومه شوه چې کوربه پیرامیټر په هیڅ ډول نه تجزیه کیږي، او پروتوکول باید په سکیم کې مشخص شي. دا د قونسل سره د کار کولو لپاره د کاري ترتیب بلاک زموږ لپاره داسې ښکاري:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

قونسل - کينډۍ

نو، موږ د ترتیب لپاره ذخیره غوره کړې. اوس موږ اړتیا لرو پوه شو چې څنګه PgBouncer به خپل تشکیلات بدل کړي کله چې د پټروني کلستر کې مشر بدل کړي. په اسنادو کې د دې پوښتنې ځواب نشته، ځکه. هلته، په اصولو کې، د PgBouncer سره کار ندی بیان شوی.

د حل په لټه کې، موږ یوه مقاله وموندله (زه له بده مرغه سرلیک په یاد نه لرم) چیرې چې دا لیکل شوي و چې د کنسول ټیمپلیټ د PgBouncer او Patroni په جوړه کولو کې ډیره مرسته کړې. دې کار موږ ته وهڅوله چې وڅیړو چې د قونسل-ټیمپلیټ څنګه کار کوي.

دا معلومه شوه چې Consul-template په دوامداره توګه په قونسل کې د PostgreSQL کلستر تنظیمات څاري. کله چې مشر بدل شي، دا د PgBouncer ترتیب تازه کوي او د بیا پورته کولو لپاره کمانډ لیږي.

د ټیمپلیټ لوی پلس دا دی چې دا د کوډ په توګه زیرمه شوی ، نو کله چې نوی شارډ اضافه کړئ ، نو دا کافي ده چې نوې ژمنې رامینځته کړئ او ټیمپلیټ په اوتومات ډول تازه کړئ ، د کوډ اصول په توګه د زیربنا ملاتړ کوي.

د Patroni سره نوی جوړښت

د پایلې په توګه، موږ د کار لاندې سکیم ترلاسه کړ:


ټول اپلیکیشن سرورونه بیلانسر ته لاسرسی لري → د دې تر شا د PgBouncer دوه مثالونه شتون لري → په هر مثال کې ، قونسل - ټیمپلیټ په لاره اچول شوی ، کوم چې د هر پټروني کلستر حالت څاري او د PgBouncer تشکیل مطابقت څاري ، کوم چې اوسني مشر ته غوښتنې لیږي. د هر کلستر.

لاسي ازموینه

موږ دا سکیم په کوچني ازموینې چاپیریال کې د پیل کولو دمخه پرمخ وړی او د اتوماتیک سویچ کولو عملیات مو چیک کړي. دوی تخته پرانستله، سټیکر یې حرکت وکړ، او په دې وخت کې دوی د کلستر مشر "وژه". په AWS کې، دا د کنسول له لارې د مثال بندولو په څیر ساده دی.

سټیکر په 10-20 ثانیو کې بیرته راستون شو، او بیا یې په نورمال ډول حرکت پیل کړ. دا پدې مانا ده چې د پټروني کلستر په سمه توګه کار کړی: دا مشر بدل کړ، معلومات یې کنسول ته واستول، او کنسول ټیمپلیټ سمدلاسه دا معلومات پورته کړل، د PgBouncer ترتیب یې بدل کړ او د بیا پورته کولو قومانده یې واستوله.

څنګه د لوړ بار لاندې ژوندي پاتې شئ او د ځنډ وخت لږترلږه وساتئ؟

هرڅه په سمه توګه کار کوي! مګر نوې پوښتنې شتون لري: دا به څنګه د لوړ بار لاندې کار وکړي؟ څنګه په چټکۍ او خوندي توګه په تولید کې هرڅه راوباسئ؟

د ازموینې چاپیریال په کوم کې چې موږ د بار ازموینې ترسره کوو موږ سره د لومړۍ پوښتنې ځواب کې مرسته کوي. دا د معمارۍ له مخې تولید ته په بشپړ ډول ورته دی او د ازموینې ډیټا یې رامینځته کړې چې د تولید حجم کې نږدې مساوي وي. موږ پریکړه کوو چې یوازې د ازموینې په جریان کې د PostgreSQL ماسټرانو څخه یو "وژو" او وګورو چې څه پیښیږي. مګر د دې دمخه ، دا مهمه ده چې اتوماتیک رولینګ چیک کړئ ، ځکه چې پدې چاپیریال کې موږ ډیری PostgreSQL شارډونه لرو ، نو موږ به د تولید دمخه د ترتیب سکریپټونو عالي ازموینه ترلاسه کړو.

دواړه دندې لیوالتیا ښکاري، مګر موږ PostgreSQL 9.6 لرو. ایا موږ کولی شو سمدلاسه 11.2 ته لوړ کړو؟

موږ پریکړه کوو چې دا په 2 مرحلو کې ترسره کړو: لومړی 11.2 ته لوړ کړئ، بیا پیټروني پیل کړئ.

PostgreSQL تازه کول

د PostgreSQL نسخه ګړندي تازه کولو لپاره ، اختیار وکاروئ -k، په کوم کې چې په ډیسک کې هارډ لینکونه رامینځته شوي او ستاسو د معلوماتو کاپي کولو ته اړتیا نشته. د 300-400 GB په اډو کې، تازه کول 1 ثانیې وخت نیسي.

موږ ډیری شارډونه لرو، نو اوسمهال باید په اوتومات ډول ترسره شي. د دې کولو لپاره، موږ د ځواب وړ لوبې کتاب لیکلی چې زموږ لپاره د تازه کولو ټوله پروسه اداره کوي:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

دلته دا مهمه ده چې یادونه وکړو چې د اپ گریڈ پیل کولو دمخه، تاسو باید دا د پیرامیټر سره ترسره کړئ -- چکترڅو ډاډ ترلاسه کړئ چې تاسو کولی شئ لوړ کړئ. زموږ سکریپټ د اپ گریڈ دورې لپاره د تشکیلاتو بدیل هم رامینځته کوي. زموږ سکریپټ په 30 ثانیو کې بشپړ شو، کوم چې خورا ښه پایله ده.

Patroni پیل کړئ

د دویمې ستونزې د حل لپاره، یوازې د پټروني ترتیب وګورئ. رسمي ذخیره د initdb سره یو مثال ترتیب لري ، کوم چې د نوي ډیټابیس پیل کولو مسؤلیت لري کله چې تاسو لومړی Patroni پیل کړئ. مګر څنګه چې موږ دمخه چمتو شوی ډیټابیس لرو ، موږ په ساده ډول دا برخه له ترتیب څخه لیرې کړه.

کله چې موږ د پخوانۍ موجوده PostgreSQL کلستر کې Patroni نصب او چلول پیل کړل، موږ یوې نوې ستونزې سره مخ شو: دواړه سرورونه د مشر په توګه پیل شول. پټروني د کلستر لومړني حالت په اړه هیڅ نه پوهیږي او هڅه کوي دواړه سرورونه د ورته نوم سره د دوه جلا کلسترونو په توګه پیل کړي. د دې ستونزې د حل لپاره، تاسو اړتیا لرئ چې په غلام کې د معلوماتو سره ډایرکټر حذف کړئ:

rm -rf /var/lib/postgresql/

دا باید یوازې په غلام ترسره شي!

کله چې یو پاک نقل وصل شي، پیټروني د بیس بیک اپ مشر جوړوي او نقل ته یې بیرته راولي، او بیا د وال لاګونو سره سم اوسني حالت سره نیسي.

یو بل مشکل چې موږ ورسره مخ شو دا دی چې ټول PostgreSQL کلسترونه د ډیفالټ لخوا اصلي نومول شوي. کله چې هر کلستر د بل په اړه هیڅ نه پوهیږي، دا عادي خبره ده. مګر کله چې تاسو غواړئ Patroni وکاروئ، نو ټول کلسترونه باید یو ځانګړی نوم ولري. د حل لاره د PostgreSQL ترتیب کې د کلستر نوم بدلول دي.

بار ازموینه

موږ یوه ازموینه پیل کړې چې په بورډونو کې د کارونکي تجربه تقلید کوي. کله چې بار زموږ اوسط ورځني ارزښت ته ورسید ، موږ ورته ورته ازموینه تکرار کړه ، موږ د PostgreSQL مشر سره یوه بیلګه بنده کړه. اتوماتیک ناکامۍ لکه څنګه چې موږ تمه درلوده کار وکړ: پټروني مشر بدل کړ، د قونسل ټیمپلیټ د PgBouncer ترتیب تازه کړ او د بیا پورته کولو لپاره یې قومانده واستوله. په ګرافانا کې زموږ د ګرافونو له مخې ، دا روښانه وه چې د 20-30 ثانیو ځنډ شتون لري او د ډیټابیس سره د پیوستون پورې اړوند سرورونو څخه لږې غلطۍ شتون لري. دا یو نورمال حالت دی، دا ډول ارزښتونه زموږ د ناکامۍ لپاره د منلو وړ دي او یقینا د خدماتو وخت څخه غوره دي.

د پټروني تولید ته راوړل

د پایلې په توګه، موږ لاندې پلان سره مخ شو:

• د پی جی باونسر سرورونو ته د قونسل ټیمپلیټ ځای په ځای کړئ او لانچ کړئ؛
• PostgreSQL نسخه 11.2 ته تازه کول؛
• د کلستر نوم بدل کړئ؛
• د پټروني کلستر پیل کول.

په ورته وخت کې، زموږ سکیم موږ ته اجازه راکوي چې په هر وخت کې لومړی ټکی جوړ کړو، موږ کولی شو هر PgBouncer په بدل کې له کار څخه لیرې کړو او په هغې کې د قونسل ټیمپلیټ ځای پرځای او چل کړو. نو موږ وکړل.

د ګړندي ګمارلو لپاره ، موږ ځواب ورکوونکی وکاروو ، ځکه چې موږ دمخه د ازموینې چاپیریال کې ټول د لوبو کتابونه ازمویل ، او د بشپړ سکریپټ اجرا کولو وخت د هر شارډ لپاره له 1,5 څخه تر 2 دقیقو پورې و. موږ کولی شو پرته له دې چې زموږ خدمت ودروو هر شی ته په بدل کې هرڅه راوباسئ ، مګر موږ باید د څو دقیقو لپاره هر PostgreSQL بند کړو. په دې حالت کې، هغه کاروونکي چې معلومات یې په دې شارډ کې دي پدې وخت کې په بشپړه توګه کار نشي کولی، او دا زموږ لپاره د منلو وړ ندي.

د دې وضعیت څخه د وتلو لاره پالن شوي ساتنه وه، چې په هر 3 میاشتو کې ترسره کیږي. دا د ټاکل شوي کار لپاره یوه کړکۍ ده، کله چې موږ خپل خدمت په بشپړه توګه وتړو او زموږ د ډیټابیس مثالونه لوړ کړو. بلې کړکۍ ته یوه اونۍ پاتې وه، او موږ پریکړه وکړه چې یوازې انتظار وکړو او نور چمتو کړو. د انتظار وخت په جریان کې، موږ اضافي ځان خوندي کړ: د هر PostgreSQL شارډ لپاره، موږ د وروستي معلوماتو ساتلو کې د ناکامۍ په صورت کې یو اضافي نقل پورته کړ، او د هر شارډ لپاره یې یو نوی مثال اضافه کړ، کوم چې باید د پټروني کلستر کې یو نوی نقل شي، د دې لپاره چې د معلوماتو حذف کولو قوماندې اجرا نه کړي. دا ټول د خطا خطر کمولو کې مرسته وکړه.


موږ خپل خدمت بیا پیل کړ، هرڅه لکه څنګه چې باید کار وکړي، کاروونکو کار کولو ته دوام ورکړ، مګر په ګرافونو کې موږ د قونسل سرورونو کې غیر معمولي لوړ بار ولیدل.


ولې موږ دا د ازموینې چاپیریال کې ونه لید؟ دا ستونزه خورا ښه روښانه کوي چې دا اړینه ده چې د کوډ اصولو په توګه زیربنا تعقیب کړئ او د ازموینې چاپیریال څخه تولید ته ټول زیربنا پاک کړئ. که نه نو، دا خورا اسانه ده چې هغه ستونزه چې موږ یې ترلاسه کړې. څه شوي دي؟ قونسل لومړی په تولید کې ښکاره شو، او بیا د ازموینې چاپیریال کې، د پایلې په توګه، د ازموینې چاپیریال کې، د قونسل نسخه د تولید په پرتله لوړه وه. یوازې په یوه ریلیز کې ، د CPU لیک حل شوی و کله چې د قونسل ټیمپلیټ سره کار کول. له همدې امله، موږ په ساده ډول قونسل تازه کړ، پدې توګه ستونزه حل شوه.

د Patroni کلستر بیا پیل کړئ

په هرصورت، موږ یوه نوې ستونزه ترلاسه کړه، کوم چې موږ یې شک هم نه درلود. کله چې قونسل تازه کوو، موږ په ساده ډول د قونسل نوډ د قونسل رخصت کمانډ په کارولو سره له کلستر څخه لرې کوو مګر کله چې موږ د قونسل کلستر وروستي مثال ته ورسیدو او د قونسل رخصتۍ قومانده یې ورته واستوله، د پټروني ټول کلسترونه په ساده ډول بیا پیل شول، او په لاګونو کې موږ لاندې تېروتنه ولیدله:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

د پټروني کلستر ونه توانید چې د خپل کلستر په اړه معلومات ترلاسه کړي او بیا پیل شو.

د حل موندلو لپاره، موږ د ګیتوب په اړه د یوې مسلې له لارې د پټروني لیکوالانو سره اړیکه ونیوله. دوی زموږ د تشکیلاتو فایلونو ته د پرمختګ وړاندیز وکړ:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

موږ وکولی شو ستونزه د ازموینې چاپیریال کې تکرار کړو او دا اختیارونه یې هلته ازمویل ، مګر له بده مرغه دوی کار ونکړ.

ستونزه لا هم حل شوې نه ده. موږ پلان لرو چې لاندې حلونه هڅه وکړو:

• د پټروني کلستر په هر مثال کې د قونسل اجنټ څخه کار واخلئ؛
• په کوډ کې مسله حل کړئ.

موږ پوهیږو چې خطا چیرې رامینځته شوې: ستونزه شاید د ډیفالټ وخت پای کارول وي ، کوم چې د ترتیب کولو فایل له لارې نه پټیږي. کله چې د قونسل وروستی سرور د کلستر څخه لیرې شي، د قونسل کلستر ټول د یوې ثانیې څخه زیات ځړول کیږي، د دې له امله، پټروني نشي کولی د کلستر حالت ترلاسه کړي او په بشپړه توګه ټول کلستر بیا پیل کړي.

خوشبختانه، موږ د نورو غلطیو سره مخ نه شو.

د Patroni کارولو پایلې

د پټروني له بریالي پیل وروسته، موږ په هر کلستر کې یو اضافي نقل اضافه کړ. اوس په هر کلستر کې د کورم یوه بیلګه شتون لري: یو مشر او دوه نقلونه، د خوندیتوب جال لپاره د سپیټ دماغ په حالت کې کله چې بدلیږي.


پټروني له دریو میاشتو راهیسې په تولید کار کوي. د دې وخت په جریان کې، هغه لا دمخه زموږ سره مرسته کړې ده. په دې وروستیو کې، د یو کلستر مشر په AWS کې مړ شو، اتوماتیک ناکامي کار وکړ او کاروونکو کار ته دوام ورکړ. پټروني خپله اصلي دنده سرته ورسوله.

د Patroni کارولو یوه کوچنۍ لنډیز:

• د تشکیلاتو د بدلونونو اسانتیا. دا کافي ده چې په یو مثال کې ترتیب بدل کړئ او دا به ټول کلستر ته راښکته شي. که د نوي ترتیب پلي کولو لپاره ریبوټ ته اړتیا وي، نو پټروني به تاسو ته خبر درکړي. پټروني کولی شي ټول کلستر د یو واحد کمانډ سره بیا پیل کړي، کوم چې خورا اسانه دی.
• اتوماتیک ناکامي کار کوي او دمخه یې زموږ سره مرسته کړې.
• PostgreSQL د اپلیکیشن بند وخت پرته تازه کول. تاسو باید لومړی عکسونه نوي نسخه ته تازه کړئ، بیا د پټروني کلستر کې مشر بدل کړئ او زاړه مشر تازه کړئ. په دې حالت کې، د اتوماتیک ناکامۍ اړین ازموینه ترسره کیږي.

سرچینه: www.habr.com