د پټروني ناکامۍ کیسې یا ستاسو د PostgreSQL کلستر د کریش کولو څرنګوالی. الیکسي لیسوفسکي

د Patroni اصلي هدف د PostgreSQL لپاره لوړ شتون چمتو کول دي. مګر پټروني یوازې یوه نمونه ده، نه چمتو شوې وسیله (کوم چې په عمومي توګه په اسنادو کې ویل کیږي). په لومړي نظر کې ، د ازموینې لابراتوار کې پټروني تنظیم کول ، تاسو کولی شئ وګورئ چې دا څومره عالي وسیله ده او دا زموږ د کلستر ماتولو هڅې څومره په اسانۍ اداره کوي. په هرصورت، په عمل کې، د تولید چاپیریال کې، هر څه تل ​​د ازموینې لابراتوار په څیر په ښکلي او ښکلي ډول نه پیښیږي.

زه به تاسو ته د خپل ځان په اړه لږ څه ووایم. ما د سیسټم مدیر په توګه پیل وکړ. د ویب پرمختیا کې کار کړی. زه د 2014 راهیسې په ډیټا ایګریټ کې کار کوم. شرکت د Postgres په ساحه کې په مشورې بوخت دی. او موږ په سمه توګه د پوسټګریس خدمت کوو، او موږ هره ورځ د پوسټګریس سره کار کوو، نو موږ د عملیاتو پورې اړوند مختلف مهارتونه لرو.

او د 2018 په پای کې، موږ ورو ورو د پټروني کارول پیل کړل. او ځینې تجربې راټولې شوې. موږ دا یو څه تشخیص کړل، دا یې تنظیم کړل، زموږ غوره کړنو ته راغلل. او په دې راپور کې به یې په اړه خبرې وکړم.

د پوسټګریس سربیره ، زه لینکس خوښوم. زه خوښوم چې شاوخوا یې وخورئ او وپلټم، زه د کور راټولول خوښوم. زه مجازی کول، کانټینرونه، ډاکر، کوبرنیټس خوښوم. دا ټول زما سره علاقه لري، ځکه چې د ادارې زاړه عادتونه اغیزه کوي. زه د څارنې سره معامله کول خوښوم. او زه د ادارې پورې اړوند پوسټګریس شیان خوښوم ، د بیلګې په توګه نقل ، بیک اپ. او زما په فارغ وخت کې زه په Go کې لیکم. زه د سافټویر انجنیر نه یم، زه یوازې د ځان لپاره په Go کې لیکم. او دا ماته خوښي راکوي.

• زه فکر کوم چې ستاسو څخه ډیری پوهیږي چې پوسټګریس د بکس څخه بهر HA (لوړ شتون) نلري. د HA ترلاسه کولو لپاره، تاسو اړتیا لرئ یو څه نصب کړئ، تنظیم یې کړئ، هڅه وکړئ او ترلاسه کړئ.
• ډیری وسیلې شتون لري او پټروني یو له دوی څخه دی چې HA خورا ښه او خورا ښه حل کوي. مګر دا ټول د ازموینې لابراتوار کې ایښودلو او په چلولو سره ، موږ کولی شو وګورو چې دا ټول کار کوي ، موږ کولی شو ځینې ستونزې بیا تولید کړو ، وګورو چې پټروني دوی ته څنګه خدمت کوي. او موږ به وګورو چې دا ټول ښه کار کوي.
• مګر په عمل کې، موږ د بیلابیلو ستونزو سره مخ یو. او زه به د دې ستونزو په اړه خبرې وکړم.
• زه به تاسو ته ووایم چې موږ دا څنګه تشخیص کړ، څه چې موږ ټیک کړي - ایا دا زموږ سره مرسته کړې که نه.

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

او یو کوچنی اعلان مخکې له دې چې موږ خپل راپور پیل کړو.

دا ټولې ستونزې چې موږ ورسره مخ وې، موږ یې د عملیاتو په لومړیو 6-7-8 میاشتو کې درلودې. د وخت په تیریدو سره، موږ خپل داخلي غوره کړنو ته راغلو. او زموږ ستونزې له منځه ولاړې. له همدې امله ، راپور شاوخوا شپږ میاشتې دمخه اعلان شو ، کله چې دا ټول زما په سر کې تازه و او ما دا ټول په بشپړ ډول یاد کړل.

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

Patroni څه شی دی؟

• دا د HA جوړولو لپاره یوه نمونه ده. دا هغه څه دي چې دا په اسنادو کې وايي. او زما له نظره، دا یو ډیر درست وضاحت دی. پټروني د سپینو زرو ګولۍ نه ده چې ستاسو ټولې ستونزې به حل کړي، دا دی، تاسو اړتیا لرئ چې د کار کولو لپاره هڅه وکړئ او ګټې ترلاسه کړئ.
• دا د اجنټ خدمت دی چې په هر ډیټابیس خدمت کې نصب شوی او ستاسو د پوسټګریس لپاره یو ډول init سیسټم دی. دا پوسټګریس پیل کوي، ودریږي، بیا پیل کوي، بیا تنظیموي، او ستاسو د کلستر ټوپولوژي بدلوي.
• په دې اساس، د کلستر حالت ذخیره کولو لپاره، د دې اوسني استازیتوب، لکه څنګه چې ښکاري، یو ډول ذخیره ته اړتیا ده. او له همدې ځایه پټروني په یوه بهرني نظام کې د دولت د ساتلو لاره خپله کړه. دا د توزیع شوي ترتیب ذخیره کولو سیسټم دی. دا کیدی شي Etcd، Consul، ZooKeeper، یا kubernetes Etcd وي، د بیلګې په توګه د دې اختیارونو څخه یو.
• او د پټروني یوه ځانګړتیا دا ده چې تاسو د بکس څخه آټوفیلر ترلاسه کوئ، یوازې د هغې په ترتیب کولو سره. که موږ د پرتله کولو لپاره Repmgr واخلو ، نو فایلر پکې شامل دی. د Repmgr سره، موږ یو سویچ اوور ترلاسه کوو، مګر که موږ یو اتومات فایلر غواړو، نو موږ اړتیا لرو چې دا نور هم تنظیم کړو. پټروني لا دمخه د بکس څخه یو اتوماتیک فایل لري.
• او داسې نور ډیر څه دي. د مثال په توګه، د تشکیلاتو ساتنه، د نوي نقلونو ډکول، بیک اپ، او داسې نور. مګر دا د راپور له دائرې څخه بهر دی، زه به یې په اړه خبرې ونه کړم.

او یوه کوچنۍ پایله دا ده چې د پټروني اصلي دنده دا ده چې یو اتومات فایل په ښه او معتبر ډول ترسره کړي ترڅو زموږ کلستر فعال پاتې شي او غوښتنلیک د کلستر ټوپولوژي کې بدلونونه ونه ګوري.

مګر کله چې موږ د Patroni کارول پیل کړو، زموږ سیسټم یو څه نور پیچلی کیږي. که مخکې موږ Postgres درلود، نو کله چې د Patroni په کارولو سره موږ پخپله Patroni ترلاسه کوو، موږ DCS ترلاسه کوو چیرې چې ریاست ذخیره کیږي. او دا ټول باید په یو ډول کار وکړي. نو څه شی غلط کیدی شي؟

مات کیدی شي:

• پوسټګریس ممکن مات شي. دا یو ماسټر یا نقل کیدی شي، یو له دوی څخه ناکام شي.
• پټروني پخپله مات کیدی شي.
• DCS چیرې چې حالت زیرمه کیږي ممکن مات شي.
• او شبکه ماتولی شي.

دا ټول ټکي به زه په راپور کې په پام کې ونیسم.

زه به قضیې په پام کې ونیسم ځکه چې دوی خورا پیچلي کیږي ، نه له دې نظره چې قضیه ډیری برخې لري. او د موضوعي احساساتو له نظره، چې دا قضیه زما لپاره ستونزمنه وه، د هغې جلا کول ستونزمن وو ... او برعکس، ځینې قضیه روښانه وه او د هغې جلا کول اسانه وو.

او لومړۍ قضیه ترټولو اسانه ده. دا هغه قضیه ده کله چې موږ د ډیټابیس کلستر واخیست او زموږ د DCS ذخیره یې په ورته کلستر کې ځای په ځای کړه. دا تر ټولو عام تېروتنه ده. دا د معمارۍ په جوړولو کې تېروتنه ده، د بیلګې په توګه، په یو ځای کې د مختلفو اجزاوو یوځای کول.

نو، یو فایلر و، راځئ چې د هغه څه سره معامله وکړو چې څه پیښ شوي.

او دلته موږ علاقه لرو چې فایلر کله پیښ شو. دا دی، موږ په دې وخت کې لیوالتیا لرو کله چې د کلستر حالت بدل شو.

مګر فایلر تل سمدستي نه وي، د بیلګې په توګه دا د وخت هیڅ واحد نه اخلي، دا ځنډیدلی شي. دا کیدی شي اوږدمهاله وي.

نو ځکه، دا د پیل وخت او د پای وخت لري، یعنی دا یوه دوامداره پیښه ده. او موږ ټولې پیښې په دریو وقفو ویشو: موږ د فایلر څخه دمخه وخت لرو ، د فایلر پرمهال او د فایلر وروسته. دا، موږ په دې مهال ویش کې ټولې پیښې په پام کې نیسو.

او لومړی شی، کله چې یو فایلر پیښ شو، موږ د هغه څه لامل وګورو چې څه پیښ شوي، د هغه څه لامل و چې د فایلر لامل شو.

که موږ لاګونو ته وګورو ، نو دا به د کلاسیک پټروني لاګونه وي. هغه موږ ته په دوی کې وايي چې سرور ماسټر شو، او د ماسټر رول دې نوډ ته رسیدلی. دلته دا روښانه شوې ده.

بیا، موږ اړتیا لرو پوه شو چې فایلر ولې پیښ شو، د بیلګې په توګه کومې پیښې رامنځ ته شوي چې د ماسټر رول له یو نوډ څخه بل ته لیږدول کیږي. او په دې حالت کې، هرڅه ساده دي. موږ د ذخیره کولو سیسټم سره په تعامل کې تېروتنه لرو. ماسټر پوه شو چې هغه نشي کولی د DCS سره کار وکړي، دا د متقابل عمل سره یو ډول ستونزه وه. او هغه وايي چې نور نشي کولی ماسټر پاتې شي او استعفا ورکړي. دا کرښه "ځان تخریب شوی" دقیقا ورته وايي.

که موږ د فایلر څخه دمخه پیښو ته وګورو، موږ کولی شو هلته هغه دلیلونه وګورو چې د وزرډ ته دوام ورکولو کې د ستونزې لامل شوی.

که موږ د Patroni logs ته وګورو، نو موږ به وګورو چې موږ ډیری غلطۍ لرو، وخت پای ته رسیدلی، د بیلګې په توګه د Patroni اجنټ نشي کولی د DCS سره کار وکړي. پدې حالت کې، دا د قونسل اجنټ دی، کوم چې په 8500 بندر کې اړیکه نیسي.

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

یو څه وخت وروسته، کله چې بار کم شو، زموږ سرپرست وتوانید چې د استازو سره بیا اړیکه ونیسي. عادي کار بیا پیل شو. او ورته Pgdb-2 سرور بیا ماسټر شو. دا دی، یو کوچنی فلپ و، چې له امله یې نوډ د ماسټر واکونه استعفا ورکړه، او بیا یې بیرته واخیست، دا دی، هر څه بیرته راستانه شوي لکه څنګه چې وو.

او دا د غلط الارم په توګه ګڼل کیدی شي، یا دا په پام کې نیول کیدی شي چې پټروني هرڅه سم کړي. دا، هغه پوه شو چې هغه نشي کولی د کلستر حالت وساتي او خپل واک یې لیرې کړ.

او دلته ستونزه د دې حقیقت له امله رامینځته شوې چې د قونسل سرورونه د اډو په څیر ورته هارډویر کې دي. په دې اساس، کوم بار: که دا په ډیسکونو یا پروسیسرونو کې بار وي، دا د قونسل کلستر سره تعامل هم اغیزه کوي.

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

د یو اختیار په توګه، تاسو کولی شئ پیرامیټونه ttl، loop_wait، retry_timeout، د بیلګې په توګه د دې پیرامیټرو په زیاتولو سره د دې لنډ مهاله بار بارونو ژوندي کولو هڅه وکړئ. مګر دا ترټولو مناسب انتخاب ندی، ځکه چې دا بار په وخت کې اوږد کیدی شي. او موږ به په ساده ډول د دې پیرامیټونو له دې حدودو هاخوا لاړ شو. او دا ممکن واقعیا مرسته ونکړي.

لومړۍ ستونزه، لکه څنګه چې تاسو پوهیږئ، ساده ده. موږ DCS د اډې سره یو ځای ونیولو، موږ ستونزه درلوده.

دویمه ستونزه د لومړي سره ورته ده. دا په ورته ډول دی چې موږ بیا د DCS سیسټم سره د مداخلې ستونزې لرو.

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

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

دلته موږ باید هغه ځای پیدا کړو چې د فایلر څخه مخکې دی، د بیلګې په توګه هغه تېروتنې چې موږ یې د فایلر درلودلو لامل شوي. او پدې برخه کې، د پټروني لاګونه د کار کولو لپاره خورا مناسب دي. هغه په ​​یو ټاکلي وخت کې ورته پیغامونه لیکي. او که موږ د دې لاګونو له لارې په چټکۍ سره سکرول پیل کړو، نو موږ به د لاګونو څخه وګورو چې لاګونه بدل شوي، پدې معنی چې ځینې ستونزې پیل شوي. موږ ژر تر ژره دې ځای ته راستانه شو، وګورو چې څه پیښیږي.

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

او هغه ځای ته سکرول کولو سره چیرې چې خطاګانې څرګندیدل پیل شوي ، موږ ګورو چې موږ یو اتومات فایل اوور درلود. او له هغه وخته چې زموږ تېروتنې د DCS سره د تعامل سره تړاو درلود او زموږ په قضیه کې موږ قونسل کارولی و، موږ د قونسل لاګونو ته هم ګورو چې هلته څه پیښ شوي.

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

او که تاسو د نورو قونسل اجنټانو لاګونو ته هم وګورئ ، تاسو دا هم لیدلی شئ چې د شبکې یو ډول سقوط هلته پیښیږي. او د قونسل کلستر ټول غړي د یو بل په شتون شک لري. او دا د فایلر لپاره هڅونه وه.

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

ترټولو ساده ځواب د شبکې ترمیم کول دي. مګر زما لپاره ، په پوډیم کې ولاړ ، دا ویل اسانه دي. مګر شرایط داسې دي چې تل پیرودونکي نشي کولی د شبکې ترمیم کړي. هغه ممکن په DC کې ژوند وکړي او ممکن د شبکې ترمیم کولو توان ونلري، تجهیزات اغیزمن کړي. او له همدې امله ځینې نورو اختیارونو ته اړتیا ده.

اختیارونه شتون لري:

• ترټولو ساده اختیار، چې لیکل شوی، زما په نظر، حتی په اسنادو کې، د قونسل چکونو غیر فعال کول دي، دا دی، په ساده ډول یو خالي صف تیر کړئ. او موږ د قونسل اجنټ ته وایو چې هیڅ چک ونه کاروي. د دې چکونو سره، موږ کولی شو د دې شبکې طوفانونه له پامه غورځوو او فایلر پیل نه کړو.
• بله اختیار د raft_multiplier دوه ځله چیک کول دي. دا پخپله د قونسل سرور پیرامیټر دی. په ډیفالټ ډول، دا 5 ته ټاکل شوی. دا ارزښت د سټینګ چاپیریال لپاره د اسنادو لخوا وړاندیز شوی. په حقیقت کې، دا د قونسل شبکې غړو ترمنځ د پیغام رسولو فریکونسۍ اغیزه کوي. په حقیقت کې، دا پیرامیټر د قونسل کلستر د غړو ترمنځ د خدماتو اړیکو سرعت اغیزه کوي. او د تولید لپاره، دا دمخه سپارښتنه کیږي چې دا کم کړي ترڅو نوډونه ډیر ځله پیغامونه تبادله کړي.
• بل انتخاب چې موږ ورسره مخ یو د عملیاتي سیسټم پروسې مهالویش لپاره د نورو پروسو په مینځ کې د قونسل پروسې لومړیتوب لوړول دي. داسې یو "ښه" پیرامیټر شتون لري، دا یوازې د پروسو لومړیتوب ټاکي چې د مهالویش کولو پر مهال د OS مهالویش لخوا په پام کې نیول کیږي. موږ د قونسل اجنټانو لپاره ښه ارزښت هم کم کړی دی، د بیلګې په توګه. لومړیتوب ډیر کړی ترڅو عملیاتي سیسټم د قونسل پروسې ته د کار کولو او د دوی کوډ پلي کولو لپاره ډیر وخت ورکړي. زموږ په قضیه کې، دا زموږ ستونزه حل کړه.
• بله لاره دا ده چې د قونسل څخه کار وانخلي. زه یو ملګری لرم چې د Etcd لوی ملاتړی دی. او موږ په منظمه توګه د هغه سره بحث کوو چې غوره Etcd یا قونسل دی. مګر پدې شرایطو کې چې کوم غوره دی ، موږ معمولا د هغه سره موافق یو چې قونسل یو اجنټ لري چې باید په هر نوډ کې د ډیټابیس سره پرمخ ولاړ شي. دا، د قونسل کلستر سره د Patroni تعامل د دې اجنټ له لارې تیریږي. او دا اجنټ یو خنډ کیږي. که چیرې اجنټ ته څه پیښ شي، نو پټروني نور نشي کولی د قونسل کلستر سره کار وکړي. او دا ستونزه ده. د Etcd پلان کې هیڅ استازی شتون نلري. پټروني کولی شي مستقیم د Etcd سرورونو لیست سره کار وکړي او دمخه د دوی سره اړیکه ونیسي. پدې برخه کې ، که تاسو په خپل شرکت کې Etcd وکاروئ ، نو Etcd به شاید د قونسل څخه غوره انتخاب وي. مګر موږ په خپلو پیرودونکو کې تل د هغه څه له مخې محدود یو چې پیرودونکي غوره کړي او کاروي. او موږ د ټولو پیرودونکو لپاره د ډیری برخې لپاره قونسل لرو.
• او وروستی ټکی د پیرامیټر ارزښتونو بیاکتنه ده. موږ کولی شو دا پیرامیټونه په دې امید کې لوړ کړو چې زموږ د شبکې لنډمهاله ستونزې به لنډې وي او د دې پیرامیټونو له حد څخه بهر نه راوتلي. په دې توګه موږ کولی شو د پټروني تیریدل په اتوماتیک فایل کې کم کړو که چیرې د شبکې ځینې ستونزې رامینځته شي.

زه فکر کوم چې ډیری څوک چې پیټروني کاروي د دې قوماندې سره بلد دي.

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

په دې اساس، یو اتومات فایل شتون درلود. او د دې آٹو فایل وروسته، زموږ نقل ورک شو. موږ اړتیا لرو چې معلومه کړو چې هغه ولې ورکه شوه او بیرته یې راوړو، بیرته یې راوړو. او موږ بیا لاګ ته ځو او وګورو چې ولې موږ د آټو فایل اوور درلود.

په دې حالت کې، دوهم نقل ماسټر شو. دلته هرڅه سم دي.

او موږ اړتیا لرو هغه نقل وګورو چې راوتلی او کوم چې په کلستر کې ندي. موږ د Patroni logs خلاصوو او ګورو چې موږ د pg_rewind مرحله کې د کلستر سره د وصل کولو پروسې په جریان کې ستونزه درلوده. د کلستر سره د نښلولو لپاره، تاسو اړتیا لرئ د لیږد لاګ بیرته راوباسئ، د ماسټر څخه د اړین لیږد لاګ غوښتنه وکړئ، او د ماسټر سره د نیولو لپاره یې وکاروئ.

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

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

ما د وخت سټیمپونه پرتله کړل کله چې دا پیښې پیښ شوي. او دلته توپیر په حقیقت کې 150 ملیسیکنډ دی، دا دی، پوسته په 369 ملی ثانیو کې بشپړه شوې، د WAL برخې نومول شوی. او په حقیقت کې په 517 کې، د 150 ملی ثانیو وروسته، په زاړه نقل کې بیا پیل شو. دا په حقیقت کې زموږ لپاره 150 ملی ثانوي کافي و ترڅو نقل نشي کولی وصل شي او عاید ترلاسه کړي.

اختیارونه څه دي؟

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

مګر دلته یوه ستونزه شتون لري، کله چې ماسټر نقل ته ځي، دا سلاټونه حذف کوي او د سلاټونو سره د WAL برخې حذف کوي. او د دې ستونزې له منځه وړلو لپاره، موږ پریکړه وکړه چې د wal_keep_segments پیرامیټر لوړ کړو. دا په 8 برخو کې ډیفالټ دی. موږ دا 1 ته پورته کړه او وګورو چې موږ څومره وړیا ځای لرو. او موږ د wal_keep_segments لپاره 000 ګیګابایټ مرسته وکړه. دا دی ، کله چې سویچ کول ، موږ تل په ټولو نوډونو کې د 16 ګیګابایټ لیږد لاګ ذخیره لرو.

او پلس - دا لاهم د اوږدې مودې ساتنې دندو لپاره اړین دی. راځئ چې ووایو موږ اړتیا لرو یو له نقلونو څخه تازه کړو. او موږ غواړو چې دا بند کړو. موږ اړتیا لرو چې سافټویر تازه کړو، شاید عملیاتي سیسټم، بل څه. او کله چې موږ یو نقل بند کړو، د دې نقل لپاره سلاټ هم لرې کیږي. او که موږ یو کوچنی وال_کیپ_سګمینټ وکاروو، نو د نقل اوږد نه شتون سره، د لیږد لاګونه به ورک شي. موږ به یو نقل راپورته کړو ، دا به د هغه لیږد لاګونو غوښتنه وکړي چیرې چې دا ودریږي ، مګر دوی ممکن په ماسټر کې نه وي. او نقل به هم ونه شي کولی چې وصل شي. له همدې امله، موږ د مجلو لوی ذخیره ساتو.

موږ د تولید اساس لرو. دلته لا دمخه پروژې شتون لري.

یو فایلر وو. موږ دننه لاړو او وګورو - هرڅه سم دي، نقلونه په ځای دي، د نقل کولو ځنډ شتون نلري. په لاګونو کې هیڅ غلطی شتون نلري، هرڅه په ترتیب کې دي.

د محصول ټیم ​​وايي چې باید یو څه ډاټا وي، مګر موږ دا د یوې سرچینې څخه ګورو، مګر موږ دا په ډیټابیس کې نه ګورو. او موږ باید پوه شو چې د دوی سره څه پیښ شوي.

دا روښانه ده چې pg_rewind دوی له لاسه ورکړي. موږ سمدلاسه په دې پوه شو، خو لاړو چې څه پیښیږي.

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

زموږ زوړ ماسټر ریبوټ شو. او Patroni په autorun کې ثبت شو. Patroni په لاره واچول. هغه بیا پوسټګریس پیل کړ. په ډیر دقت سره، د پوسټګریس پیل کولو دمخه او د هغې د نقل کولو دمخه، پټروني د pg_rewind پروسه پیل کړه. په دې اساس، هغه د راکړې ورکړې د لوګو یوه برخه پاکه کړه، نوي یې ډاونلوډ او وصل کړل. دلته پټروني په هوښیارۍ سره کار وکړ، لکه څنګه چې تمه کیده. کلستر بیا رغول شوی دی. موږ 3 نوډونه درلودل، د فایلر 3 نوډونو وروسته - هرڅه ښه دي.

موږ ځینې معلومات له لاسه ورکړي دي. او موږ باید پوه شو چې موږ څومره له لاسه ورکړی دی. موږ یوازې د هغه شیبې په لټه کې یو کله چې موږ بیرته راګرځیده. موږ کولی شو دا په داسې ژورنالونو کې ومومئ. بیرته پیل شو، هلته یې یو څه وکړل او پای ته ورسید.

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

موږ معمول pg_wal_lsn_diff اخلو او دا دوه نښې پرتله کوو. او په دې حالت کې، موږ 17 میګابایټ ترلاسه کوو. ډیر یا لږ، هرڅوک د ځان لپاره پریکړه کوي. ځکه چې د یو چا لپاره 17 میګابایټ ډیر ندی، د یو چا لپاره دا ډیر او د منلو وړ نه دی. دلته، هر فرد د سوداګرۍ اړتیاوو سره سم د ځان لپاره ټاکي.

مګر موږ د ځان لپاره څه موندلي؟

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

او یوازې له هغې وروسته موږ باید پریکړه وکړو چې ایا موږ کولی شو دا ډاټا رد کړو یا موږ یې بیرته راګرځوو، دا نوډ زموږ کلستر ته د نقل په توګه وصل کړئ.

سربیره پردې، د "maximum_lag_on_failover" پیرامیټر شتون لري. د ډیفالټ په واسطه، که زما حافظه ما ته خدمت وکړي، دا پیرامیټر د 1 میګابایټ ارزښت لري.

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

مګر پدې کې یوه ستونزه شتون لري چې د پټروني کلستر او DCS کې د نقل کولو ځنډ په یو ټاکلي وقفه کې تازه کیږي. زه فکر کوم چې 30 ثانیې د ډیفالټ ttl ارزښت دی.

په دې اساس، داسې یو حالت شتون لري چې په DCS کې د نقلونو لپاره یو تکرار وقفه شتون لري، مګر په حقیقت کې ممکن یو بشپړ مختلف وقف وي یا ممکن هیڅ ډول ځنډ شتون ونلري، د بیلګې په توګه دا شی ریښتیني وخت نه دی. او دا تل اصلي انځور نه منعکس کوي. او دا د دې په اړه د زړه پورې منطق کولو ارزښت نلري.

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

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

او دا د لاګونو په څیر ښکاري که چیرې Max_lag_on_failover تنظیم شوی وي او فایلر رامینځته شوی وي ، او تاسو اړتیا لرئ یو نوی ماسټر غوره کړئ. عکس العمل ځان په ټاکنو کې د برخې اخیستو وړ نه بولي. او هغه د مشر لپاره په سیالۍ کې برخه اخیستل ردوي. او هغه د نوي ماسټر ټاکل کیدو لپاره انتظار باسي، ترڅو هغه بیا ورسره اړیکه ونیسي. دا د معلوماتو له لاسه ورکولو په وړاندې یو اضافي اقدام دی.

دلته موږ د محصول ټیم ​​لرو چې لیکلي یې دي چې د دوی محصول د پوسټګریس سره ستونزې لري. په ورته وخت کې، ماسټر پخپله نشي رسیدلی، ځکه چې دا د SSH له لارې شتون نلري. او آٹو فایل هم نه پیښیږي.

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

په ورته وخت کې ، موږ دمخه پوهیږو چې موږ د ډیسکونو سره ستونزې لرو ، دا دی ، موږ دمخه د نظارت څخه پوهیږو چې چیرې کیندل او څه باید وګورو.

موږ د پوسټګریس لاګ ته ننوتلو، د لیدلو لپاره یې پیل وکړ چې هلته څه پیښیږي. موږ ژمنې ولیدلې چې هلته د یو، دوه، درې ثانیو لپاره پای ته رسیږي، کوم چې نورمال ندي. موږ ولیدل چې زموږ آٹوواکوم خورا ورو او په عجیب ډول پیل کیږي. او موږ په ډیسک کې لنډمهاله فایلونه ولیدل. دا دی، دا د ډیسکونو سره د ستونزو ټول شاخصونه دي.

موږ سیسټم dmesg (kernel log) ته وکتل. او موږ ولیدل چې موږ د یو ډیسک سره ستونزې لرو. د ډیسک فرعي سیسټم د سافټویر برید و. موږ /proc/mdstat ته وکتل او ولیدل چې موږ یو ډرایو ورکوو. دا د 8 ډیسکونو برید دی، موږ یو له لاسه ورکوو. که تاسو سلایډ ته په دقت سره وګورئ ، نو په محصول کې تاسو لیدلی شئ چې موږ هلته sde نه لرو. په موږ کې، په مشروط ډول خبرې کول، ډیسک وتلی دی. دې د ډیسک ستونزې رامینځته کړې ، او غوښتنلیکونه هم د پوسټګریس کلستر سره کار کولو پرمهال ستونزې تجربه کړې.

او پدې حالت کې ، پټروني به موږ سره په هیڅ ډول مرسته ونه کړي ، ځکه چې پټروني د سرور حالت ، د ډیسک حالت نظارت دنده نلري. او موږ باید دا ډول حالتونه د بهرنی څارنې په واسطه وڅیړو. موږ ژر تر ژره بهرني نظارت ته د ډیسک نظارت اضافه کړ.

او داسې فکر شتون درلود - ایا د کټارو یا څارنې سافټویر زموږ سره مرسته کولی شي؟ موږ فکر کاوه چې هغه به په سختۍ سره په دې قضیه کې زموږ سره مرسته کړې وي، ځکه چې د ستونزو په جریان کې پټروني د DCS کلستر سره اړیکه درلوده او هیڅ ستونزه یې نه لیدله. دا د DCS او Patroni له نظره، د کلستر سره هرڅه سم وو، که څه هم په حقیقت کې د ډیسک سره ستونزې وې، د ډیټابیس شتون سره ستونزې شتون درلود.

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

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

او دا ټول څنګه پیل شول؟ دا د پخوانۍ ستونزې په څیر، د ډیسک بریکونو سره پیل شو. موږ د یوې ثانیې لپاره ژمنې درلودې، دوه.

په اتصالونو کې وقفې وې، د بیلګې په توګه، پیرودونکي مات شوي.

د مختلف شدت خنډونه شتون درلود.

او، په وینا، د ډیسک فرعي سیسټم خورا ځواب ورکوونکی ندی.

او زما لپاره ترټولو پراسرار شی د سمدستي بندیدو غوښتنه ده چې راورسیده. پوسټګریس درې بند حالتونه لري:

• دا په زړه پوری دی کله چې موږ د ټولو پیرودونکو لپاره انتظار کوو چې دوی پخپله منحل شي.
• دلته ګړندی شتون لري کله چې موږ پیرودونکي مجبور کړو چې اړیکې پرې کړو ځکه چې موږ بندیدو ته ځو.
• او سمدستي. په دې حالت کې، سمدستي حتی مراجعینو ته نه وايي چې بند شي، دا یوازې د خبرتیا پرته تړل کیږي. او ټولو پیرودونکو ته، عملیاتي سیسټم دمخه د RST پیغام لیږي (د TCP پیغام چې اړیکه یې مداخله شوې او پیرودونکي نور څه نه لري چې ونیسي).

دا سیګنال چا رالیږلی؟ د پوسټګریس شالید پروسې یو بل ته دا ډول سیګنالونه نه لیږي، د بیلګې په توګه دا وژنه-9 دی. دوی دا ډول شیان یو بل ته نه لیږي ، دوی یوازې ورته شیانو ته عکس العمل ښیې ، د بیلګې په توګه دا د پوسټګریس بیړني بیا پیل دی. چا رالیږلی، نه پوهیږم.

ما د "وروستي" کمانډ ته وکتل او ما یو سړی ولید چې زموږ سره پدې سرور کې هم ننوتلی و ، مګر زه د پوښتنې کولو لپاره ډیر شرمیدلی وم. شاید دا وژنه وه -9. زه به په لاګونو کې وژنه -9 وګورم، ځکه پوسټګریس وايي چې دا وژنه -9 اخیستې، مګر ما دا په لاګونو کې ونه لید.

نور په لټه کې ، ما ولیدل چې پټروني د ډیر وخت لپاره log ته نه و لیکلی - 54 ثانیې. او که موږ دوه ټایم سټیمپونه پرتله کړو ، د شاوخوا 54 ثانیو لپاره هیڅ پیغام نه و.

او د دې وخت په جریان کې یو آٹو فایل شتون درلود. پټروني دلته بیا ښه کار وکړ. زموږ زوړ بادار شتون نه درلود، هغه ته یو څه پیښ شول. او د نوي ماسټر ټاکنه پیل شوه. دلته هرڅه ښه ترسره شول. زموږ pgsql01 نوی مشر شو.

موږ یو نقل لرو چې ماسټر شو. او دوهم غبرګون دی. او د دوهم نقل سره ستونزې وې. هغې د بیا تنظیم کولو هڅه وکړه. لکه څنګه چې زه پوهیږم، هغې هڅه وکړه recovery.conf بدل کړي، Postgres بیا پیل کړي او نوي ماسټر سره وصل شي. هغه په ​​هرو 10 ثانیو کې پیغامونه لیکي چې هغه هڅه کوي، مګر هغه بریالۍ نه ده.

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

په یو وخت کې، دا کار وکړ، مګر نقل پیل نه شو.

زما یوازینی اټکل دا دی چې په recovery.conf کې یو پخوانی ماسټر پته وه. او کله چې یو نوی ماسټر ښکاره شو، دویم نقل بیا هم هڅه وکړه چې زاړه ماسټر سره وصل شي.

کله چې پټروني په دوهم عکس کې پیل وکړ، نوډ پیل شو مګر نقل نشي کولی. او د نقل کولو ځنډ رامینځته شوی ، کوم چې ورته یو څه ښکاري. دا، ټول درې نوډونه په ځای وو، مګر دویم نوډ وروسته پاتې شو.

په ورته وخت کې، که تاسو هغه لوګو ته وګورئ چې لیکل شوي وو، تاسو لیدلی شئ چې نقل نشي پیل کیدی ځکه چې د لیږد لاګ مختلف وو. او د راکړې ورکړې لاګونه چې ماسټر وړاندیز کوي، کوم چې په recovery.conf کې مشخص شوي، په ساده ډول زموږ اوسني نوډ سره سمون نه لري.

او دلته ما یوه غلطي وکړه. زه باید راشم او وګورم چې په recovery.conf کې څه دي ترڅو زما فرضیه ازموینه وکړي چې موږ د غلط ماسټر سره وصل یو. مګر بیا ما یوازې د دې سره معامله کوله او دا ما ته نه و پیښ شوي، یا ما ولیدل چې نقل شاته و او باید بیا ډک شي، دا دی، ما یو څه په بې پروایۍ سره کار وکړ. دا زما ګډه وه.

د 30 دقیقو وروسته ، اډمین لا دمخه راغلی ، د بیلګې په توګه ما پټروني په نقل کې بیا پیل کړ. ما لا دمخه دا پای ته ورساوه، ما فکر کاوه چې دا باید له سره ډک شي. او ما فکر وکړ - زه به پټروني بیا پیل کړم، شاید یو څه ښه شي. بیا رغونه پیل شوه. او اډه حتی پرانستل شوه، دا د اړیکو منلو ته چمتو وه.

تکرار پیل شو. مګر یوه دقیقه وروسته، هغه د یوې تېروتنې سره راښکته شوه چې د راکړې ورکړې لاګونه د هغې لپاره مناسب ندي.

ما فکر کاوه چې زه به بیا پیل کړم. ما پټروني بیا پیل کړ، او ما پوسټګریس بیا پیل نه کړ، مګر پیټروني په دې هیله بیا پیل کړ چې دا به په جادويي ډول ډیټابیس پیل کړي.

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

او بیا دا ما ته پیښیږي - څه که زه پوسټګریس بیا پیل کړم ، پدې وخت کې زه په اوسني ماسټر کې یوه پوسته جوړه کړم ترڅو د راکړې ورکړې لاګ کې نقطه یو څه وړاندې حرکت وکړي ترڅو بیا رغونه له بلې شیبې څخه پیل شي؟ برسیره پردې، موږ لاهم د WAL ذخیره درلوده.

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

زما لپاره دا ډول ستونزه یو له خورا پراسرارانو څخه دی ، چې زه لاهم په دې اړه حیران یم چې واقعیا هلته څه پیښ شوي.

دلته اغیزې څه دي؟ Patroni کولی شي د هدف په توګه کار وکړي او پرته له کومې تېروتنې. مګر په ورته وخت کې، دا 100٪ تضمین ندی چې هرڅه زموږ سره سم دي. نقل ممکن پیل شي، مګر دا ممکن په نیمه کاري حالت کې وي، او غوښتنلیک نشي کولی د داسې نقل سره کار وکړي، ځکه چې زاړه معلومات به وي.

او د فایلر وروسته ، تاسو تل اړتیا لرئ چیک کړئ چې هرڅه د کلستر سره سم دي ، دا دی ، د عکسونو اړین شمیر شتون لري ، د نقل کولو ځنډ شتون نلري.

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

کله چې تاسو Patroni کاروئ، تاسو باید څارنه ولرئ. تاسو باید تل پوه شئ کله چې د آټو فایل اوور پیښیږي ، ځکه چې که تاسو نه پوهیږئ چې تاسو د آټو فایل اوور درلود ، تاسو په کلستر باندې هیڅ کنټرول نلرئ. او دا بد دی.

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

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

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

زه څنګه د تشخیص مسلې ته رسیدلی شم؟ دا داسې پیښ شوي چې موږ د مختلف پیرودونکو سره کار کوو او هیڅوک د ELK سټیک نلري ، او موږ باید د 6 کنسولونو او 2 ټبونو په خلاصولو سره لاګونه تنظیم کړو. په یوه ټب کې، دا د هر نوډ لپاره د پټروني لاګونه دي، په بل ټب کې، دا د قونسل لاګونه دي، یا که اړتیا وي پوسټګریس. د دې تشخیص خورا ستونزمن دی.

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

بیا، زه د فایلر څخه مخکې د پیښو لپاره په لاګونو کې ګورم، کوم چې د فایلر څخه مخکې و، د بیلګې په توګه زه د هغه دلیلونو په لټه کې یم چې ولې فایلر پیښ شوی.

او دا د پوهیدو انځور ورکوي چې څه پیښ شوي او په راتلونکي کې څه ترسره کیدی شي ترڅو داسې شرایط رامینځته نشي (او په پایله کې هیڅ فایلر شتون نلري).

او موږ عموما چیرته ګورو؟ زه ګورم:

• لومړی، د پټروني لوګو ته.
• بیا، زه د پوسټګریس لاګونو، یا د DCS لاګونو ته ګورم، د هغه څه پورې اړه لري چې د پټروني لاګونو کې موندل شوي.
• او د سیسټم لاګونه هم ځینې وختونه پوهه ورکوي چې د فایلر لامل څه دی.

زه د Patroni په اړه څنګه احساس کوم؟ زه د پټروني سره خورا ښه اړیکه لرم. زما په اند، دا نن ورځ ترټولو غوره دی. زه ډیری نور محصولات پیژنم. دا Stolon، Repmgr، Pg_auto_failover، PAF دي. ۴ وسیلې. ما دوی ټول هڅه وکړه. پټروني زما د خوښې وړ دی.

که دوی له ما څخه پوښتنه وکړي: "ایا زه د پټروني وړاندیز کوم؟". زه به ووایم هو، ځکه چې زه پټونی خوښوم. او زه فکر کوم چې ما د دې پخلی کول زده کړل.

که تاسو لیوالتیا لرئ چې وګورئ د پټروني سره نورې کومې ستونزې شتون لري د هغه ستونزو سربیره چې ما یې یادونه کړې، تاسو کولی شئ تل دا پاڼه وګورئ مسلې په GitHub کې. دلته ډیری بیلابیلې کیسې شتون لري او ډیری په زړه پوري مسایل پکې بحث کیږي. او د پایلې په توګه، ځینې بګونه معرفي شوي او حل شوي، دا یو په زړه پورې لوستل دی.

د خلکو په اړه ځینې په زړه پورې کیسې شتون لري چې پخپله په پښو ډزې کوي. ډیر معلوماتي. تاسو لوستل او پوهیږئ چې دا اړینه نده چې دا کار وکړي. ما خپل ځان ټک کړ.

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

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

بس نور څه نه. که تاسو پوښتنې لرئ، پوښتنه وکړئ.

پوښتنې

د راپور لپاره مننه! که د فایلر وروسته تاسو لاهم اړتیا لرئ هلته په ډیر دقت سره وګورئ ، نو موږ ولې اتومات فایلر ته اړتیا لرو؟

ځکه چې دا نوي توکي دي. موږ یوازې یو کال د هغې سره یو. دا غوره ده چې خوندي وي. موږ غواړو دننه شو او وګورو چې هرڅه واقعیا هغه ډول کار کوي چې باید ترسره شي. دا د بالغ بې باورۍ کچه ده - دا غوره ده چې دوه ځله وګورئ او وګورئ.

د مثال په توګه، موږ سهار ته لاړو او وګورو، سمه ده؟

په سهار کې نه، موږ معمولا د اتوماتیک فایل په اړه نږدې سمدلاسه زده کوو. موږ خبرتیاوې ترلاسه کوو، موږ ګورو چې یو اتومات فایل رامنځته شوی. موږ نږدې سمدلاسه لاړو او ګورو. مګر دا ټول چکونه باید د څارنې کچې ته راوړل شي. که تاسو د REST API له لارې Patroni ته لاسرسی ومومئ، یو تاریخ شتون لري. د تاریخ په واسطه تاسو کولی شئ د وخت سټیمپونه وګورئ کله چې فایلر پیښ شوی. د دې پر بنسټ، څارنه کولی شي. تاسو تاریخ وګورئ، څومره پیښې وې. که موږ نورې پیښې ولرو، نو یو اتومات فایل رامنځته شوی. تاسو کولی شئ لاړ شئ او وګورئ. یا زموږ د نظارت اتوماتیک چیک کړی چې موږ ټول نقلونه په ځای کې لرو ، هیڅ ځنډ شتون نلري او هرڅه سم دي.

ساپی!

د عالي کیسې لپاره ډیره مننه! که موږ د DCS کلستر د پوسټګریس کلستر څخه لیرې انتقال کړو، نو دا کلستر هم باید په دوره توګه خدمت شي؟ کوم غوره عملونه دي چې د DCS کلستر ځینې برخې باید بندې شي، د دوی سره څه وکړي، او داسې نور؟ دا ټول جوړښت څنګه ژوندی پاتې کیږي؟ او تاسو دا کارونه څنګه کوئ؟

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

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

دا پدې پورې اړه لري چې موږ د DCS کلستر کې څومره نوډونه لرو. که چیرې ډیری نوډونه شتون ولري او که موږ یوازې یو له نوډونو څخه غیر فعال کړو (انقلاب) ، نو کلستر یو کورم ساتي. او پټروني فعال پاتې کیږي. او هیڅ شی نه دی محرک. که موږ یو څه پیچلي عملیات ولرو چې نور نوډونه اغیزمن کړي، د هغې نشتوالی کولی شي نصاب خراب کړي، نو بیا - هو، دا به معنی ولري چې پټروني په وقفه کې واچول شي. دا یو ورته کمانډ لري - سرپرست وقف، سرپرست بیا پیل کول. موږ یوازې وقفه کوو او آٹوفیلر پدې وخت کې کار نه کوي. موږ د DCS کلستر ساتنه کوو، بیا موږ وقفه لرې کوو او ژوند ته دوام ورکوو.

ډیره مننه!

ستاسو د راپور لپاره ډیره مننه! د محصول ټیم ​​د معلوماتو له لاسه ورکولو په اړه څنګه احساس کوي؟

د محصول ټیمونه پروا نه کوي، او د ټیم مشران اندیښمن دي.

کوم تضمینونه شتون لري؟

تضمین خورا ستونزمن دی. الکساندر کوکوشین یو راپور لري "څنګه د RPO او RTO محاسبه کول"، د بیلګې په توګه د بیا رغونې وخت او څومره معلومات چې موږ یې له لاسه ورکولی شو. زه فکر کوم چې موږ باید دا سلایډونه ومومئ او مطالعه یې کړو. تر هغه ځایه چې زه په یاد لرم، د دې شیانو محاسبه کولو په اړه ځانګړي ګامونه شتون لري. موږ څومره لیږدونه له لاسه ورکولی شو، څومره ډیټا له لاسه ورکولی شو. د یو اختیار په توګه، موږ کولی شو د پټروني په کچه همغږي نقل وکاروو، مګر دا دوه اړخیزه توره ده: موږ یا د معلوماتو اعتبار لرو، یا موږ سرعت له لاسه ورکوو. همغږي تکرار شتون لري ، مګر دا د معلوماتو له لاسه ورکولو پروړاندې 100٪ محافظت هم نه تضمینوي.

الیکسي ، د عالي راپور لپاره مننه! د صفر کچې محافظت لپاره د پټروني کارولو کومه تجربه؟ يعنې د همغږي سټنډرډ سره په ګډه؟ دا لومړۍ پوښتنه ده. او دویمه پوښتنه. تاسو مختلف حلونه کارولي دي. موږ Repmgr کارولی، مګر پرته له آٹوفیلر، او اوس موږ پالن لرو چې د آٹوفیلر شامل کړو. او موږ Patroni د بدیل حل په توګه ګورو. تاسو د Repmgr په پرتله د ګټو په توګه څه ویلای شئ؟

لومړۍ پوښتنه د همغږي عکسونو په اړه وه. هیڅوک دلته همغږي نقل نه کاروي، ځکه چې هرڅوک ویره لري (ډیری پیرودونکي لا دمخه دا کاروي، په اصولو کې، دوی د فعالیت ستونزې نه دي لیدلي - د سپیکر یادښت). مګر موږ د ځان لپاره یو قاعده رامینځته کړې چې په ترکیب کې د نقل کولو کلستر کې باید لږترلږه درې نوډونه وي ، ځکه چې که موږ دوه نوډونه ولرو او که ماسټر یا ریپلیکا ناکامه شي ، نو پټروني دا نوډ سټینډالون حالت ته بدلوي ترڅو غوښتنلیک دوام ومومي. کار په دې حالت کې، د معلوماتو له لاسه ورکولو خطر شتون لري.

د دویمې پوښتنې په اړه، موږ Repmgr کارولی او لاهم د تاریخي دلایلو لپاره د ځینو پیرودونکو سره کوو. څه ویل کیدی شي؟ پټروني د بکس څخه بهر د آټوفیلر سره راځي ، Repmgr د اضافي ځانګړتیا په توګه د آٹوفیلر سره راځي چې فعالولو ته اړتیا لري. موږ اړتیا لرو چې په هر نوډ کې د Repmgr ډیمون چل کړو او بیا موږ کولی شو آٹوفیلر تنظیم کړو.

Repmgr ګوري چې ایا د پوسټګریس نوډونه ژوندي دي. د Repmgr پروسې د یو بل شتون لپاره معاینه کوي، دا خورا اغیزمنه طریقه نه ده. د شبکې د انزوا پیچلې قضیې شتون لري په کوم کې چې یو لوی Repmgr کلستر کولی شي په څو کوچنیو کې جلا شي او کار ته دوام ورکړي. زه د اوږدې مودې لپاره Repmgr نه تعقیبوم، شاید دا ثابت شوی وي ... یا شاید نه. مګر په DCS کې د کلستر د حالت په اړه د معلوماتو لرې کول، لکه څنګه چې سټولون، پټروني کوي، ترټولو ګټور انتخاب دی.

الیکسي، زه یوه پوښتنه لرم، شاید یو لیمر. په یوه لومړی مثال کې، تاسو DCS له محلي ماشین څخه لیرې کوربه ته لیږدول. موږ پوهیږو چې شبکه یو شی دی چې خپل ځانګړتیاوې لري، دا پخپله ژوند کوي. او څه پیښیږي که چیرې د کوم دلیل لپاره د DCS کلستر شتون ونلري؟ زه به دلایل ونه وایم ، ډیری یې شتون لري: د شبکې ورکونکو له بدو لاسونو څخه اصلي ستونزو ته.

ما دا په لوړ غږ ونه ویل، مګر د DCS کلستر باید ناکام وي، د بیلګې په توګه دا د نوډونو عجیب شمیر دی، د دې لپاره چې د نصاب پوره شي. څه پیښیږي که چیرې د DCS کلستر شتون ونلري، یا نصاب پوره نشي، د بیلګې په توګه د شبکې ویش یا نوډ ناکامي؟ په دې حالت کې، د پټروني کلستر یوازې د لوستلو حالت ته ځي. د پټروني کلستر نشي کولی د کلستر حالت وټاکي او څه وکړي. دا نشي کولی د DCS سره اړیکه ونیسي او د نوي کلستر حالت هلته ذخیره کړي، نو ټول کلستر یوازې لوستلو ته ځي. او یا د آپریټر څخه لاسي مداخلې یا د DCS بیا رغیدو ته انتظار باسي.

په لنډه توګه ووایو، DCS زموږ لپاره د اساس په څیر مهم دی؟

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

ساپی!

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