د ظرفیت ټایر (یا لکه څنګه چې موږ ورته د Vim - captir دننه وایو) د ویم بیک اپ او ریپلیکیشن 9.5 تازه کولو 4 ورځو کې د آرشیف ټایر نوم لاندې څرګند شو. د دې ترشا نظر دا دی چې دا ممکنه کړي چې بیک اپونه حرکت وکړي چې د تش په نامه عملیاتي بیا رغونې کړکۍ څخه د اعتراض ذخیره کولو ته راوتلي دي. دا د هغو کاروونکو لپاره د ډیسک ځای پاکولو کې مرسته وکړه چې لږ یې درلود. او دا اختیار د حرکت حالت په نوم یادیږي.
د دې ساده (لکه څنګه چې ښکاري) عمل ترسره کولو لپاره ، دا د دوه شرایطو پوره کولو لپاره کافي و: د حرکت شوي بیک اپ ټول ټکي باید د پورته ذکر شوي عملیاتي بیا رغونې کړکۍ له حدودو بهر وي ، کوم چې په UI کې په واضح ډول تنظیم شوی. او دوهم: زنځیر باید په تش په نامه "مهر شوي شکل" کې وي (د مهر شوي بیک اپ چین یا غیر فعال بیک اپ چین). یعنی د وخت په تیریدو سره په دې سلسله کې هیڅ بدلون نه راځي.
مګر په VBR v10 کې، مفهوم د نویو دندو سره ضمیمه شوی و - د کاپي موډ، مهر شوي حالت او یو شی چې د تلفظ ستونزمن نوم سره ناڅرګندتیا ښکاره شوه.
دا په زړه پورې شیان دي چې موږ به یې نن ورځ په اړه خبرې وکړو. لومړی، په VBR9.5u4 کې د کار کولو څرنګوالي په اړه، او بیا په لسمه نسخه کې د بدلونونو په اړه.
او د پاکې ژبې اتلان دې ما وبخښي ، مګر دلته ډیر شرایط شتون لري چې ژباړل کیدی نشي.
نو دلته به یو ټن انګلیسزم وي.
او ډیری gifونه.
او انځورونه.
- د لږ افسوس پرته. د مقالې لیکوال.
لکه څنګه چې دا وه
ښه، راځئ چې د عملیاتي بیا رغونې کړکۍ او مهر شوي بیک اپ تحلیل کولو سره پیل وکړو (یا لکه څنګه چې دوی د غیر فعال بیک اپ چین اسنادو کې ویل کیږي). د دوی د پوهیدو پرته به نور توضیحات ممکن نه وي.
لکه څنګه چې موږ په عکس کې ګورو، موږ د ډیټا بلاکونو سره یو ډول بیک اپ سلسله لرو، کوم چې د ذخیره کولو د فعالیت ټایر SOBR کې موقعیت لري چې د ظرفیت ټیر سره وصل دی. زموږ عملیاتي بیک اپ کړکۍ درې ورځې ده.
په دې اساس، .vbk د دوشنبې په ورځ رامینځته شوی پخوانی سلسله مهر کړه، چې کړکۍ یې درې ورځو ته ټاکل شوې. او دا پدې مانا ده چې تاسو کولی شئ په خوندي ډول د دې دریو ورځو څخه زاړه هرڅه د شوټینګ حد ته لیږدول پیل کړئ.
مګر په حقیقت کې د مهر شوي زنځیر معنی څه وه او په تازه 4 کې د ظرفیت شوټینګ حد ته څه لیږل کیدی شي؟
د فارورډ انکریمینټل لپاره، د زنځیر مهر کولو نښه د نوي بشپړ بیک اپ رامینځته کول دي. او دا مهمه نده چې دا بشپړ بیک اپ څنګه ترلاسه کیږي: دواړه مصنوعي بشپړ او فعال بشپړ بیک اپ په پام کې نیول کیږي.
د ریورس په حالت کې، دا ټول هغه فایلونه دي چې په عملیاتي کړکۍ کې نه راځي.
د رول بیک سره د فارورډ زیاتوالي په حالت کې، دا ټول رول بیکونه دي او .vbk، که چیرې د فعالیت حد کې بل .vbk شتون ولري.
اوس راځئ چې د بیک اپ کاپي زنځیرونو سره د کار کولو اختیار په پام کې ونیسو. یوازې هغه توکي چې د GFS ساتلو لاندې راځي دلته لیږدول شوي. ځکه چې هرڅه په وروستي بیک اپ کاپي زنځیرونو کې زیرمه شوي په یو یا بل ډول بدل کیدی شي.
اوس راځئ چې د هود لاندې وګورو. هلته، د ډیهایډریشن په نوم یوه پروسه پیښیږي - په حد کې د خالي بیک اپ فایلونو پریښودل او د دې فایلونو څخه د ظرفیت شوټینګ حد ته د بلاکونو ایستل. د دې پروسې د ښه کولو لپاره، د تشناب ډیهایډریشن شاخص کارول کیږي، کوم چې تاسو ته اجازه درکوي د کاپي کولو بلاکونو څخه مخنیوی وکړئ چې دمخه د ظرفیت شوټینګ حد ته کاپي شوي.
راځئ وګورو چې دا د مثال سره څه ښکاري: راځئ چې ووایو چې موږ یو .vbk لرو چې د راکړې ورکړې له کړکۍ څخه راوتلی او د مهر شوي سلسلې پورې اړه لري. دا پدې مانا ده چې موږ دا حق لرو چې دا د ظرفیت شوټینګ حد ته واړوو. د حرکت کولو په وخت کې، د میټاډاټا فایل د لیږد شوي فایل په ظرفیت ډش او بلاکونو کې رامینځته کیږي. د لینک کچې میټاډاټا فایل تشریح کوي چې زموږ فایل کوم بلاکونه لري. د انځور په حالت کې، زموږ لومړی فایل د بلاکس څخه جوړ دی a، b، c او میټاډاټا د دې بلاکونو لینکونه لري. کله چې موږ دوهم .vbk فایل ولرو، د حرکت کولو لپاره چمتو او د بلاکس a، b او d څخه جوړ وي، موږ د ډیهایډریشن شاخص تحلیل کوو، پوهیږو چې یوازې د بلاک d لیږدولو ته اړتیا لري. او د دې میټاډاټا فایل به د دوه پخوانیو بلاکونو او یو نوي سره اړیکې ولري.
په دې اساس، د دې خالي ځایونو ډکولو پروسې بیرته د معلوماتو سره د ریهایډریشن په نوم یادیږي. دا دمخه د خپل ریهایډریشن شاخص کاروي ، د ځایی فعالیت حد کې د زوړ .vbk فایل پراساس. دا دی، که چیرې کاروونکي غواړي د ظرفیت شوټینګ رینج څخه فایل بیرته راولي، موږ لومړی د زاړه بشپړ بیک اپ بلاکونو شاخص جوړوو او د ظرفیت شوټینګ ګالري څخه یوازې ورک شوي بلاکونه لیږدوو. په عکس کې وړاندې شوي قضیه کې، د ریهایډریشن شاخص سره سم د FullBackup1.vbk ریهایډریټ کولو لپاره، موږ یوازې C بلاک ته اړتیا لرو، کوم چې موږ د ظرفیت شوټینګ حد څخه اخلو. که چیرې د ذخیره کولو بادل څیز د ظرفیت شوټینګ حد په توګه کار وکړي ، دا تاسو ته اجازه درکوي خورا لوی مقدار خوندي کړئ.
دلته ممکن داسې بریښي چې دا ټیکنالوژي ورته ورته ده چې په WAN سرعت کونکي کې کارول کیږي ، مګر دا یوازې داسې بریښي. په سرعت کونکي کې، تخریب نړیوال دی؛ دلته، محلي نقل کول په هر فایل کې په ځانګړي آفسیټ کې کارول کیږي. دا د حل شوي دندو کې د توپیر له امله پیښیږي: دلته موږ اړتیا لرو لوی بشپړ بیک اپ فایلونه کاپي کړو ، او زموږ د څیړنې له مخې ، حتی که د دوی ترمینځ اوږده موده تیریږي ، دا د تخریب الګوریتم غوره پایله ورکوي.
مګر د شاخصونو خدای لپاره نور شاخصونه! د معلوماتو بیا رغونې لپاره یو شاخص هم شتون لري! کله چې موږ د ظرفیت ډش کې موقعیت لرونکي ماشین بیا رغونه پیل کوو، موږ به یوازې د ځانګړي ډیټا بلاکونه ولولو چې د فعالیت ډش کې ندي.
دا څنګه وشول؟
دا ټول د ابتدايي برخې لپاره دي. دا خورا مفصله ده، مګر لکه څنګه چې پورته یادونه وشوه، د دې توضیحاتو پرته به دا ممکنه نه وي چې تشریح کړئ چې نوي دندې څنګه کار کوي. له همدې امله، پرته له نورو اډو، راځئ چې لومړی ته لاړ شو.
د کاپي حالت
دا په پراخه کچه د موجوده ټیکنالوژیو پراساس دی ، مګر د کارولو بشپړ مختلف منطق لري.
د دې حالت هدف دا دی چې ډاډ ترلاسه شي چې ټول معلومات په محلي حد کې موقعیت لري د ظرفیت ډش کې کاپي لري.
که تاسو د حرکت او کاپي حالتونه په سر کې پرتله کړئ، دا به داسې ښکاري:
- یوازې مهر شوی سلسله لیږدول کیدی شي. د کاپي حالت په حالت کې، په بشپړه توګه هرڅه لیږدول کیږي، پرته له دې چې د بیک اپ دندې کې څه پیښیږي.
- حرکت هغه وخت پیل کیږي کله چې فایلونه د عملیاتي بیک اپ کړکۍ له حدودو څخه تیریږي، او کاپي کول د بیک اپ فایل څرګندیدو سره سم پیل کیږي.
- د کاپي کولو لپاره د نوي معلوماتو څارنه په دوامداره توګه ترسره کیږي، او د حرکت لپاره دا په هر 4 ساعتونو کې یو ځل پیل کیږي.
د نوي حالت په پام کې نیولو سره، زه وړاندیز کوم چې له ساده مثالونو څخه پیچلي نمونو ته لاړ شم.
په خورا عام حالت کې، موږ په ساده ډول د زیاتوالي سره نوي فایلونه لرو، او موږ په ساده ډول د ظرفیت شوټینګ حد ته کاپي کوو. د دې په پام کې نیولو پرته چې د بیک اپ کار کې کوم حالت کارول کیږي، پرته له دې چې دا د زنځیر مهر شوي برخې پورې اړه ولري یا نه، پرته له دې چې زموږ عملیاتي کړکۍ پای ته رسیدلې وي. دوی یوازې دا اخیستي او کاپي یې کړي.
د دې تر شا پروسه لاهم د ډیهایډریشن ده لکه څنګه چې پورته تشریح شوي. د کاپي حالت کې، دا دا هم ډاډه کوي چې موږ هغه بلاکونه کاپي نه کوو چې دمخه زموږ په ذخیره کې دي. یوازینی توپیر دا دی چې که د فلم موډ کې موږ ریښتیني فایلونه د ډمي فایلونو سره ځای په ځای کړي ، دلته موږ دوی ته په هیڅ ډول لاس نه ورکوو او هرڅه لکه څنګه چې پریږدو. که نه نو، دا په سمه توګه د ډیهایډریشن شاخص دی، کوم چې په احتیاط سره هڅه کوي ستاسو پیسې او وخت خوندي کړي.
پوښتنه راپورته کیږي - که تاسو UI ته ګورئ ، نو فرصت شتون لري چې په ورته وخت کې دواړه اختیارونه غوره کړئ. دا ډول ګډ حالت به څنګه کار وکړي؟
راځئ چې سم یې کړو.
پیل معیاري دی: یو بیک اپ فایل جوړ شوی او سمدلاسه کاپي کیږي. یو زیاتوالی ورته رامینځته شوی او کاپي هم کیږي. دا تر هغه وخته پورې پیښیږي کله چې موږ پوهیږو چې فایلونه زموږ عملیاتي کړکۍ پریږدي او یو مهر شوی سلسله ښکاره شوې. پدې مرحله کې موږ د ډیهایډریشن عملیات ترسره کوو او دا فایلونه د ډمي فایلونو سره بدلوو. البته، موږ بیا د ظرفیت شوټینګ حد ته هیڅ شی کاپي نه کوو.
دا ټول زړه راښکونکي منطق په انٹرفیس کې یوازې د یو چیک باکس لپاره مسؤل دی: د شیانو ذخیره کولو کې بیک اپ کاپي کړئ هرڅومره ژر چې دوی رامینځته شي.
موږ ولې دې کاپي حالت ته اړتیا لرو؟
دا حتی غوره ده چې دا پوښتنه بیا تکرار کړئ: موږ د دې په مرسته له کوم خطرونو څخه خوندي یو؟ کومه ستونزه له موږ سره مرسته کوي؟
ځواب څرګند دی: البته، دا د معلوماتو بیا رغونه ده. که موږ د اعتراض ذخیره کولو کې د ځایی ډیټا بشپړ کاپي ولرو، نو مهمه نده چې زموږ محصول ته څه پیښیږي، موږ کولی شو تل په مشروط ایمیزون کې موقعیت لرونکي فایلونو څخه ډاټا بیرته راوړو.
نو راځئ چې ممکنه سناریوګانو ته لاړ شو، له ساده څخه ډیر پیچلي ته.
ترټولو ساده بدبختي چې زموږ په سرونو راوتلی شي د بیک اپ سلسله کې د یوې فایلونو لاسرسی دی.
یوه غمجنه کیسه دا ده چې زموږ د SOBR ذخیره یوه برخه مات شوه.
دا نور هم خرابیږي کله چې د SOBR ټول ذخیره د لاسرسي وړ نه وي ، مګر د شوټینګ ظرفیت کار کوي.
او هرڅه واقعیا خراب دي - دا هغه وخت دی کله چې د بیک اپ سرور مړ شي او ستاسو لومړۍ هیله دا ده چې هڅه وکړئ په لسو دقیقو کې د کاناډا پولې ته وګرځئ.
اوس راځئ چې هر حالت په جلا توګه وګورو.
کله چې موږ یو (او حتی څو) بیک اپ فایلونه له لاسه ورکړ، نو بیا ټول هغه څه چې موږ یې کولو ته اړتیا لرو د ذخیره کولو بیا رغونې پروسه پیل کړه، او ورک شوی فایل به د ډمي فایل سره بدل شي. او د ریهایډریشن پروسې په کارولو سره (کوم چې د مقالې په پیل کې بحث شوی) ، کارونکي به وکولی شي د ظرفیت شوټینګ رینج څخه ځایی ذخیره ته ډیټا ډاونلوډ کړي.
اوس وضعیت نور هم پیچلی دی. راځئ فرض کړو چې زموږ SOBR د دوه برخو څخه جوړ دی چې د فعالیت حالت کې روان دي، پدې معنی چې زموږ .vbk او .vib په دوی باندې په غیر مساوي طبقه کې خپریږي. او په ځینو وختونو کې، یو له حدونو څخه شتون نلري، او کاروونکي په چټکۍ سره د ماشین بیا رغولو ته اړتیا لري، د معلوماتو یوه برخه چې په دې حد کې دقیقه ده.
کارونکي د بیا رغونې وزرډ په لاره اچوي، هغه نقطه غوره کوي چې هغه یې بیرته راوستل غواړي، او وزرډ، د کار کولو په وخت کې، احساس ته راځي چې هغه په محلي توګه د بیا رغونې لپاره اړین ټول معلومات نلري او له همدې امله اړتیا لري چې د ظرفیت شوټینګ څخه ډاونلوډ شي. ګالری په ورته وخت کې، هغه بلاکونه چې په محلي ذخیره کې پاتې دي د بادل څخه به ډاونلوډ نشي. د بیا رغونې شاخص ته ویاړ (هو، دا د مقالې په پیل کې هم یادونه شوې وه).
د دې قضیې یو فرعي ډول دا دی چې د SOBR ټول ذخیره د لاسرسي وړ نه وه. په دې حالت کې، موږ د محلي ذخیرې څخه د کاپي کولو لپاره هیڅ نه لرو، او ټول بلاکونه د بادل څخه ډاونلوډ شوي دي.
او ترټولو په زړه پورې حالت دا دی چې د بیک اپ سرور مړ شو. دلته دوه اختیارونه شتون لري: اډمین عالي دی او د تشکیلاتو بیک اپ یې جوړ کړی ، او مدیر پخپله یو بد Pinocchio دی او د تشکیلاتو بیک اپ یې نه دی رامینځته کړی.
په لومړي حالت کې، دا به د هغه لپاره کافي وي چې په ساده ډول د VBR پاک نصب ځای ځای پرځای کړي او د معیاري وسیلو په کارولو سره د بیک اپ څخه ډیټابیس بیرته راولي. د دې پروسې په پای کې، هرڅه به عادي حالت ته راشي. یا دا به د پورته سناریوګانو څخه یو له مخې بحال شي.
خو که مدیر یې خپل دښمن وي او یا هم د تشکیلاتو بیک اپ هم له لویې ناکامۍ سره مخ شوی وي، نو دلته به یې هم د قسمت رحم ته نه پریږدي. د دې قضیې لپاره، موږ یو نوی طرزالعمل معرفي کړی چې د وارداتو آبجیکٹ ذخیره نومیږي. دا تاسو ته اجازه درکوي په لاسي ډول د SOBR ذخیره کولو پروسه پریږدئ او د راتلونکي ریسکین سره دې ته د ظرفیت شوټینګ رینج ضمیمه کړئ ، او په ساده ډول د ویم انٹرفیس ته د ذخیره کولو څیز اضافه کړئ او د وارداتو ذخیره کولو ذخیره پروسیجر پرمخ وړئ. یوازینی شی چې کولی شي ستاسو او ستاسو د بیک اپونو ترمینځ په لاره کې ودریږي د پټنوم دننه کولو غوښتنه ده که ستاسو بیک اپ کوډ شوی وي.
دا شاید ټول د کاپي موډ په اړه وي او موږ پرمخ ځو
مهر شوی حالت
اصلي نظر دا دی چې نوي بیک اپ نشي کولی د ذخیره کولو ټاکل شوي SOBR حد کې څرګند شي. د v10 دمخه ، موږ یوازې د ساتنې حالت درلود ، کله چې د ذخیره کولو سره کوم کار په بشپړ ډول منع و. د ذخیره کولو بندولو لپاره یو ډول هارډکور حالت، چیرې چې یوازې د Evacuate تڼۍ شتون لري، کوم چې یو ځل بل حد ته بیک اپ لیږدوي.
او مهر شوي حالت یو ډول "نرم" اختیار دی: موږ د نوي بیک اپ رامینځته کول منع کوو او په تدریجي ډول د ټاکل شوي ساتلو سره سم زاړه حذف کوو ، مګر په پروسه کې موږ د زیرمو نقطو څخه د بیرته راګرځولو وړتیا له لاسه نه ورکوو. یو ډیر ګټور شی کله چې موږ یا د هارډویر یوه ټوټه د خپل ژوند پای ته نږدې وي او د هغې ځای په ځای کولو ته اړتیا لرو، یا موږ اړتیا لرو چې دا د یو څه مهم لپاره آزاد کړو، مګر هیڅ ځای شتون نلري چې دا واخلي او په یوځل کې هرڅه حرکت وکړي. یا دا نشي حذف کیدی.
په دې اساس، د عملیاتو اصول خورا ساده دي: دا اړینه ده چې د لیکلو ټول عملیات منع کړئ (د نوي معلوماتو بڼه)، لوستل (بیارغونې) او حذف کول (ساتنه).
دواړه حالتونه په یو وخت کې کارول کیدی شي، مګر په یاد ولرئ چې ساتنه لوړ لومړیتوب لري.
د مثال په توګه، یو SOBR په پام کې ونیسئ چې دوه برخې لري. راځئ چې فرض کړو چې د لومړیو څلورو ورځو لپاره موږ د Forward Forever Incremental mode کې بیک اپ جوړ کړو، او بیا موږ حد سیل کړو. دا د دې حقیقت لامل کیږي چې موږ په دوهم موجود حد کې د نوي فعال بشپړ رامینځته کول پیل کوو. که زموږ ساتل څلور وي، نو کله چې په مهر شوي حد کې واقع ټوله سلسله له خپل حد څخه تیریږي، دا په روښانه ضمیر سره حذف کیږي.
داسې شرایط شتون لري کله چې له مینځه وړل دمخه پیښیږي. د مثال په توګه، دا د دورې ډکونو سره د فارورډ زیاتوالی دی. که موږ د لومړیو دوو ورځو لپاره بشپړ بیک اپ جوړ کړو، او د پنجشنبې په ورځ موږ پریکړه وکړو چې ذخیره مهر کړو، نو د جمعې په ورځ، کله چې یو نوی بیک اپ رامینځته شي، د دوشنبې لپاره فایل به حذف شي ځکه چې دې ټکي ته هیڅ انحصار نشته. او ټکی پخپله په هیچا پورې اړه نلري. بیا موږ انتظار کوو تر هغه چې څلور ټکي په موجود حد کې رامینځته شي او پاتې درې یې حذف کړئ ، کوم چې په خپلواک ډول له یو بل څخه حذف کیدی نشي.
د ریورس زیاتوالي سره شیان ساده دي. په دې کې، زاړه ټکي په هیڅ شی پورې اړه نلري او په خوندي توګه حذف کیدی شي. نو، هرڅومره ژر چې یو نوی .vbk په نوي حد کې رامینځته شي ، زاړه .vrbs به یو یو له مینځه ویسي.
په هرصورت، موږ ولې هر ځل یو نوی .vbk جوړوو: که موږ دا نه وي رامینځته کړی، مګر د زیاتوالي زوړ سلسله ته دوام ورکړي، نو زوړ .vbk به په هر حالت کې د اوږدې مودې لپاره کنګل شي، د هغې د حذف کیدو مخه نیسي. له همدې امله، پریکړه وشوه چې څومره ژر چې حد مهر شي، موږ په وړیا حد کې بشپړ بیک اپ جوړ کړو.
شیان د ظرفیت شوټینګ حد سره ډیر پیچلي دي.
لومړی، راځئ چې د کاپي حالت وګورو. راځئ فرض کړو چې موږ په فعاله توګه د څلورو ورځو لپاره بیک اپ رامینځته کوو ، او بیا د ظرفیت شوټینګ سلسله قطع شوې وه. موږ هیڅ شی نه حذف کوو ، مګر په عاجزۍ سره ساتل برداشت کوو ، وروسته لدې چې موږ د ظرفیت شوټینګ حد څخه ډاټا حذف کوو.
نږدې ورته شی د حرکت حالت کې پیښیږي - موږ د بیا رغونې لپاره انتظار کوو ، په ځایی ذخیره کې زوړ حذف کوو ، او د څیز ذخیره کې زیرمه شوی حذف کوو.
د فارورورډ انکریمینټ سره یو په زړه پوری مثال. موږ ساتل په دریو ټکو کې نصب کوو او د دوشنبې په ورځ بیک اپ رامینځته کوو ، کوم چې په منظم ډول کلاوډ ته کاپي کیږي. د ذخیره کولو سیل کولو وروسته ، بیک اپ رامینځته کیدو ته دوام ورکوي ، د دریو ټکو ساتل ، مګر د ظرفیت ډیش کې زیرمه شوي ډیټا انحصار پاتې کیږي او حذف کیدی نشي. له همدې امله، موږ تر پنجشنبې پورې انتظار کوو، کله چې زموږ .vbk د ساتلو څخه بهر وي، او یوازې بیا موږ په آرامۍ سره ټول خوندي شوي سلسله حذف کوو.
او یو کوچنی اعلان: دلته ټول مثالونه د یو ماشین سره ښودل شوي. که تاسو په خپل بیک اپ کې ډیری یې لرئ، نو بیا د دوی بیا رغونه به د دې پورې اړه ولري چې ایا فعال بشپړ شوی یا نه.
دا په اصل کې ټول هغه څه دي. نو راځئ چې خورا سخت فیچر ته لاړ شو -
بې کفایتي
د تیرو ټکو په څیر، لومړی شی دا دی چې دا فعالیت کومه ستونزه حل کوي. هرڅومره ژر چې موږ خپل بیک اپ د ذخیره کولو لپاره چیرته اپلوډ کړو ، د دوی د خوندیتوب تضمین کولو لپاره قوي هیله شتون لري ، دا د ورکړل شوي ساتلو پرمهال په فزیکي توګه د دوی حذف کول او کوم ترمیم منع کول دي. د مدیرانو په شمول، په شمول د دوی د روټ حسابونو لاندې. دا تاسو ته اجازه درکوي چې دوی د ناڅاپي یا قصدي زیان څخه خوندي کړئ. هرڅوک چې د AWS سره کار کوي ممکن د ورته ځانګړتیا سره مخ شوي وي چې د آبجیکٹ لاک په نوم یادیږي.
اوس راځئ چې په عمومي شرایطو کې موډ وګورو، او بیا توضیحاتو ته لاړ شو. زموږ په مثال کې، بې ثباتي به زموږ د ظرفیت شوټینګ حد لپاره د څلورو ورځو ساتلو سره فعاله شي. او د کاپي حالت په بیک اپ کې فعال شوی.
بې ثباتي په هیڅ ډول د عمومي ساتلو سره اړیکه نه لري. د مثال په توګه، دا اضافي ټکي یا داسې څه نه اضافه کوي. دا یوازې دا دی چې یو څوک نشي کولی د څلورو ورځو دننه بیک اپ فایلونه حذف کړي. که تاسو د دوشنبې په ورځ بیک اپ جوړ کړئ، تاسو به یوازې د جمعې په ورځ د هغې فایل حذف کړئ.
د ډیهایډریشن ، شاخصونو او میټاډاټا ټول دمخه تشریح شوي مفکورې په ورته ډول کار کولو ته دوام ورکوي. مګر د یو شرط سره - بلاک نه یوازې د معلوماتو لپاره، بلکې د میټاډاټا لپاره هم ټاکل شوی. دا په هغه صورت کې ترسره کیږي چې یو هوښیار برید کونکی پریکړه وکړي چې زموږ د میټاډاټا ډیټابیس له مینځه یوسي او د ډیټا بلاکونو مخه ونیسي چې بې ګټې بائنری مچ ته بدل شي.
اوس زموږ د بلاک نسل ټیکنالوژۍ تشریح کولو لپاره خورا ښه وخت دی. یا بلاک نسل. د دې کولو لپاره، هغه وضعیت په پام کې ونیسئ چې د هغې ظهور لامل شوی.
راځئ چې د وخت اندازه شپږ ورځې واخلو او لاندې به موږ د متوقع پای ته رسیدو وخت په نښه کړو. په لومړۍ ورځ موږ یو فایل اخلو او رامینځته کوو چې د ډیټا بلاک a او د هغې میټاډاټا لري. که چیرې بې ثباتي په دریو ورځو کې ټاکل شوې وي ، نو دا منطقي ده چې فرض کړئ چې په څلورمه ورځ به ډاټا خلاص او حذف شي. په دویمه ورځ به موږ یو نوی فایل 2 اضافه کړو، د ورته ترتیباتو سره د بلاک ب څخه جوړ شوی. بلاک A لاهم په څلورمه ورځ لرې کولو ته اړتیا لري. مګر په دریمه ورځ یو څه ویره پیښیږي - د فایل 3 فایل رامینځته کیږي ، چې د نوي بلاک d او زاړه بلاک a سره لینک لري. دا پدې مانا ده چې د بلاک لپاره او د هغې د بدلیدو بیرغ باید یوې نوې نیټې ته له سره تنظیم شي، کوم چې شپږمې ورځې ته لیږدول کیږي. او دلته یوه ستونزه رامینځته کیږي - په ریښتیني بیک اپ کې د ورته بلاکونو لوی شمیر شتون لري. او د دې لپاره چې د دوی د بدلون موده وغځول شي، تاسو اړتیا لرئ هر ځل ډیری غوښتنې وکړئ. او په حقیقت کې ، دا به نږدې نه ختمیدونکي ورځنۍ پروسه وي ، ځکه چې د لوړې کچې احتمال سره به موږ د هرې کاپي سره د تخریب شوي بلاکونو لوی سټیکونه ومومئ. د اعتراض ذخیره کولو چمتو کونکو څخه لوی شمیر غوښتنې څه معنی لري؟ سمه ده! د میاشتې په پای کې لوی بل.
او د دې لپاره چې د پام وړ پیسو لپاره ستاسو د خوښې پیرودونکي افشا نه کړئ ، د بلاک تولید میکانیزم اختراع شوی و. دا یوه اضافي دوره ده چې موږ یې د ټاکل شوي غیر متغیر دورې سره اضافه کوو. په لاندې مثال کې، دا موده دوه ورځې ده. مګر دا یوازې یو مثال دی. په واقعیت کې، دوی خپل فارمول کاروي، کوم چې د میاشتني بند په جریان کې نږدې لس اضافي ورځې ورکوي.
راځئ چې ورته وضعیت په پام کې ونیسو، مګر د بلاک نسل سره. په لومړۍ ورځ موږ د بلاک A او میټاډاټا څخه فایل 1 جوړوو. موږ د نسل دوره او تغیر اضافه کوو - پدې معنی چې د فایل حذف کولو فرصت به په شپږمه ورځ وي. که په دوهمه ورځ موږ فایل 2 رامینځته کړو ، د بلاک b او د بلاک a لینک کولو لپاره ، نو بیا د حذف کیدو تمه نیټې ته هیڅ نه پیښیږي. هغه په شپږمه ورځ ولاړه وه. او پدې توګه موږ هڅه کوو چې د غوښتنو په شمیر کې پیسې خوندي کړو. یوازینی حالت چې د وخت نیټه لیږدول کیدی شي که چیرې د نسل موده پای ته ورسیږي. دا دی ، که چیرې په دریمه ورځ نوې فایل 3 د بلاک کولو لینک ولري ، نو نسل 2 به اضافه شي ځکه چې Gen1 دمخه پای ته رسیدلی. او د بلاک A د حذف کولو تمه شوې نیټه به اتمې ورځې ته واړول شي. دا موږ ته اجازه راکوي چې په ډراماتیک ډول د غوښتنلیکونو شمیر کم کړو ترڅو د نقل شوي بلاکونو د ژوند موده وغځوو ، کوم چې پیرودونکي یو ټن پیسې خوندي کوي.
دا ټیکنالوژي پخپله د S3 او S3 سره مطابقت لرونکي هارډویر کاروونکو ته شتون لري ، چې جوړونکي یې تضمین کوي چې د دوی پلي کول د ایمیزون څخه توپیر نلري. له همدې امله د مشروع پوښتنې ځواب چې ولې Azure نه ملاتړ کیږي - دوی ورته ځانګړتیا لري، مګر دا د کانټینرونو په کچه کار کوي، نه د انفرادي شیانو. په لاره کې، ایمیزون پخپله په دوه حالتونو کې د اعتراض لاک لري: اطاعت او حکومتداري. په دوهم حالت کې ، دا امکان شتون لري چې د اډمین څخه پورته لوی مدیر او د ریښو پورته ریښې ، د اعتراض لاک سره سره ، لاهم ډیټا حذف کوي. د موافقت په حالت کې ، هرڅه په کلکه سره کیل شوي او هیڅ څوک نشي کولی بیک اپ حذف کړي. حتی د ایمیزون مدیران (د دوی د رسمي بیانونو له مخې). دا هغه موډل دی چې موږ یې ملاتړ کوو.
او، د معمول په څیر، ځینې ګټور لینکونه:
- په په هر تفصیل کې.
- په اړه ټول معلومات په غوره توګه
- О په جزئياتو سره
سرچینه: www.habr.com