زه وړاندیز کوم چې تاسو د 2019 له پیل څخه د انډری بوروډین لخوا د راپور لیږد ولولئ "د WAL-G سره بیک اپ. په 2019 کې څه شتون لري؟"
سلام و ټولو ته! زما نوم اندری بوروډین دی. زه په Yandex کې جوړونکی یم. زه د 2016 راهیسې د PostgreSQL سره علاقه لرم ، وروسته له دې چې ما د پراختیا کونکو سره خبرې وکړې او دوی وویل چې هرڅه ساده دي - تاسو د سرچینې کوډ واخلئ او جوړ یې کړئ ، او هرڅه به کار وکړي. او له هغه وخته زه نشم کولی ودروم - زه هر ډول مختلف شیان لیکم.
یو له هغه شیانو څخه چې زه یې کار کوم د بیک اپ سیسټم دی. . په عموم کې، په Yandex کې موږ د اوږدې مودې لپاره په PostgreSQL کې د بیک اپ سیسټمونو کار کوو. او تاسو کولی شئ په انټرنیټ کې د شپږو راپورونو لړۍ ومومئ چې موږ څنګه د بیک اپ سیسټمونه جوړوو. او هر کال دوی یو څه وده کوي، یو څه وده کوي، او ډیر باوري کیږي.
مګر نن ورځ راپور یوازې د هغه څه په اړه نه دی چې موږ یې کړي، بلکې په دې اړه هم دی چې څومره ساده او څه دي. ستاسو څخه څو تنو دمخه د WAL-G په اړه زما راپورونه لیدلي دي؟ دا ښه ده چې یو څو خلکو ونه لیدل، ځکه چې زه به د ساده شی څخه پیل وکړم.
که ناڅاپه تاسو د PostgreSQL کلستر ولرئ، او زه فکر کوم چې هرڅوک د دوی سره یو څو لري، او ناڅاپه لاهم د بیک اپ سیسټم شتون نلري، نو تاسو اړتیا لرئ چې د S3 ذخیره یا د ګوګل کلاوډ مناسب ذخیره ترلاسه کړئ.
د مثال په توګه، تاسو کولی شئ زموږ موقف ته راشئ او د Yandex Object Storage لپاره یو پروموشنل کوډ واخلئ، کوم چې د S3 سره مطابقت لري.
بیا یو بالټ جوړ کړئ. دا یوازې د معلوماتو لپاره یو کانټینر دی.
د خدمت کاروونکي جوړ کړئ.
د خدمت کارونکي لپاره د لاسرسي کیلي رامینځته کړئ: aws-s3-key.
د WAL-G وروستی مستحکم ریلیز ډاونلوډ کړئ.
زموږ مخکینۍ خپرونه د ریلیزونو څخه څنګه توپیر لري؟ زما څخه ډیری وختونه غوښتل کیږي چې ژر خوشې کړم. او که چیرې د کافي وخت لپاره په نسخه کې کومه ستونزه شتون ونلري ، د مثال په توګه ، یوه میاشت ، نو زه یې خوشې کوم. دلته د نومبر څخه دا خپرونه ده. او د دې معنی دا ده چې هره میاشت موږ یو ډول بګ موندلی ، معمولا په غیر جدي فعالیت کې ، مګر موږ لاهم خوشې نه شو. پخوانۍ نسخه یوازې نومبر ده. په دې کې موږ ته هیڅ کیګونه ندي پیژندل شوي، د بیلګې په توګه د پروژې پرمختګ سره بګونه اضافه شوي.
یوځل چې تاسو د WAL-G ډاونلوډ کړئ ، تاسو کولی شئ د چاپیریال متغیرونو کې تیرولو سره د ساده "بیک اپ لیست" کمانډ پرمخ وړئ. او دا به د آبجیکٹ ذخیره سره وصل شي او تاسو ته ووایی چې تاسو کوم بیک اپ لرئ. په لومړي سر کې، البته، تاسو باید بیک اپ ونه لرئ. د دې سلایډ نقطه دا ده چې وښيي چې هرڅه خورا ساده دي. دا د کنسول کمانډ دی چې د چاپیریال تغیرات مني او فرعي کمانډونه اجرا کوي.
له دې وروسته، تاسو کولی شئ خپل لومړی بیک اپ جوړ کړئ. په WAL-G کې "backup-push" ووایاست او په WAL-G کې د خپل کلستر د pgdata موقعیت مشخص کړئ. او ډیری احتمال، PostgreSQL به تاسو ته ووایي، که تاسو دمخه د بیک اپ سیسټم نلرئ، چې تاسو اړتیا لرئ د "آرشیف حالت" فعال کړئ.
دا پدې مانا ده چې تاسو اړتیا لرئ تنظیماتو ته لاړ شئ او "آرشیف_موډ = آن" چالان کړئ او "آرشیف_کمانډ" اضافه کړئ ، کوم چې په WAL-G کې فرعي کمانډ هم دی. مګر د ځینو دلیلونو لپاره خلک ډیری وختونه پدې موضوع کې د بار سکریپټونه کاروي او د WAL-G شاوخوا یې پوښي. مهرباني وکړئ دا کار مه کوئ. په WAL-G کې موندل شوي فعالیت وکاروئ. که تاسو یو څه له لاسه ورکړی وي، ولیکئ . WAL-G ګومان کوي چې دا یوازینی برنامه ده چې په آرشیف_کمانډ کې پرمخ ځي.
موږ په عمده توګه د Yandex ډیټابیس مدیریت کې د لوړ شتون کلستر رامینځته کولو لپاره WAL-G کاروو.
او دا معمولا د یو ماسټر او څو نقلونو په ټوپولوژي کې کارول کیږي. په ورته وخت کې، دا د Yandex Object ذخیره کې د بیک اپ کاپي جوړوي.
ترټولو عام سناریوګانې د وخت په ریکوری کې د پوائنټ په کارولو سره د کلستر کاپي رامینځته کوي. مګر پدې حالت کې ، د بیک اپ سیسټم فعالیت زموږ لپاره دومره مهم ندي. موږ یوازې د بیک اپ څخه یو نوی کلستر اپلوډ کولو ته اړتیا لرو.
عموما، موږ د نوي نوډ اضافه کولو پر مهال د بیک اپ سیسټم فعالیت ته اړتیا لرو. ولې دا مهمه ده؟ معمولا خلک په کلستر کې نوی نوډ اضافه کوي ځکه چې موجوده کلستر نشي کولی د لوستلو بار اداره کړي. دوی باید یو نوی نقل اضافه کړي. که موږ د pg_basebackup څخه ماسټر ته بار اضافه کړو ، نو ماسټر ممکن سقوط وکړي. له همدې امله، دا زموږ لپاره خورا مهم و چې موږ ژر تر ژره د آرشیف څخه یو نوی نوډ اپلوډ کړو، په ماسټر کې لږ تر لږه بار رامنځته کول.
او بل ورته حالت. دا د ډیټا سنټر څخه د کلسټر ماسټر بدلولو وروسته د زوړ ماسټر بیا پیل کولو اړتیا ده چې ورسره اړیکه له لاسه ورکړې وه.
- د پایلې په توګه ، کله چې د کاپي سیسټم لپاره اړتیاوې رامینځته کول ، موږ پوهیږو چې pg_basebackup زموږ لپاره مناسب نه دی کله چې په کلاوډ کې کار کوي.
- موږ غوښتل چې د دې وړتیا ولرو چې زموږ ډاټا کمپریس کړو. مګر نږدې کوم بیک اپ سیسټم پرته له هغه څه چې په بکس کې راځي د ډیټا کمپریشن چمتو کوي.
- موږ غوښتل هر څه موازي کړو ځکه چې په بادل کې یو کاروونکي د پروسیسر کور لوی شمیر اخلي. مګر که موږ په ځینو عملیاتو کې موازي نه لرو، نو د کور لوی شمیر بې ګټې کیږي.
- موږ کوډ کولو ته اړتیا لرو ځکه چې ډیری وختونه ډاټا زموږ نه وي او په روښانه متن کې نشي ساتل کیدی. په هرصورت، په WAL-G کې زموږ ونډه د کوډ کولو سره پیل شوه. موږ په WAL-G کې کوډ کول بشپړ کړل، وروسته له هغه چې موږ څخه وپوښتل شول: "شاید زموږ څخه یو به پروژه رامینځته کړي؟" او له هغه وخت راهیسې زه د یو کال څخه زیات د WAL-G سره کار کوم.
- موږ د منابعو غلظت ته هم اړتیا درلوده، ځکه چې د بادل په کارولو سره د وخت په تیریدو سره، موږ وموندله چې ځینې وختونه خلک د شپې مهم خوراکي توکي لري او دا بار نشي کولی مداخله وکړي. له همدې امله موږ د سرچینو تروټلینګ اضافه کړ.
- همدارنګه لیست کول او مدیریت.
- او تصدیق.
موږ ډیری مختلف وسیلې ولیدل. خوشبختانه، موږ په PostgreSQL کې لوی انتخاب لرو. او هر چیرې چې موږ یو څه له لاسه ورکوو، یو څه یو کوچنی فعالیت، ځینې یو کوچنی ځانګړتیا.
او د موجوده سیسټمونو معاینه کولو سره، موږ دې پایلې ته ورسیدو چې موږ به WAL-G ته وده ورکړو. دا هغه وخت یوه نوې پروژه وه. دا د بیک اپ سیسټم د بادل زیربنا په لور د پرمختګ اغیزه کول خورا اسانه وو.
اصلي نظریه چې موږ یې پیروان یو دا دی چې WAL-G باید د باللیک په څیر ساده وي.
WAL-G 4 کمانډونه لري. دا:
وال-پش - شافټ آرشیف کړئ.
WAL-FETCH - شافټ ترلاسه کړئ.
بیک اپ پش - بیک اپ جوړ کړئ.
BACKUP-FETCH - د بیک اپ سیسټم څخه بیک اپ ترلاسه کړئ.
په حقیقت کې ، WAL-G د دې بیک اپ مدیریت هم لري ، د بیلګې په توګه په تاریخ کې د ریکارډونو او بیک اپ لیست کول او حذف کول چې اوس مهال ورته اړتیا نلري.
زموږ لپاره یو له مهمو دندو څخه د ډیلټا کاپي جوړولو فعالیت دی.
د ډیلټا کاپي پدې معنی ده چې موږ د ټول کلستر بشپړ بیک اپ نه جوړوو، مګر یوازې په کلستر کې د بدل شوي فایلونو بدل شوي پاڼې. داسې بریښي چې په فعاله توګه دا د WAL په کارولو سره د رغیدو وړتیا سره ورته دی. مګر موږ کولی شو په موازي توګه د WAL واحد - تاریډ ډیلټا بیک اپ پورته کړو. په دې اساس، کله چې موږ د شنبې په ورځ یو بنسټیز بیک اپ جوړ کړو، هره ورځ د ډیلټا بیک اپ، او د پنجشنبې په ورځ موږ ناکام شو، نو موږ اړتیا لرو چې د 4 ډیلټا بیک اپ او 10 ساعته WAL ولرو. دا به ورته وخت ونیسي ځکه چې د ډیلټا بیک اپ په موازي ډول رول کوي.
د LSN پر بنسټ ډیلټا - دا پدې مانا ده چې کله بیک اپ رامینځته کړئ، موږ به اړتیا ولرو چې هره پاڼه یوځای کړو او د هغې LSN د پخوانی بیک اپ LSN سره وګورو ترڅو پوه شو چې دا بدل شوی. هر هغه پاڼه چې په احتمالي توګه بدل شوي ډاټا ولري باید د ډیلټا بیک اپ کې موجود وي.
لکه څنګه چې ما وویل، موازي کولو ته ډیره پاملرنه شوې.
مګر په PostgreSQL کې آرشیف API ثابت دی. PostgreSQL یو د WAL فایل آرشیف کوي او کله چې دا بیرته راګرځوي د یو WAL فایل غوښتنه کوي. مګر کله چې ډیټابیس د "WAL-FETCH" کمانډ په کارولو سره د یو WAL فایل غوښتنه کوي، موږ د "WAL-PREFETCH" کمانډ ته زنګ وهو، کوم چې په موازي ډول د اعتراض پلورنځي څخه ډاټا ترلاسه کولو لپاره راتلونکي 8 فایلونه چمتو کوي.
او کله چې ډیټابیس له موږ څخه د یوې فایل آرشیف کولو غوښتنه کوي، موږ آرشیف_سټیټس ته ګورو او وګورو چې ایا نور د WAL فایلونه شتون لري. او موږ هم هڅه کوو چې WAL په موازي ډول ډاونلوډ کړو. دا د پام وړ فعالیت لاسته راوړنه چمتو کوي او د غیر آرشیف شوي WALs شمیر کې فاصله د پام وړ کموي. د بیک اپ سیسټم ډیری پراختیا کونکي پدې باور دي چې دا دومره خطرناک سیسټم دی ځکه چې موږ د کوډ داخلي په اړه زموږ په پوهه تکیه کوو چې د PostgreSQL API ندي. PostgreSQL زموږ لپاره د archive_status فولډر شتون تضمین نه کوي او د سیمانټیکونو تضمین نه کوي، هلته د WAL فایلونو لپاره د چمتووالي نښو شتون. په هرصورت، موږ د سرچینې کوډ مطالعه کوو، موږ ګورو چې دا داسې دی او موږ هڅه کوو چې ګټه پورته کړو. او موږ هغه سمت کنټرول کوو چې PostgreSQL وده کوي؛ که ناڅاپه دا میکانیزم مات شي، موږ به یې کارول بند کړو.
په خپل خالص شکل کې، د LSN پر بنسټ وال ډیلټا د هر کلستر فایل لوستلو ته اړتیا لري چې د فایل سیسټم کې د موډ وخت د تیر بیک اپ څخه بدل شوی. موږ د دې سره د اوږدې مودې لپاره ژوند کاوه، نږدې یو کال. او په پای کې موږ دې پایلې ته ورسیدو چې موږ د وال ډیلټا لرو.
دا پدې مانا ده چې هرکله چې موږ په ماسټر کې WAL آرشیف کوو، موږ نه یوازې دا کمپریس کوو، کوډ کوو او شبکې ته یې لیږو، بلکې موږ یې په ورته وخت کې لوستلو. موږ په دې کې ریکارډونه تحلیل او لوستل کوو. موږ پوهیږو چې کوم بلاکونه بدل شوي او د ډیلټا فایلونه راټولوي.
د ډیلټا فایل د WAL فایلونو یو ټاکلی سلسله تشریح کوي، د دې په اړه معلومات تشریح کوي چې د WAL په دې لړۍ کې کوم بلاکونه بدل شوي. او بیا دا ډیلټا فایلونه هم آرشیف شوي دي.
دلته موږ د دې حقیقت سره مخ یو چې موږ هرڅه په چټکۍ سره موازي کړل، مګر موږ نشو کولی یو ترتیب تاریخ په موازي توګه ولولو، ځکه چې په یوه ځانګړې برخه کې موږ ممکن د پخواني WAL ریکارډ پای ته ورسیږو، کوم چې موږ تر اوسه پورې د ارتباط لپاره هیڅ نه لرو، ځکه چې موازي لوستل د دې لامل شوي چې موږ لومړی راتلونکی تحلیل کړو ، کوم چې لاهم تیر نه لري.
د پایلې په توګه، موږ باید د پوهیدو وړ ټوټې په _delta_partial فایلونو کې واچوو. د پایلې په توګه، کله چې موږ تیر ته بیرته راګرځو، موږ به د WAL ریکارډ ټوټې په یوه کې چپه کړو، له هغې وروسته به موږ تحلیل کړو او پوه شو چې په دې کې څه بدلون راغلی.
که زموږ د شافټ تجزیه کولو په تاریخ کې لږترلږه یو ټکی شتون ولري چیرې چې موږ نه پوهیږو چې څه پیښ شوي ، نو د دې سره سم ، د راتلونکي بیک اپ په جریان کې به موږ مجبور شو چې ټول کلستر بیا ولولو ، لکه څنګه چې موږ د منظم LSN سره وکړل. - د ډیلټا پر بنسټ.
د پایلې په توګه، زموږ ټول کړاو د دې حقیقت لامل شو چې موږ د WAL-G تحلیل کتابتون خلاص کړ. تر هغه ځایه چې زه پوهیږم، هیڅوک یې نه کاروي، مګر که څوک وغواړي، ولیکي او وکاروي، دا په عامه ډومین کې دی. (تازه شوی لینک )
د پایلې په توګه، د ټولو معلوماتو جریان خورا پیچلي ښکاري. زموږ ماسټر شافټ آرشیف کوي او د ډیلټا فایلونه آرشیف کوي. او هغه نقل چې د بیک اپ کاپي رامینځته کوي باید د ډیلټا فایلونه د هغه وخت په جریان کې ترلاسه کړي چې د بیک اپونو ترمینځ تیر شوی وي. په دې حالت کې، د تاریخ برخې باید په لویه کچه اضافه شي او تجزیه شي، ځکه چې ټول تاریخ په لویو برخو کې مناسب نه دی. او یوازې له دې وروسته نقل کولی شي د ډیلټا بشپړ بیک اپ آرشیف کړي.
په ګرافونو کې هرڅه خورا ساده ښکاري. دا زموږ د اصلي کلسترونو څخه یو ډاونلوډ دی. موږ د LSN پر بنسټ لرو، په یوه ورځ کې جوړ شوی. او موږ ګورو چې د LSN پراساس ډیلټا بیک اپ د سهار له دریو بجو څخه تر پنځو بجو پورې روان و. دا د پروسیسر کور شمیر کې بار دی. WAL-delta موږ دلته شاوخوا 20 دقیقې وخت نیولې، دا د پام وړ چټکه شوه، مګر په ورته وخت کې په شبکه کې ډیر شدید تبادله وه.
څرنګه چې موږ د دې په اړه معلومات لرو چې د ډیټابیس په تاریخ کې کوم بلاکونه بدل شوي او په کوم وخت کې، موږ نور لاړ شو او پریکړه یې وکړه چې فعالیت مدغم کړو - د PostgreSQL توسیع چې "pg_prefaulter" نومیږي.
دا پدې مانا ده چې کله د سټینډ بای بیس د بیا رغونې کمانډ اجرا کوي، دا WAL-G ته وایي چې راتلونکی WAL فایل ترلاسه کړي. موږ تقریبا پوهیږو چې کوم ډیټا بلاک کوي د WAL د بیا رغونې پروسه به په نږدې راتلونکي کې لاسرسی ومومي او په دې بلاکونو کې د لوستلو عملیات پیل کړي. دا د SSD کنټرولرانو فعالیت زیاتولو لپاره ترسره شوی. ځکه چې د وال رول به هغه پاڼې ته ورسیږي چې بدلون ته اړتیا لري. دا پاڼه په ډیسک کې ده او د پاڼې زیرمه کې نه ده. او هغه به د دې پاڼې د رسیدو لپاره په همغږي توګه انتظار وکړي. مګر نږدې WAL-G دی، کوم چې پوهیږي چې په راتلونکو څو سوو میګابایټ WAL کې به موږ ځینې مخونو ته اړتیا ولرو او په ورته وخت کې د دوی ګرمول پیل کړو. ډیری ډیسک لاسرسي پیل کوي ترڅو دوی په موازي توګه اجرا شي. دا په SSD ډرایو کې ښه کار کوي، مګر، له بده مرغه، دا په بشپړ ډول د هارډ ډرایو لپاره د تطبیق وړ نه دی، ځکه چې موږ یوازې زموږ د اشارو سره مداخله کوو.
دا هغه څه دي چې اوس په کوډ کې دي.
داسې ځانګړتیاوې شتون لري چې موږ یې اضافه کول غواړو.
دا انځور ښیې چې د وال ډیلټا نسبتا لنډ وخت نیسي. او دا د هغه بدلونونو لوستل دي چې د ورځې په جریان کې په ډیټابیس کې پیښ شوي. موږ نه یوازې د شپې په وخت کې WAL-delta ترسره کولی شو، ځکه چې دا نور د بار وړلو مهم سرچینه نه ده. موږ کولی شو هره دقیقه WAL-delta ولولو ځکه چې دا ارزانه ده. په یوه دقیقه کې موږ کولی شو ټول هغه بدلونونه سکین کړو چې په کلستر کې پیښ شوي. او دې ته "فوري وال ډیلټا" ویل کیدی شي.
نقطه دا ده چې کله موږ کلستر بحال کړو، موږ د کیسې شمیر کموو چې موږ باید په ترتیب سره پورته کړو. دا دی، د WAL مقدار چې PostgreSQL رولونه باید کم شي، ځکه چې دا د پام وړ وخت نیسي.
مګر دا ټول نه دي. که موږ پوهیږو چې ځینې بلاک به د بیک اپ تسلسل نقطې ته بدل شي، موږ نشو کولی دا په تیرو وختونو کې بدل کړو. دا دی، اوس موږ د WAL-delta فارورډینګ د فایل په واسطه د فایل اصلاح کوو. د دې معنی دا ده چې که د مثال په توګه ، د سه شنبې په ورځ یو میز په بشپړ ډول حذف شوی یا ځینې فایلونه په بشپړ ډول له میز څخه حذف شوي ، نو کله چې ډیلټا د دوشنبې په ورځ او د شنبې په ورځ pg_basebackup بحال شي ، نو موږ به حتی دا ډاټا رامینځته نه کړو.
موږ غواړو دا ټیکنالوژي د پاڼې کچې ته وغځوو. دا دی، که د فایل ځینې برخه د دوشنبې په ورځ بدله شي، مګر د چهارشنبه په ورځ به بیا لیکل کیږي، نو کله چې د پنجشنبې په ورځ یو ټکي ته بیرته راستانه شي، موږ اړتیا نلرو چې د پاڼو لومړنۍ څو نسخې ډیسک ته ولیکو.
مګر دا لاهم یوه مفکوره ده چې زموږ دننه په فعاله توګه بحث کیږي، مګر دا لا تر اوسه کوډ ته نه دی رسیدلی.
موږ غواړو په WAL-G کې یو بل خصوصیت جوړ کړو. موږ غواړو دا د توزیع وړ کړو ځکه چې موږ اړتیا لرو د مختلف ډیټابیسونو ملاتړ وکړو او غواړو په ورته ډول د بیک اپ مدیریت ته د رسیدو وړتیا ولرو. مګر ستونزه دا ده چې د MySQL APIs په بنسټیز ډول توپیر لري. په MySQL کې، PITR د فزیکي وال لاګ پر بنسټ نه دی، مګر په بنلاګ کې. او موږ په MySQL کې د آرشیف کولو سیسټم نلرو چې ځینې بهرني سیسټم ته ووایي چې دا بنلاګ پای ته رسیدلی او آرشیف ته اړتیا لري. موږ اړتیا لرو چې د ډیټابیس سره په کرون کې یو ځای ودریږو او وګورو چې ایا یو څه چمتو دی؟
او په ورته ډول، د مای ایس کیو ایل بیا رغولو په جریان کې، د بیا رغونې هیڅ کمانډ شتون نلري چې سیسټم ته ووایي چې زه داسې او داسې فایلونو ته اړتیا لرم. مخکې له دې چې تاسو خپل کلستر بیا رغول پیل کړئ، تاسو اړتیا لرئ پوه شئ چې کوم فایلونو ته اړتیا لرئ. تاسو پخپله اړتیا لرئ اټکل وکړئ چې کوم فایلونو ته اړتیا لرئ. مګر دا ستونزې ممکن په یو ډول حل شي. (وضاحت: MySQL لا دمخه ملاتړ شوی)
په راپور کې، ما غوښتل د هغو قضیو په اړه هم وغږیږم کله چې WAL-G ستاسو لپاره مناسب نه وي.
که تاسو یو همغږي عکس نلرئ، WAL-G تضمین نه کوي چې وروستۍ برخه به وساتل شي. او که آرشیف د تاریخ وروستي څو برخې شاته پاتې وي، دا یو خطر دی. که هیڅ همغږي عکس شتون نلري، زه به د WAL-G کارولو وړاندیز ونه کړم. بیا هم، دا په عمده توګه د بادل نصبولو لپاره ډیزاین شوی، کوم چې د مطابقت لرونکي نقل سره د لوړ شتون حل معنی لري، کوم چې د ژمن شوي وروستي بایټونو خوندیتوب مسولیت لري.
زه ډیری وختونه ګورم چې خلک هڅه کوي په ورته وخت کې WAL-G او WAL-E دواړه چلوي. موږ د شاته مطابقت ملاتړ کوو پدې معنی چې WAL-G کولی شي د WAL-E څخه فایل بحال کړي او کولی شي په WAL-E کې جوړ شوی بیک اپ بحال کړي. مګر څنګه چې دا دواړه سیسټمونه موازي وال-پش کاروي، دوی د یو بل څخه د فایلونو غلا پیل کوي. که موږ دا په WAL-G کې حل کړو، دا به لاهم په WAL-E کې پاتې شي. په WAL-E کې، دا د آرشیف حالت ته ګوري، بشپړ شوي فایلونه ګوري او آرشیف کوي، پداسې حال کې چې نور سیسټمونه به په ساده ډول نه پوهیږي چې دا د WAL فایل شتون لري، ځکه چې PostgreSQL به د دویم ځل آرشیف کولو هڅه ونه کړي.
موږ دلته د WAL-G اړخ کې څه حل کوو؟ موږ به PostgreSQL ته خبر نه ورکوو چې دا فایل په موازي ډول لیږدول شوی، او کله چې PostgreSQL موږ څخه د آرشیف کولو غوښتنه کوي، موږ به دمخه پوه شو چې دا ډول فایل د دې حالت وخت او د دې md5 سره لا دمخه آرشیف شوی او موږ به په ساده ډول ووایو PostgreSQL - سمه ده، هرڅه پرته له کوم څه کولو څخه چمتو دي.
مګر دا ستونزه د WAL-E اړخ کې د حل کیدو امکان نلري ، نو اوس مهال دا ناشونې ده چې د آرشیف کمانډ رامینځته کړئ چې فایل په WAL-G او WAL-E دواړو کې آرشیف کړي.
سربیره پردې ، داسې قضیې شتون لري چیرې چې WAL-G اوس ستاسو لپاره مناسب ندي ، مګر موږ به یې خامخا حل کړو.
لومړی، موږ دا مهال د جوړ شوي بیک اپ تصدیق نلرو. موږ د بیک اپ یا رغیدو پرمهال تصدیق نلرو. البته، دا په بادل کې پلي کیږي. مګر دا په ساده ډول د مخکې چک کولو له لارې پلي کیږي، په ساده ډول د کلستر بیا رغولو سره. زه غواړم دا فعالیت کاروونکو ته ورکړم. مګر د تایید په واسطه، زه ګومان کوم چې په WAL-G کې به دا ممکنه وي چې کلستر بیرته راوباسئ او دا یې پیل کړئ، او د سګرټ ازموینې پرمخ بوځي: pg_dumpall to /dev/null او amcheck index تصدیق.
اوس مهال په WAL-G کې د WAL څخه د یو بیک اپ ځنډولو کومه لاره نشته. دا دی، موږ د ځینې کړکۍ ملاتړ کوو. د مثال په توګه ، د تیرو اوو ورځو ذخیره کول ، د وروستي لسو بیک اپونو ذخیره کول ، د وروستي درې بشپړ بیک اپ ذخیره کول. ډیری وختونه خلک راځي او وايي: "موږ د نوي کال په اړه د هغه څه بیک اپ ته اړتیا لرو او موږ غواړو چې دا د تل لپاره وساتو." WAL-G تراوسه دا نشي کولی. (یادونه - دا لا دمخه ټاکل شوی. نور ولولئ - د بیک اپ مارک آپشن )
او موږ د PITR تصدیق کولو په وخت کې د ټولو شافټ برخو لپاره د پا pageې چیکسم او بشپړتیا چیک نلرو.
له دې ټولو څخه ما د ګوګل سمر کوډ لپاره یوه پروژه جوړه کړه. که تاسو هوښیار زده کونکي پیژنئ څوک چې غواړي په Go کې یو څه ولیکي او د "G" لیک سره د یو شرکت څخه څو زره ډالر ترلاسه کړي ، نو دوی ته زموږ پروژه وړاندیز کړئ. زه به د دې پروژې لپاره د ښوونکي په توګه کار وکړم، دوی کولی شي. که زده کوونکي نه وي، نو زه به یې واخلم او په اوړي کې به یې پخپله وکړم.
او موږ ډیری نورې وړې ستونزې لرو چې موږ یې په تدریجي توګه کار کوو. او ځینې خورا عجیب شیان پیښیږي.
د مثال په توګه، که تاسو WAL-G ته یو خالي بیک اپ ورکړئ، دا به په ساده ډول راټیټ شي. د مثال په توګه، که تاسو هغه ته ووایاست چې هغه د خالي فولډر بیک اپ کولو ته اړتیا لري. د pg_control فایل به هلته نه وي. او هغه به فکر وکړي چې هغه په یو څه نه پوهیږي. په تیوري کې، پدې حالت کې، تاسو اړتیا لرئ چې کاروونکي ته یو عادي پیغام ولیکئ ترڅو هغه ته تشریح کړي چې څنګه وسیله وکاروي. مګر دا حتی د پروګرام کولو ځانګړتیا نه ده، مګر د یوې ښې، پوهه ژبې ځانګړتیا ده.
موږ نه پوهیږو چې څنګه آفلاین بیک اپ وکړو. که ډیټابیس دروغ وي، موږ نشو کولی دا بیک اپ کړو. مګر دلته هرڅه خورا ساده دي. موږ د LSN لخوا بیک اپ ته زنګ وهو کله چې پیل شو. د لاندې بنسټ LSN باید د کنټرول فایل څخه ولوستل شي. او دا یو غیر واقع شوی ځانګړتیا ده. ډیری بیک اپ سیسټمونه کولی شي یو اصلي ډیټابیس بیک اپ کړي. او دا اسانه ده.
موږ اوس مهال نشو کولی د بیک اپ ځای نشتوالی په سمه توګه اداره کړو. ځکه چې موږ معمولا په کور کې د لوی بیک اپ سره کار کوو. او دوی دې ته نږدې نه شول. مګر که څوک غواړي همدا اوس په Go کې برنامه وکړي ، بالټ ته د ځای څخه بهر غلطیو لپاره اداره کول اضافه کړئ. زه به خامخا د کشش غوښتنه وګورم.
او اصلي شی چې موږ ته اندیښمن دی دا دی چې موږ د امکان تر حده ډیری ډاکر ادغام ازموینې غواړو چې مختلف سناریوګانې چیک کړي. همدا اوس موږ یوازې د لومړني سناریو ګانو ازموینه کوو. په هره ژمنه کې، مګر موږ غواړو د ژمنې په واسطه ټول هغه فعالیت وګورو چې موږ یې ملاتړ کوو. په ځانګړې توګه، د مثال په توګه، موږ به د PostgreSQL 9.4-9.5 لپاره کافي ملاتړ ولرو. موږ د دوی ملاتړ کوو ځکه چې ټولنه د PostgreSQL ملاتړ کوي، مګر موږ د ژمنې له مخې ژمنې نه ګورو ترڅو ډاډ ترلاسه کړو چې هرڅه مات شوي ندي. او ماته داسې ښکاري چې دا یو ډیر جدي خطر دی.
موږ WAL-G لرو چې د Yandex ډیټابیس مدیریت کې له زرو څخه ډیر کلسترونو کې پرمخ ځي. او دا هره ورځ څو سوه ټیرابایټ ډیټا بیک اپ کوي.
موږ زموږ په کوډ کې ډیری TODO لرو. که تاسو غواړئ برنامه وکړئ، راشئ، موږ د پلټ غوښتنو ته انتظار یو، موږ پوښتنو ته انتظار یو.
پوښتنې
ماښام مو پخیر! له تاسو مننه! زما اټکل دا دی چې که تاسو د WAL-delta کاروئ، تاسو شاید د بشپړ پاڼې لیکلو باندې تکیه کوئ. او که داسې وي، ایا تاسو ازموینې ترسره کړې؟ تاسو یو ښکلی ګراف ښودلی. که FPW بند شي نو دا به څومره ښکلی شي؟
د بشپړ پاڼې لیکنې زموږ لپاره فعال دي، موږ د دې غیر فعالولو هڅه نه ده کړې. دا دی، ما، د پراختیا کونکي په توګه، هڅه نه ده کړې چې دا بند کړم. د سیسټم مدیرانو چې تحقیق یې کړی شاید دا مسله څیړلې وي. مګر موږ FPW ته اړتیا لرو. تقریبا هیڅوک دا غیر فعال نه کوي، ځکه چې که نه نو د نقل څخه بیک اپ اخیستل ناممکن دي.
د راپور لپاره مننه! زه دوه پوښتنې لرم. لومړۍ پوښتنه دا ده چې د میزانونو سره به څه کیږي؟
موږ د وتلو غوښتنې ته په تمه یو. زموږ ډیټابیسونه په SSD او NMVE ډیسکونو کې ژوند کوي او موږ واقعیا دې خصوصیت ته اړتیا نلرو. زه چمتو نه یم چې همدا اوس د دې په ښه کولو کې جدي وخت تیر کړم. زه په بشپړ ډول د دې ملاتړ کوم چې موږ یې ملاتړ کوو. داسې خلک شته چې د دې ملاتړ کوي، مګر په داسې طریقه یې ملاتړ کوي چې د دوی سره مناسب وي. دوی فورک جوړ کړ، مګر دوی د پلولو غوښتنې نه کوي. (په 0.2.13 نسخه کې اضافه شوی)
او دویمه پوښتنه. تاسو په پیل کې وویل چې WAL-G ګومان کوي چې دا یوازې کار کوي او هیڅ ریپر ته اړتیا نلري. زه پخپله لفافې کاروم. ولې دوی باید ونه کارول شي؟
موږ غواړو چې دا د بالالیکا په څیر ساده وي. دا پدې مانا ده چې تاسو د باللیکا پرته هیڅ شی ته اړتیا نلرئ. موږ غواړو چې سیسټم ساده وي. که تاسو فعالیت لرئ چې تاسو یې په سکریپټ کې ترسره کولو ته اړتیا لرئ ، نو راشئ او موږ ته ووایاست - موږ به یې په Go کې ترسره کړو.
ماښام مو پخیر! د راپور لپاره مننه! موږ نشو کولی د GPG ډیکریپشن سره کار کولو لپاره WAL-G ترلاسه کړو. دا په نورمال ډول کوډ کوي ، مګر نه غواړي کوډ کړي. ایا دا هغه څه دي چې زموږ لپاره کار نه کوي؟ وضعیت د خپګان وړ دی.
په GitHub کې یوه مسله رامینځته کړئ او راځئ چې دا معلومه کړو.
دا دی، تاسو له دې سره مخ نه یاست؟
د تېروتنې راپور یوه ځانګړتیا ده چې کله WAL-G نه پوهیږي چې دا کوم ډول فایل دی، دا پوښتنه کوي: "شاید دا کوډ شوی وي؟" شاید ستونزه په بشپړ ډول کوډ کولو کې نه وي. زه غواړم په دې موضوع کې د ننوتلو ښه کول. هغه باید درک کړي. موږ اوس مهال پدې موضوع کار کوو چې موږ واقعیا نه خوښوو چې څنګه د عامه او خصوصي کیلي ترلاسه کولو سیسټم تنظیم شوی. ځکه چې موږ بهرنۍ GPG وایو نو دا موږ ته خپلې کیلي راکوي. او بیا موږ دا کلیدونه اخلو او داخلي GPG ته یې لیږدوو، کوم چې خلاص PGP دی، کوم چې زموږ لپاره د WAL-G دننه ترتیب شوی، او هلته موږ کوډ کول بولو. پدې برخه کې، موږ غواړو سیسټم ته وده ورکړو او د لیبسوډیم کوډ کولو ملاتړ کول غواړو (په نسخه 0.2.15 کې اضافه شوي). البته، کوډ کول باید کار وکړي، راځئ چې دا معلومه کړو - تاسو د څو کلمو په پرتله ډیرې نښې ته اړتیا لرئ. تاسو کولی شئ یو څه وخت د سپیکر په خونه کې راټول شئ او سیسټم وګورئ. (د خارجي GPG پرته د PGP کوډ کول - v0.2.9)
سلام! د راپور لپاره مننه! زه دوه پوښتنې لرم. زه یوه عجیبه هیله لرم چې pg_basebackup او WAL لاګ په دوه چمتو کونکو کې وکړم ، د بیلګې په توګه زه غواړم یو کلاوډ او بل وکړم. ایا د دې کولو لپاره کومه لاره شتون لري؟
دا اوس شتون نلري، مګر دا یو زړه پورې نظر دی.
زه یوازې په یو چمتو کونکي باور نه لرم، زه غواړم چې په بل کې ورته وي، یوازې په قضیه کې.
نظر په زړه پورې دی. په تخنیکي توګه، دا د پلي کولو لپاره خورا ستونزمن نه دی. د دې له لاسه ورکولو څخه د نظر مخنیوي لپاره ، ایا زه کولی شم له تاسو څخه وغواړم چې په GitHub کې مسله رامینځته کړم؟
هو!
او بیا، کله چې زده کونکي د ګوګل سمر کوډ ته راشي، نو موږ به دوی په پروژه کې اضافه کړو ترڅو د دوی څخه د ډیر څه ترلاسه کولو لپاره ډیر کار وي.
او دویمه پوښتنه. په GitHub کې یوه ستونزه شتون لري. زه فکر کوم چې دا لا دمخه تړل شوی دی. د بیا رغولو پرمهال ویره شتون لري. او د هغې د ماتولو لپاره تاسو جلا مجلس جوړ کړ. دا په مسلو کې سمه ده. او په یوه تار کې د متغیر چاپیریال ترسره کولو اختیار شتون لري. او له همدې امله دا خورا ورو کار کوي. او موږ د دې ستونزې سره مخ شو، او دا لاهم نه دی حل شوی.
ستونزه دا ده چې د ځینې دلیلونو لپاره ذخیره (CEPH) پیوستون له سره تنظیموي کله چې موږ دې ته د لوړې همغږۍ سره راځو. په دې اړه څه کولی شي؟ د بیاکتنې منطق داسې ښکاري. موږ هڅه کوو چې فایل بیا ډاونلوډ کړو. په یوه پاس کې، موږ یو شمیر فایلونه ډاونلوډ نه کړل، موږ به د ټولو هغو کسانو لپاره دوهم جوړ کړو چې لاګ ان شوي ندي. او تر هغه چې لږترلږه یو فایل په هر تکرار کې پورته شي، موږ تکرار کوو او بیا تکرار کوو. موږ د بیا هڅه کولو منطق ته وده ورکړه - exponential backoff. مګر دا په بشپړ ډول روښانه نده چې د دې حقیقت سره څه وکړي چې اړیکه په ساده ډول د ذخیره کولو سیسټم اړخ کې ماتیږي. دا دی، کله چې موږ یو جریان ته اپلوډ کوو، دا دا اړیکې نه ماتوي. موږ دلته څه ښه کولی شو؟ موږ د شبکې تروټلینګ لرو، موږ کولی شو هره اړیکه د هغه بایټس شمیر پورې محدود کړو چې دا یې لیږلي. که نه نو، زه نه پوهیږم چې څنګه د دې حقیقت سره معامله وکړم چې د اعتراض ذخیره موږ ته اجازه نه راکوي چې له دې څخه موازي ډاونلوډ یا ډاونلوډ کړو.
SLA نشته؟ ایا دا د دوی لپاره نه دی لیکل شوی چې دوی څنګه ځان ته د عذاب اجازه ورکوي؟
خبره دا ده چې هغه خلک چې د دې پوښتنې سره راځي معمولا خپل والټ لري. دا دی، هیڅوک د ایمیزون یا ګوګل کلاوډ یا یانډیکس آبجیکٹ ذخیره څخه نه راځي.
شاید پوښتنه نور ستاسو لپاره نه وي؟
دلته په دې قضیه کې دا پوښتنه مطرح نه ده چې چا ته. که چیرې د دې سره د معاملې کولو څرنګوالي په اړه کوم نظرونه شتون ولري ، راځئ چې دا په WAL-G کې ترسره کړو. مګر تر دې دمه زه د دې سره د چلند څرنګوالي په اړه ښه نظرونه نه لرم. دلته د آبجیکٹ ذخیره شتون لري چې د لیست کولو بیک اپ په مختلف ډول ملاتړ کوي. تاسو له دوی څخه د شیانو لیست کولو غوښتنه کوئ، او دوی هلته فولډر اضافه کوي. WAL-G پدې کې ویره لري - دلته یو ډول شی شتون لري چې فایل نه دی ، زه نشم کولی دا بیرته راوباسئ ، پدې معنی چې بیک اپ نه و بحال شوی. دا په حقیقت کې ، تاسو په بشپړ ډول رغول شوي کلسټر لرئ ، مګر دا تاسو ته غلط حالت راګرځوي ځکه چې د آبجیکٹ ذخیره ځینې عجیب معلومات بیرته راګرځولي چې دا په بشپړ ډول نه پوهیږي.
دا یو شی دی چې د میل کلاوډ کې پیښیږي.
که تاسو کولی شئ بیا تولید جوړ کړئ ...
دا په دوامداره توګه بیا تولید کیږي ...
که چیرې بیا تولید شتون ولري، نو زه فکر کوم چې موږ به د بیاکتنې ستراتیژیو سره تجربه وکړو او معلومه کړو چې څنګه بیا هڅه وکړو او پوه شو چې بادل زموږ څخه څه ته اړتیا لري. شاید دا به زموږ لپاره په دریو ارتباطاتو کې مستحکم وي او اړیکه به نه ماتوي ، بیا به موږ په احتیاط سره دریو ته ورسیږو. ځکه چې اوس موږ اړیکه په چټکۍ سره پریږدو، د بیلګې په توګه که موږ د 16 تارونو سره ریکوری پیل کړو، نو د لومړۍ بیا هڅې وروسته به 8 تارونه، 4 تارونه، 2 تارونه او یو وي. او بیا به دا فایل په یوه جریان کې راوباسي. که چیرې ځینې جادو ارزښتونه شتون ولري لکه 7,5 تارونه د پمپ کولو لپاره غوره دي ، نو موږ به په دوی کې پاتې شو او هڅه وکړو چې نور 7,5 تارونه جوړ کړو. دلته یو نظر دی.
د راپور لپاره مننه! د WAL-G سره کار کولو لپاره بشپړ کاري فلو څه ډول ښکاري؟ د مثال په توګه، په احمق قضیه کې کله چې په پاڼو کې ډیلټا شتون نلري. او موږ لومړنی بیک اپ اخلو او لیرې کوو ، بیا شافټ آرشیف کوو تر هغه چې موږ په مخ نیلي وي. دلته، لکه څنګه چې زه پوهیږم، یو ماتول شتون لري. په یو وخت کې تاسو اړتیا لرئ د پاڼو ډیلټا بیک اپ جوړ کړئ، د بیلګې په توګه ځینې بهرنۍ پروسې دا چلوي یا دا څنګه پیښیږي؟
د ډیلټا بیک اپ API خورا ساده دی. دلته یو شمیر شتون لري - د ډیلټا اعظمي مرحلې ، دا هغه څه دي چې ورته ویل کیږي. دا صفر ته ډیفالټ کوي. دا پدې مانا ده چې هرکله چې تاسو بیک اپ پش کوئ، دا یو بشپړ بیک اپ ډاونلوډ کوي. که تاسو دا هرې مثبتې شمیرې ته بدل کړئ، د بیلګې په توګه، 3، بیا بل ځل چې تاسو د بیک اپ پش ترسره کوئ، دا د پخوانیو بیک اپ تاریخ ته ګوري. هغه ګوري چې تاسو د 3 ډیلټا زنځیر څخه ډیر نه یاست او ډیلټا جوړوي.
دا دی، هرکله چې موږ WAL-G پیل کړو، دا هڅه کوي چې بشپړ بیک اپ جوړ کړي؟
نه، موږ WAL-G چلوو، او دا هڅه کوي چې ډیلټا جوړ کړي که ستاسو پالیسۍ اجازه ورکړي.
په لنډه توګه، که تاسو دا هر ځل د صفر سره پرمخ وړئ، ایا دا به د pg_basebackup په څیر چلند وکړي؟
نه، دا به لاهم ګړندی وګرځي ځکه چې دا کمپریشن او موازي کاروي. Pg_basebackup به شافټ ستاسو تر څنګ کېږدي. WAL-G فرض کوي چې تاسو آرشیف ترتیب کړی دی. او دا به یو خبرداری خپور کړي که چیرې دا تنظیم شوی نه وي.
Pg_basebackup د شافټونو پرته چلیدلی شي.
هو، بیا به دوی تقریبا ورته چلند وکړي. Pg_basebackup د فایل سیسټم ته کاپي کوي. په هرصورت، موږ یو نوی خصوصیت لرو چې ما یې یادونه هېره کړه. موږ اوس کولی شو د pg_basebackup څخه فایل سیسټم ته بیک اپ وکړو. زه نه پوهیږم چې ولې دې ته اړتیا ده، مګر دا شتون لري.
د مثال په توګه، په CephFS کې. هرڅوک نه غواړي د آبجیکٹ ذخیره تنظیم کړي.
هو، شاید له همدې امله دوی د دې ځانګړتیا په اړه پوښتنه وکړه ترڅو موږ یې وکړو. او موږ یې وکړل.
د راپور لپاره مننه! د فایل سیسټم ته د کاپي کولو په اړه یوازې یوه پوښتنه شتون لري. د بکس څخه بهر، ایا تاسو اوس ریموټ ذخیره ته د کاپي کولو ملاتړ کوئ، د بیلګې په توګه، که چیرې د ډیټا مرکز کې یو څه شیلف وي یا بل څه؟
په دې فورمول کې، دا یوه ستونزمنه پوښتنه ده. هو، موږ ملاتړ کوو، مګر دا فعالیت لا تر اوسه په هیڅ ریلیز کې شامل نه دی. دا دی، ټول پری ریلیز د دې ملاتړ کوي، مګر د خوشې کولو نسخې نه کوي. دا فعالیت په 0.2 نسخه کې اضافه شوی. دا به خامخا ژر خوشې شي، هرڅومره ژر چې موږ ټول پیژندل شوي بګونه حل کړو. مګر اوس دا یوازې د خوشې کیدو دمخه ترسره کیدی شي. د خپریدو دمخه دوه کیچونه شتون لري. د WAL-E د بیا رغونې ستونزه، موږ دا نه ده حل کړې. او په وروستي دمخه خپریدو کې د ډیلټا بیک اپ په اړه بګ اضافه شوی. له همدې امله ، موږ هرڅوک وړاندیز کوو چې د خوشې نسخې وکاروئ. هرڅومره ژر چې د خوشې کیدو دمخه نور بګونه شتون ونلري ، موږ کولی شو ووایو چې موږ د ګوګل کلاوډ ، S3 سره مطابقت لرونکي شیان او د فایل ذخیره ملاتړ کوو.
سلام، د راپور لپاره مننه. لکه څنګه چې زه پوهیږم، WAL-G یو ډول مرکزي سیسټم نه دی لکه بارمین؟ ایا تاسو پلان لرئ چې پدې لور حرکت وکړئ؟
ستونزه دا ده چې موږ له دې اړخه تللي یو. WAL-G د بیس کوربه، د کلستر کوربه، او په کلستر کې په ټولو کوربه کې ژوند کوي. کله چې موږ څو زره کلسترونو ته لاړو، موږ ډیری بارټینر تاسیسات درلودل. او هرکله چې یو څه په دوی کې جلا شي، دا یوه لویه ستونزه ده. ځکه چې دوی ترمیم ته اړتیا لري، تاسو اړتیا لرئ پوه شئ چې کوم کلسترونه اوس بیک اپ نلري. زه پلان نه لرم چې د بیک اپ سیسټمونو لپاره د فزیکي هارډویر په لور د WAL-G رامینځته کړم. که ټولنه دلته یو څه فعالیت غواړي، زه هیڅ فکر نه کوم.
موږ ټیمونه لرو چې د ذخیره کولو مسولیت لري. او موږ دومره ښه احساس کوو چې دا موږ نه یو، دلته ځانګړي خلک شتون لري چې زموږ فایلونه یې ځای په ځای کوي چیرې چې فایلونه خوندي دي. دوی هلته هر ډول هوښیار کوډینګ کوي ترڅو د یو ټاکلي شمیر فایلونو له لاسه ورکولو سره مقاومت وکړي. دوی د شبکې بینډ ویت لپاره مسؤل دي. کله چې تاسو بارټینر لرئ، تاسو ممکن ناڅاپه ومومئ چې کوچني ډیټابیسونه د ډیری ترافیک سره په ورته سرور کې راټول شوي. تاسو داسې بریښي چې پدې کې ډیر ځای لرئ ، مګر د ځینې دلیلونو لپاره هرڅه د شبکې له لارې مناسب ندي. دا ممکن په بل ډول وګرځي. دلته ډیری شبکې شتون لري، د پروسیسر کورونه شتون لري، مګر دلته هیڅ ډیسک شتون نلري. او موږ د دې اړتیا څخه ستړي شوي یو چې یو څه تیر کړو ، او موږ دې حقیقت ته لاړو چې د معلوماتو ذخیره کول یو جلا خدمت دی ، د کوم لپاره چې جلا ځانګړي خلک مسؤل دي.
PS یوه نوې نسخه خپره شوې ، په کوم کې چې تاسو کولی شئ د .walg.json تشکیلاتو فایل وکاروئ ، کوم چې د ډیفالټ لخوا د پوسټګریس کور لارښود کې موقعیت لري. تاسو کولی شئ د بش سکریپټونه پریږدئ. بېلګه .walg.json په دې ګڼه کې ده
ویډیو:
سرچینه: www.habr.com