خطاهای برنامه معمولی که منجر به نفخ در postgresql می شود. آندری سالنیکوف

پیشنهاد می کنم متن گزارش آغاز سال 2016 توسط آندری سالنیکوف "خطاهای معمولی در برنامه های کاربردی که منجر به نفخ در postgresql می شود" را بخوانید.

در این گزارش به تحلیل خطاهای اصلی اپلیکیشن ها می پردازم که در مرحله طراحی و نوشتن کد اپلیکیشن رخ می دهد. و من فقط آن دسته از خطاهایی را که منجر به نفخ در Postgresql می شود، می گیرم. به عنوان یک قاعده، این آغاز پایان عملکرد سیستم شما به عنوان یک کل است، اگرچه در ابتدا هیچ پیش نیازی برای این کار دیده نشد.

خوشحالم که به همه خوش آمد می گویم! این گزارش مانند گزارش قبلی همکارم فنی نیست. هدف این گفتگو توسعه دهندگان سیستم های بک اند عمدتاً به این دلیل است که ما تعداد نسبتاً زیادی مشتری داریم. و همه آنها یک اشتباه را مرتکب می شوند. من در مورد آنها به شما خواهم گفت. من توضیح خواهم داد که این اشتباهات منجر به چه مرگبار و بدی می شود.

چرا اشتباهات انجام می شود؟ آنها به دو دلیل انجام می شوند: به صورت تصادفی، شاید به دلیل ناآگاهی از مکانیسم هایی که در سطح بین پایه و برنامه و همچنین در خود پایه رخ می دهد، کار کند.

من سه مثال با تصاویر وحشتناک از بد شدن اوضاع برای شما می‌آورم. مکانیسمی را که در آنجا رخ می دهد به اختصار شرح خواهم داد. و نحوه برخورد با آنها، زمان وقوع آنها و چه روشهای پیشگیرانه برای جلوگیری از اشتباهات استفاده شود. من در مورد ابزارهای کمکی به شما می گویم و پیوندهای مفیدی می دهم.

من از یک پایگاه داده آزمایشی استفاده کردم که در آن دو جدول داشتم. یک صفحه با حساب های مشتری، دیگری با عملیات روی این حساب ها. و با مقداری دوره ای، مانده های این حساب ها را به روز می کنیم.

اطلاعات اولیه صفحه: بسیار کوچک است، 2 مگابایت. زمان پاسخگویی برای پایگاه داده و به طور خاص برای صفحه نیز بسیار خوب است. و بار نسبتاً خوب - 2 عملیات در ثانیه روی صفحه.

و از طریق این گزارش نمودارهایی را به شما نشان خواهم داد تا مشخص شود چه اتفاقی دارد می افتد. همیشه 2 اسلاید با نمودار وجود خواهد داشت. اسلاید اول چیزی است که به طور کلی روی سرور اتفاق می افتد.

و در این شرایط می بینیم که واقعا بشقاب کوچکی داریم. ایندکس کوچک و 2 مگابایت است. این اولین نمودار سمت چپ است.

میانگین زمان پاسخگویی در سراسر سرور نیز پایدار و کم است. این نمودار بالا سمت راست است.

نمودار پایین سمت چپ طولانی ترین تراکنش ها است. می بینیم که تراکنش ها به سرعت تکمیل می شوند. و اتو وکیوم هنوز در اینجا کار نمی کند، زیرا - این یک تست شروع بود. آن وقت کار خواهد کرد و برای ما مفید خواهد بود.

اسلاید دوم همیشه به صفحه آزمایش اختصاص داده می شود. در این شرایط ما به طور مداوم موجودی حساب مشتری را به روز می کنیم. و می بینیم که میانگین زمان پاسخ برای عملیات به روز رسانی بسیار خوب است، کمتر از یک میلی ثانیه. می بینیم که منابع پردازنده (این نمودار بالا سمت راست است) نیز به طور مساوی و بسیار کم مصرف می شود.

نمودار پایین سمت راست نشان می دهد که قبل از به روز رسانی خط مورد نظر خود، چه مقدار حافظه عملیاتی و دیسک را طی می کنیم. و تعداد عملیات روی صفحه همان طور که در ابتدا گفتم 2 در ثانیه است.

و حالا ما یک فاجعه داریم. به دلایلی، یک معامله فراموش شده برای مدت طولانی رخ می دهد. دلایل معمولاً همه پیش پا افتاده است:

• یکی از رایج ترین آنها این است که ما شروع به دسترسی به یک سرویس خارجی در کد برنامه کردیم. و این سرویس جواب ما را نمی دهد. یعنی ما یک تراکنش باز کردیم، تغییری در پایگاه داده ایجاد کردیم و از برنامه برای خواندن نامه یا سرویس دیگری در زیرساختمان رفتیم و به دلایلی به ما پاسخ نمی دهد. و جلسه ما در یک وضعیت معلق ماند - معلوم نیست چه زمانی حل می شود.
• حالت دوم زمانی است که به دلایلی یک استثنا در کد ما رخ داده است. و ما بسته شدن معامله را در استثنا پردازش نکردیم. و ما یک جلسه معلق با یک تراکنش باز دریافت کردیم.
• و آخرین مورد نیز بسیار رایج است. این کد بی کیفیت است. برخی از چارچوب ها یک تراکنش را باز می کنند. آویزان است و ممکن است در برنامه ندانید که آن را آویزان کرده اید.

چنین چیزهایی به کجا منتهی می شود؟

به این واقعیت که جداول و شاخص های ما شروع به افزایش چشمگیر کرده اند. این دقیقا همان اثر نفخ است. برای پایگاه داده، این به این صورت بیان خواهد شد که افزایش بسیار شدیدی در زمان پاسخگویی پایگاه داده خواهیم داشت، بار روی سرور پایگاه داده افزایش می یابد. و در نتیجه، برنامه ما آسیب خواهد دید. زیرا اگر در کد خود 10 میلی ثانیه را برای یک درخواست به پایگاه داده، 10 میلی ثانیه بر روی منطق خود صرف کرده باشید، عملکرد شما 20 میلی ثانیه کار می کند. و اکنون وضعیت شما بسیار غم انگیز خواهد بود.

و ببینیم چه می شود. نمودار پایین سمت چپ نشان می دهد که ما یک تراکنش طولانی مدت داریم. و اگر به نمودار بالا سمت چپ نگاه کنیم، می بینیم که اندازه جدول از دو مگابایت به 300 مگابایت رسیده است. در عین حال، مقدار داده ها در جدول تغییر نکرده است، یعنی مقدار نسبتاً زیادی زباله وجود دارد.

وضعیت کلی از نظر میانگین زمان پاسخ سرور نیز با چندین مرتبه تغییر کرده است. یعنی تمام درخواست ها روی سرور به طور کامل کاهش یافتند. و همزمان فرآیندهای داخلی Postgres در مواجهه با autovacuum راه اندازی شد که سعی در انجام کاری و مصرف منابع دارند.

چه اتفاقی برای بشقاب ما می افتد؟ همینطور. میانگین زمان پاسخگویی در تبلت چندین مرتبه افزایش یافت. اگر به طور خاص از نظر منابع مصرف شده، می بینیم که بار روی پردازنده بسیار افزایش یافته است. این نمودار بالا سمت راست است. و افزایش یافته است زیرا پردازنده باید از طریق یک سری خطوط بی فایده در جستجوی مورد نیاز شما بگذرد. این نمودار پایین سمت راست است. و در نتیجه، تعداد تماس ها در هر ثانیه بسیار کاهش یافت، زیرا پایگاه داده زمان لازم برای پردازش همان تعداد درخواست را ندارد.

ما باید به زندگی برگردیم. ما وارد اینترنت می شویم و متوجه می شویم که تراکنش های طولانی منجر به مشکل می شود. ما این معامله را پیدا کرده و می کشیم. و همه چیز برای ما خوب پیش می رود. همه چیز همان طور که باید کار می کند.

ما آرام شدیم، اما پس از مدتی متوجه می شویم که برنامه مانند قبل از اورژانس کار نمی کند. درخواست ها به همین صورت آهسته تر و بسیار کندتر پردازش می شوند. به طور خاص در مثال من یک و نیم تا دو برابر کندتر است. بار روی سرور نیز بیشتر از قبل از حادثه است.

و سوال: "در این لحظه چه اتفاقی برای پایگاه می افتد؟". و با اساس یک وضعیت زیر وجود دارد. در نمودار تراکنش می بینید که متوقف شده و واقعا تراکنش های بلندمدتی وجود ندارد. اما ابعاد صفحه در حین تصادف به طرز مرگباری رشد کرد. و از آن زمان تاکنون کاهش نیافته است. میانگین زمان روی پایه تثبیت شده است. و به نظر می رسد که پاسخ ها به اندازه کافی با سرعت قابل قبولی برای ما پیش می روند. Autovacuum فعال تر شد و شروع به انجام کاری با تبلت کرد، زیرا نیاز به بیل کردن داده های بیشتری دارد.

به طور خاص، در جدول امتیاز آزمون، جایی که ما تعادل ها را تغییر می دهیم: به نظر می رسد زمان پاسخ به درخواست به حالت عادی بازگشته است. اما در واقع یک و نیم برابر بیشتر است.

و با بارگذاری روی پردازنده می بینیم که بار روی پردازنده قبل از خرابی به مقدار مورد نظر برنگشته است. و دلایل وجود دارد فقط در نمودار پایین سمت راست نهفته است. مشاهده می شود که مقداری از حافظه جستجو می شود. یعنی برای جستجوی خط مورد نظر، منابع سرور پایگاه داده را هنگام مرتب سازی داده های بی فایده صرف می کنیم. تعداد تراکنش ها در هر ثانیه تثبیت شده است.

در کل خوبه ولی اوضاع بدتر از اون چیزیه که بود. تخریب آشکار پایگاه داده در نتیجه برنامه ما که با این پایگاه داده کار می کند.

و برای درک آنچه در آنجا اتفاق می افتد، اگر در گزارش قبلی نبودید، اکنون کمی تئوری. نظریه در مورد فرآیند داخلی. چرا اتو وکیوم و چه کاری انجام می دهد؟

به معنای واقعی کلمه برای درک. در مقطعی از زمان ما یک جدول داریم. ما ردیف هایی در جدول داریم. این خطوط می توانند فعال باشند، زنده باشند، ما اکنون نیاز داریم. در تصویر با رنگ سبز مشخص شده اند. و خطوط ضرب الاجلی وجود دارد که قبلاً کار کرده اند ، به روز شده اند ، ورودی های جدید روی آنها ظاهر شده اند. و مشخص شده اند که دیگر برای پایگاه داده جالب نیستند. اما آنها به دلیل ویژگی های Postgres در جدول قرار دارند.

چرا به اتو وکیوم نیاز دارید؟ Autovacuum یک لحظه می آید، با پایگاه داده تماس می گیرد و از آن می پرسد: "لطفا شناسه قدیمی ترین تراکنش را که در حال حاضر در پایگاه داده باز است به من بدهید." پایگاه داده این شناسه را برمی گرداند. و اتو وکیوم با تکیه بر آن از خطوط جدول عبور می کند. و اگر ببیند که برخی از خطوط توسط تراکنش‌های بسیار قدیمی‌تر تغییر کرده‌اند، حق دارد آنها را به‌عنوان خطوطی علامت‌گذاری کند که می‌توانیم در آینده با نوشتن داده‌های جدید در آنجا دوباره از آنها استفاده کنیم. این یک فرآیند پس زمینه است.

در این زمان، ما به کار با پایگاه داده ادامه می دهیم، ما به ایجاد برخی تغییرات در جدول ادامه می دهیم. و روی این خطوط، که می توانیم دوباره از آنها استفاده کنیم، داده های جدید می نویسیم. و به این ترتیب ما یک چرخه می گیریم، یعنی تعدادی از خطوط قدیمی مرده همیشه در آنجا ظاهر می شوند، به جای آنها خطوط جدیدی را که نیاز داریم یادداشت می کنیم. و این حالت عادی برای کار PostgreSQL است.

در جریان تصادف چه اتفاقی افتاد؟ این روند چگونه انجام شد؟

ما یک بشقاب در شرایطی داشتیم، برخی زنده بودند، برخی از خطوط مرگ. اتو وکیوم رسیده است. او از پایگاه داده پرسید قدیمی ترین تراکنش ما چیست، شناسه آن چیست. من این شناسه را گرفتم که می تواند چندین ساعت و شاید ده دقیقه باشد. بستگی به میزان بار سنگینی که روی پایگاه داده دارید دارد. و او به دنبال خطوطی رفت که بتواند آنها را به عنوان استفاده مجدد علامت گذاری کند. و من چنین خطوطی را در جدول ما پیدا نکردم.

اما در این زمان ما به کار با جدول ادامه می دهیم. ما کاری در آن انجام می دهیم، آن را به روز می کنیم، داده ها را تغییر می دهیم. پایگاه داده در این زمان چه کاری باید انجام دهد؟ او چاره ای جز اضافه کردن خطوط جدید به انتهای جدول موجود ندارد. و بنابراین در ما اندازه میز شروع به متورم شدن می کند.

ما واقعاً برای کار کردن به خطوط سبز نیاز داریم. اما در طول چنین مشکلی، مشخص می شود که درصد خطوط سبز در کل حجم جدول بسیار کم است.

و زمانی که ما یک کوئری را اجرا می کنیم، پایگاه داده باید تمام خطوط قرمز و سبز را بگذراند تا خط مناسب را پیدا کند. و اثر باد کردن جدول با داده های بی فایده "نفخ" نامیده می شود که فضای دیسک ما را نیز می خورد. یادته 2 مگابایت بود الان 300 مگابایت شده؟ اکنون مگابایت را به گیگابایت تغییر دهید و به سرعت تمام منابع دیسک خود را از دست خواهید داد.

چه پیامدهایی برای ما دارد؟

• در مثال من، جدول و شاخص 150 برابر رشد کرده است. برخی از مشتریان ما موارد مرگبار بیشتری داشته اند که فضای دیسک به سادگی شروع به تمام شدن کرده است.
• میزها هرگز به خودی خود کوچک نمی شوند. اتو وکیوم در برخی موارد می تواند دم میز را قطع کند اگر فقط خطوط مرده وجود داشته باشد. اما از آنجایی که چرخش ثابت وجود دارد، ممکن است یک خط سبز در انتها آویزان شود و به روز نشود و بقیه در جایی در ابتدای صفحه ثبت شود. اما این یک اتفاق بعید است که خود میز شما از نظر اندازه کاهش می یابد، بنابراین نباید به آن امیدوار باشید.
• پایگاه داده باید تمام خطوط بی فایده را مرتب کند. و ما منابع دیسک، منابع پردازنده و برق را هدر می دهیم.
• و این به طور مستقیم بر برنامه ما تأثیر می گذارد، زیرا اگر در ابتدا 10 میلی ثانیه را برای یک درخواست، 10 میلی ثانیه روی کد خود صرف کنیم، در طول خرابی شروع به صرف یک ثانیه روی یک درخواست و 10 میلی ثانیه روی کد کردیم، یعنی یک مرتبه عملکرد برنامه قدر کاهش یافته است. و هنگامی که تصادف حل شد، ما شروع به صرف 20 میلی ثانیه برای هر درخواست، 10 میلی ثانیه برای هر کد کردیم. یعنی هنوز یک و نیم بار از نظر عملکرد غرق شدیم. و این همه به دلیل یک معامله است که قطع شد، و، شاید، به تقصیر ما.
• و سوال: "چگونه می توانم همه چیز را پس بگیرم؟" به طوری که همه چیز با ما خوب است و درخواست ها به سرعت قبل از تصادف انجام می شود.

برای این، یک چرخه کاری مشخص وجود دارد که در حال انجام است.

ابتدا باید جداول مشکل دار که نفخ کرده اند را پیدا کنیم. ما می دانیم که برخی از جداول به طور فعال تر ضبط می کنند، برخی با فعالیت کمتر. و برای این ما از پسوند استفاده می کنیم pgstattuple. با نصب این افزونه، می توانید پرس و جوهایی بنویسید تا به شما در یافتن جداولی که به اندازه کافی متورم هستند کمک کند.

وقتی این جداول را پیدا کردید، باید فشرده شوند. در حال حاضر ابزارهایی برای این کار وجود دارد. در شرکت ما از سه ابزار استفاده می کنیم. اولین مورد، VACUUM FULL داخلی است. او ظالم، خشن و بی رحم است، اما گاهی اوقات بسیار مفید است. pg_repack и pgcompactable ابزارهای شخص ثالث برای فشرده سازی جداول هستند. و در مورد پایگاه داده دقت بیشتری دارند.

آنها بسته به آنچه برای شما راحت تر است استفاده می شوند. اما من در پایان در مورد این صحبت خواهم کرد. نکته اصلی این است که سه ابزار وجود دارد. تعداد زیادی برای انتخاب وجود دارد.

پس از اینکه همه چیز را اصلاح کردیم، مطمئن شدیم که همه چیز خوب است، باید بدانیم چگونه از این وضعیت در آینده جلوگیری کنیم:

• جلوگیری از آن نسبتاً آسان است. شما باید مدت زمان جلسات را در سرور Master نظارت کنید. جلسات به خصوص خطرناک در حالت بیکار در وضعیت تراکنش. اینها کسانی هستند که فقط یک تراکنش را باز کردند، کاری انجام دادند و رفتند، یا به سادگی آویزان شدند، در کد گم شدند.
• و برای شما، به‌عنوان توسعه‌دهنده، مهم است که کد را در زمان بروز این شرایط آزمایش کنید. انجام این کار سخت نیست. این یک بررسی مفید خواهد بود. شما از بسیاری از مشکلات "کودکانه" مرتبط با معاملات طولانی جلوگیری خواهید کرد.

در این نمودارها، من می‌خواستم به شما نشان دهم که چگونه جدول و رفتار پایگاه داده پس از عبور از VACUUM FULL روی جدول در این مورد، تغییر کرد. این تولید من نیست.

اندازه جدول بلافاصله به حالت عادی خود یعنی چند مگابایت بازگشت. این تاثیر زیادی بر میانگین زمان پاسخگویی در سرور نداشت.

اما به طور خاص در جدول تست ما، جایی که موجودی حساب ها را به روز کردیم، می بینیم که میانگین زمان پاسخ به درخواست به روز رسانی داده های موجود در تبلت به سطح قبل از تصادف کاهش یافته است. منابع مصرف شده توسط پردازنده برای اجرای این درخواست نیز به سطوح قبل از خرابی سقوط کرد. و نمودار پایین سمت راست نشان می‌دهد که اکنون دقیقاً همان خطی را پیدا می‌کنیم که به آن نیاز داریم، بدون اینکه از میان انبوهی از خطوط مرده که قبل از فشرده شدن جدول بودند عبور کنیم. و میانگین زمان پرس و جو تقریباً در همان سطح باقی ماند. اما در اینجا من، بلکه، خطای سخت افزار خود را دارم.

اینجاست که داستان اول به پایان می رسد. او رایج ترین است. و این برای همه اتفاق می افتد، صرف نظر از تجربه مشتری، چقدر برنامه نویسان واجد شرایط وجود دارد. دیر یا زود این اتفاق می افتد.

داستان دوم، که در آن بارگذاری را توزیع می کنیم و منابع سرور را بهینه می کنیم

• ما بزرگ شده ایم و تبدیل به یک آدم جدی شده ایم. و ما درک می کنیم که ماکت داریم و خوب است که بار را متعادل کنیم: به استاد بنویسید و از روی ماکت بخوانید. و معمولا این وضعیت زمانی پیش می آید که بخواهیم نوعی گزارش یا ETL تهیه کنیم. و تجارت از این بابت بسیار خوشحال است. او واقعاً گزارش های متنوعی را با مجموعه ای از تحلیل های پیچیده می خواهد.
• گزارش‌ها ساعت‌ها دوام می‌آورند، زیرا تجزیه و تحلیل پیچیده را نمی‌توان در میلی‌ثانیه محاسبه کرد. ما مثل پسرهای شجاع کد می نویسیم. ما در برنامه درج که روی Master ضبط می کنیم، گزارش هایی را روی ماکت انجام می دهیم.
• بار را تقسیم می کنیم.
• همه چیز عالی کار می کند. ما عالی هستیم.

و این وضعیت چگونه به نظر می رسد؟ به طور خاص، در این نمودارها، مدت زمان تراکنش ها را از ماکت نیز برای مدت زمان تراکنش اضافه کردم. تمام نمودارهای دیگر فقط به سرور اصلی اشاره دارد.

در این زمان، هیئت گزارش من رشد کرده بود. تعداد آنها بیشتر است. می بینیم که میانگین زمان پاسخ سرور پایدار است. می بینیم که یک تراکنش طولانی در حال اجرا روی ماکت داریم که به مدت 2 ساعت اجرا می شود. ما شاهد کار بی سر و صدا از autovacuum هستیم که خطوط مرگ را پردازش می کند. و ما همه خوبیم

به طور خاص، طبق تبلت آزمایشی، ما همچنان به به روز رسانی موجودی حساب های موجود در آنجا ادامه می دهیم. و همچنین زمان پاسخگویی پایدار در صورت درخواست، مصرف منابع پایدار داریم. همه چیز با ما خوب است.

همه چیز خوب است تا لحظه ای که این گزارش ها در تضاد با تکرار به سمت ما شلیک می کنند. و آنها در فواصل زمانی معین به عقب شلیک می کنند.

ما آنلاین می شویم و شروع به خواندن چرایی این اتفاق می کنیم. و راه حلی پیدا می کنیم.

راه حل اول افزایش تأخیر تکرار است. می دانیم که گزارش ما 3 ساعت اجرا می شود. تاخیر تکرار را روی 3 ساعت تنظیم کنید. ما همه چیز را شروع می کنیم، اما همچنان با این واقعیت که گزارش ها گاهی اوقات پاسخ داده می شود، مشکل داریم.

ما می خواهیم همه چیز عالی باشد. بیایید جلوتر برویم. و ما یک تنظیمات جالب در اینترنت پیدا می کنیم - hot_standby_feedback. روشنش می کنیم. Hot_standby_feedback به ما این امکان را می دهد که خلاء خودکار را روی Master در حال اجرا نگه داریم. بنابراین، ما به طور کامل از تضادهای تکراری خلاص می شویم. و همه ما با گزارش ها خوب کار می کنیم.

و در حال حاضر با سرور Master چه اتفاقی می افتد؟ و با سرور Master، ما یک فاجعه کامل داریم. اکنون نمودارهایی را می بینیم که هر دوی این تنظیمات روشن هستند. و می بینیم که جلسه روی ماکت به نحوی بر وضعیت سرور Master تأثیر می گذارد. تأثیر می گذارد زیرا جارو برقی را که خطوط مرده را پاک می کند، معلق کرده است. اندازه جدول ما دوباره سر به فلک کشیده است. میانگین زمان اجرای پرس و جو در کل پایگاه داده نیز به شدت افزایش یافت. جارو برقی ها کمی سفت شدند.

به طور خاص، در بشقاب ما، می بینیم که به روز رسانی داده ها در آن نیز به آسمان پرید. مصرف منابع پردازنده نیز به طور مشابه بسیار افزایش یافته است. ما دوباره روی تعداد زیادی از خطوط بی فایده مرده تکرار می کنیم. و زمان پاسخگویی در این تبلت، تعداد تراکنش ها کاهش یافته است.

اگر ندانیم قبلاً در مورد چه چیزی صحبت می کردم، چه شکلی خواهد بود؟

• ما شروع به جستجوی مشکلات می کنیم. اگر در قسمت اول با مشکل مواجه شدیم، می دانیم که ممکن است دلیل یک تراکنش طولانی مدت همین باشد و از Master بالا می رویم. مشکل از استاد است. او را سوسیس می کند. او در حال گرم کردن است، او میانگین بارگذاری زیر صد دارد.
• درخواست‌ها در آنجا کاهش می‌یابند، اما هیچ تراکنش بلندمدتی در آنجا نمی‌بینیم. و ما نمی فهمیم چه خبر است. نمی دانیم کجا را نگاه کنیم.
• بررسی سخت افزار سرور شاید حمله ما از بین رفته است. شاید نوار حافظه را سوختیم. بله، هر چیزی می تواند باشد. اما نه، سرورها جدید هستند، همه چیز خوب کار می کند.
• همه اجرا می شوند: مدیران، توسعه دهندگان و کارگردان. هیچ چیز کمک نمی کند.
• و در یک نقطه، همه چیز به طور ناگهانی شروع به اصلاح می کند.

روی ماکت، در آن زمان، درخواست انجام شد و رفت. ما گزارشی دریافت کردیم تجارت هنوز خوشحال است. همانطور که می بینید سفره ما دوباره بزرگ شده و قرار نیست کم شود. در نمودار با جلسات، من یک قطعه از این تراکنش طولانی را از ماکت گذاشتم، تا بتوانید ارزیابی کنید که چقدر طول می کشد تا وضعیت تثبیت شود.

جلسه رفت. و فقط بعد از مدتی سرور کم و بیش مرتب می شود. و میانگین زمان پاسخگویی به درخواست ها در سرور Master به حالت عادی باز می گردد. از آنجا که، در نهایت، autovacuum فرصتی برای تمیز کردن، مشخص کردن این خطوط پایان یافت. و شروع به انجام کارش کرد. و چقدر سریع این کار را انجام می دهد، به همین سرعت ما مرتب خواهیم شد.

در جدول تست، جایی که موجودی حساب ها را به روز می کنیم، دقیقاً همان تصویر را می بینیم. میانگین زمان به‌روزرسانی حساب نیز به تدریج در حال عادی شدن است. منابع مصرف شده توسط پردازنده نیز کاهش می یابد. و تعداد تراکنش ها در هر ثانیه به حالت عادی بازگشته است. اما باز هم به حالت عادی بازگشت، نه مانند قبل از حادثه.

در هر صورت، مانند مورد اول، یک و نیم تا دو برابر، و گاهی اوقات حتی بیشتر، در عملکرد کاهش می‌یابیم.

به نظر می رسد ما همه چیز را درست انجام داده ایم. بار را توزیع کنید. تجهیزات بیکار نیستند. به گفته ذهن، آنها درخواست ها را شکستند، اما باز هم همه چیز بد شد.

• hot_standby_feedback را فعال نمی کنید؟ بله، روشن کردن آن بدون دلایل خاص توصیه نمی شود. زیرا این چرخش مستقیماً روی سرور مستر تأثیر می گذارد و کار اتوواکیوم را در آنجا به حالت تعلیق در می آورد. با روشن کردن آن بر روی تعدادی ماکت و فراموش کردن آن، می توانید استاد را بکشید و با مشکلات بزرگی در برنامه مواجه شوید.
• max_standby_streaming_delay افزایش یابد؟ بله، برای گزارش این است. اگر یک گزارش سه ساعته دارید و نمی‌خواهید به دلیل تداخل تکراری از کار بیفتد، به سادگی تاخیر را افزایش دهید. یک گزارش طولانی هرگز به داده هایی نیاز ندارد که در حال حاضر وارد پایگاه داده شده باشد. اگر آن را به مدت سه ساعت در اختیار دارید، آنگاه آن را برای مدت زمان داده قدیمی اجرا می کنید. و شما، آن سه ساعت تأخیر، آن شش ساعت تأخیر - هیچ نقشی بازی نخواهید کرد، اما گزارش‌ها را به طور مداوم دریافت خواهید کرد و از مشکلات سقوط آنها اطلاعی ندارید.
• به طور طبیعی، شما باید جلسات طولانی را روی ماکت ها کنترل کنید، به خصوص اگر تصمیم دارید که hot_standby_feedback را روی یک ماکت فعال کنید. چون ممکنه هر چیزی باشه این تذکر را به توسعه دهنده دادیم تا درخواست ها را آزمایش کند. او یک درخواست دیوانه وار نوشت. شروع کرد و رفت چای نوشید و استاد مستقر را گرفتیم. یا برنامه اشتباهی را در آنجا راه اندازی کردیم. موقعیت ها متنوع است. جلسات روی ماکت ها باید به همان دقتی که روی Master انجام می شود کنترل شوند.
• و اگر پرس و جوهای سریع و طولانی در مورد ماکت دارید، در این صورت بهتر است آنها را برای توزیع بار تقسیم کنید. این یک پیوند به streaming_delay است. برای سریع داشتن یک ماکت با تاخیر کم تکرار. برای درخواست‌های گزارش‌دهی طولانی‌مدت، یک ماکت داشته باشید که می‌تواند 6 ساعت، یک روز عقب بیفتد. این یک وضعیت کاملا طبیعی است.

ما عواقب را به همین ترتیب حذف می کنیم:

• میزهای پف کرده را پیدا می کنیم.
• و ما با راحت ترین ابزاری که برای ما مناسب است فشرده می کنیم.

داستان دوم در اینجا به پایان می رسد. بریم سراغ داستان سوم.

همچنین برای ما بسیار رایج است که در آن مهاجرت را انجام می دهیم.

• هر محصول نرم افزاری رشد می کند. الزامات در حال تغییر است. در هر صورت ما می خواهیم توسعه پیدا کنیم. و این اتفاق می افتد که ما باید داده های جدول را به روز کنیم، یعنی به روز رسانی را از نظر مهاجرت خود به عملکرد جدیدی که به عنوان بخشی از توسعه خود پیاده سازی می کنیم، اجرا کنیم.
• فرمت داده های قدیمی مناسب نیست. فرض کنید اکنون به جدول دوم می پردازیم، جایی که من روی این حساب ها عملیات دارم. و، بیایید بگوییم که آنها به روبل بودند، و ما تصمیم گرفتیم که دقت را افزایش دهیم و آن را به کوپک انجام دهیم. و برای این ما نیاز به یک به روز رسانی داریم: فیلد را با مقدار عملیات در صد ضرب کنید.
• در دنیای امروز، ما از ابزارهای خودکار نسخه‌سازی پایگاه داده استفاده می‌کنیم. بیایید بگوییم Liquibase. ما مهاجرت خود را در آنجا ثبت می کنیم. ما آن را روی پایه آزمایشی خود آزمایش می کنیم. همه چیز خوب است. آپدیت در حال اجراست. بلوک ها برای مدتی کار می کنند، اما ما داده های به روز دریافت می کنیم. و ما می توانیم عملکرد جدیدی را در این مورد راه اندازی کنیم. همه تست و بررسی شدند همه تایید شد
• کارهای برنامه ریزی شده را انجام داد، مهاجرت را انجام داد.

در اینجا مهاجرت با به روز رسانی ارائه شده در مقابل شما است. از آنجایی که من روی حساب ها عملیات دارم، صفحه 15 گیگابایت بود. و از آنجایی که ما هر خط را به روز می کنیم، صفحه را با به روز رسانی دو برابر کرده ایم، زیرا هر خط را بازنویسی کرده ایم.

در طول انتقال، ما نتوانستیم کاری با این برچسب انجام دهیم، زیرا تمام درخواست‌های مربوط به آن در صف قرار می‌گرفتند و منتظر می‌ماندند تا این به‌روزرسانی تمام شود. اما در اینجا می خواهم توجه شما را به اعدادی که در محور عمودی قرار دارند جلب کنم. یعنی میانگین زمان درخواست قبل از مهاجرت در منطقه 5 میلی ثانیه و بار روی پردازنده داریم، تعداد عملیات بلوک خواندن حافظه دیسک کمتر از 7,5 است.

مهاجرت کردیم و دوباره دچار مشکل شدیم.

مهاجرت موفقیت آمیز بود، اما:

• عملکرد قدیمی شروع به کار طولانی تری کرد.
• میز دوباره بزرگ شده است.
• بار روی سرور دوباره بیشتر از آنچه بود شده است.
• و، البته، ما هنوز درگیر عملکردی هستیم که به خوبی کار می کرد، ما آن را کمی بهبود دادیم.

و این دوباره نفخ است که دوباره زندگی ما را خراب می کند.

در اینجا نشان می دهم که جدول، مانند دو مورد قبلی، به اندازه های قبلی باز نمی گردد. به نظر می رسد میانگین بار روی سرور کافی است.

و اگر به جدول با حساب ها رجوع کنیم، خواهیم دید که میانگین زمان درخواست برای این جدول دو برابر شده است. بار روی پردازنده و تعداد خطوطی که باید در حافظه مرتب شوند به بالای 7,5 رسید، اما کمتر بود. و در مورد پردازنده ها 2 برابر، در مورد عملیات بلوک 1,5 برابر پرش کردیم، یعنی عملکرد سرور را کاهش دادیم. و در نتیجه - کاهش عملکرد برنامه ما. در همان زمان، تعداد تماس ها تقریباً در همان سطح باقی ماند.

و در اینجا نکته اصلی این است که بفهمیم چگونه چنین مهاجرت هایی را به درستی انجام دهیم. و باید انجام شوند. ما این مهاجرت ها را به طور منظم انجام می دهیم.

• چنین مهاجرت های بزرگی به صورت خودکار انجام نمی شود. آنها باید همیشه کنترل شوند.
• نیاز به نظارت یک فرد آگاه دارد. اگر DBA در تیم دارید، اجازه دهید DBA این کار را انجام دهد. کار اوست اگر نه، پس اجازه دهید با تجربه ترین فرد این کار را انجام دهد، که می داند چگونه با پایگاه های داده کار کند.
• طرح پایگاه داده جدید، حتی اگر یک ستون را به روز کنیم، همیشه در مراحل آماده می شویم، یعنی از قبل قبل از انتشار نسخه جدید برنامه:
• فیلدهای جدیدی اضافه شده است که در آنها فقط داده های به روز شده را می نویسیم.
• داده ها را از فیلد قدیمی به قسمت جدید در قسمت های کوچک منتقل می کنیم. چرا ما داریم این کار را می کنیم؟ اول، ما همیشه روند این فرآیند را کنترل می کنیم. ما می دانیم که قبلاً تعداد زیادی دسته انتقال داده ایم و تعداد زیادی باقی مانده است.
• و دومین اثر مثبت این است که بین هر دسته ای از این دست، یک تراکنش را می بندیم، یک معامله جدید را باز می کنیم، و این باعث می شود که اتوواکیوم مطابق با صفحه کار کند، خطوط مهلت برای استفاده مجدد را مشخص کند.
• برای خطوطی که در حین عملکرد برنامه ظاهر می شوند (ما هنوز برنامه قدیمی را داریم)، ​​ماشه ای اضافه می کنیم که مقادیر جدیدی را در فیلدهای جدید می نویسد. در مورد ما، این یک ضرب در صد مقدار قدیمی است.
• اگر کاملاً سرسخت هستیم و همان فیلد را می‌خواهیم، ​​پس از اتمام همه مهاجرت‌ها و قبل از ارسال نسخه جدید برنامه، به سادگی نام فیلدها را تغییر می‌دهیم. قسمت های قدیمی را به نام اختراعی تبدیل می کنیم و نام فیلدهای جدید را به قسمت های قدیمی تغییر می دهیم.
• و تنها پس از آن نسخه جدیدی از برنامه را راه اندازی می کنیم.

و در عین حال دچار نفخ نخواهیم شد و در عملکرد دچار افت نخواهیم شد.

این پایان داستان سوم است.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

و حالا کمی بیشتر در مورد ابزارهایی که در همان داستان اول ذکر کردم.

قبل از جستجوی bloat، باید افزونه را نصب کنید pgstattuple.

برای اینکه شما درخواست ها را اختراع نکنید، ما قبلاً این درخواست ها را در کار خود نوشته ایم. می توانید از آنها استفاده کنید. در اینجا دو درخواست وجود دارد.

• اولین مورد زمان زیادی می برد، اما مقادیر دقیق نفخ را مطابق جدول به شما نشان می دهد.
• مورد دوم سریع‌تر عمل می‌کند و زمانی بسیار مؤثر است که باید به سرعت ارزیابی کنید که آیا نفخ در جدول وجود دارد یا خیر. و همچنین باید درک کنید که همیشه یک نفخ در جدول Postgres وجود دارد. این ویژگی مدل MVCC اوست.
• و 20% نفخ برای میزها در بیشتر موارد خوب است. یعنی نگران نباشید و این جدول را فشرده کنید.

ما متوجه شدیم که چگونه جداولی را که با ما متورم شده اند شناسایی کنیم، علاوه بر این، زمانی که با داده های بی فایده متورم شده اند.

حالا در مورد نحوه رفع نفخ:

• اگر یک صفحه کوچک و دیسک های خوب، یعنی روی یک صفحه تا یک گیگابایت داشته باشیم، می توان از VACUUM FULL استفاده کرد. او برای چند ثانیه یک قفل انحصاری از شما می گیرد و خوب است، اما همه چیز را سریع و خشن انجام می دهد. VACUUM FULL چه کاری انجام می دهد؟ یک قفل انحصاری روی میز می گیرد و ردیف های زنده را از جداول قدیمی به جدول جدید بازنویسی می کند. و در پایان جایگزین آنها می شود. فایل های قدیمی را حذف می کند، فایل های جدید را جایگزین فایل های قدیمی می کند. اما در طول مدت کار خود، یک قفل انحصاری روی میز می گیرد. این بدان معنی است که شما نمی توانید کاری با این جدول انجام دهید: نه در آن بنویسید، نه در آن بخوانید و نه آن را اصلاح کنید. و VACUUM FULL به فضای دیسک اضافی برای نوشتن داده نیاز دارد.
• ابزار بعدی pg_repack. بر اساس اصل خود، بسیار شبیه به VACUUM FULL است، زیرا همچنین داده ها را از فایل های قدیمی به فایل های جدید بازنویسی می کند و آنها را در جدول جایگزین می کند. اما در عین حال در همان ابتدای کار خود قفل انحصاری روی میز نمی گیرد، بلکه آن را فقط در لحظه ای که داده های آماده دارد برای جایگزینی فایل ها می گیرد. این دیسک همان منابع مورد نیاز دیسک VACUUM FULL را دارد. شما به فضای دیسک اضافی نیاز دارید، و اگر جداول ترابایتی دارید، گاهی اوقات بسیار مهم است. و او در مورد پردازنده بسیار حریص است ، زیرا او به طور فعال با I / O کار می کند.
• سودمند سوم است pgcompactable. این منابع با دقت بیشتری برخورد می کند، زیرا بر اساس اصول کمی متفاوت کار می کند. ماهیت اصلی pgcompacttable این است که تمام ردیف های زنده را با به روز رسانی در جدول به ابتدای جدول منتقل می کند. و سپس خلاء روی این جدول را شروع می کند، زیرا می دانیم که ردیف های زنده در ابتدا و ردیف های مرده در پایان داریم. و خود خلاء این دم را قطع می کند، یعنی به فضای دیسک اضافی زیادی نیاز ندارد. و در عین حال، هنوز هم می توان آن را توسط منابع فشرده کرد.

همه چیز با ابزار.

اگر موضوع نفخ را از نظر کاوش بیشتر به داخل جالب می‌دانید، در اینجا چند لینک مفید برای شما وجود دارد:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres گزارش همکار من است این کلی است که جایگاه پستگر در مسیر کار و زندگی اش به کجا می رود. و یک قطعه فنی بسیار بزرگ و دقیق برای DBA در مورد bloat وجود دارد.
• https://github.com/dataegret/pg-utils پیوندی به مخزن ما است، جایی که ما مجموعه ای از اسکریپت های مفید را برای بررسی وضعیت پایگاه داده ذخیره می کنیم. در آنجا می توانید اسکریپت های جستجوی bloat را پیدا کنید.
• Третья и چهارم پیوندهایی به ابزارهایی که به شما کمک می کنند صفحات را فشرده کنید.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html این یک پست از همکار من است. در آنجا او کاملاً جدی و فنی نفخ را با جزئیات در سطحی نزدیک به مدیران تجزیه و تحلیل می کند.

در اینجا سعی کردم یک داستان ترسناک را برای توسعه دهندگان نشان دهم، زیرا آنها مشتریان مستقیم پایگاه های داده ما هستند و باید بفهمند که به چه چیزی و چه اقداماتی منجر می شود. امیدوارم موفق شده باشم. با تشکر از توجه شما!

پرسش

با تشکر از گزارش! شما در مورد چگونگی شناسایی مشکلات صحبت کردید. چگونه می توان به آنها هشدار داد؟ یعنی شرایطی داشتم که درخواست‌ها نه تنها به این دلیل که به برخی از خدمات خارجی روی آوردند آویزان شدند. این فقط چند پیوند وحشی بود. درخواست های کوچک و بی ضرری وجود داشت که یک روز در اطراف بود و سپس شروع به انجام نوعی مزخرف کرد. یعنی خیلی شبیه چیزی است که شما توضیح می دهید. چگونه آن را پیگیری کنیم؟ بنشین و مدام تماشا کن کدام درخواست گیر کرده است؟ چطور میتوان مانع آن شد؟

در این مورد، این یک وظیفه برای مدیران شرکت شما است، نه لزوماً برای DBA.

من یک مدیر هستم.

PostgreSQL یک نمای به نام pg_stat_activity دارد که پرس و جوهای معلق را نشان می دهد. و می توانید ببینید که چقدر در آنجا آویزان است.

من باید هر 5 دقیقه بیام و نگاه کنم؟

cron را راه اندازی کنید و بررسی کنید. اگر درخواست طولانی دارید، نامه بنویسید و تمام. یعنی نیازی نیست با چشمان خود نگاه کنید، این می تواند خودکار باشد. نامه ای دریافت می کنید، به آن پاسخ می دهید. یا می توانید به طور خودکار شلیک کنید.

آیا دلایل روشنی وجود دارد که چرا این اتفاق می افتد؟

تعدادی را فهرست کرده ام. نمونه های پیچیده تر دیگر و می تواند یک مکالمه طولانی باشد.

با تشکر از گزارش! من می خواستم در مورد ابزار pg_repack توضیح دهم. اگر قفل انحصاری نمی گیرد، پس...

او یک قفل اختصاصی درست می کند.

... در این صورت ممکن است اطلاعات را از دست بدهم. آیا برنامه من در این زمان نباید چیزی را ضبط کند؟

نه، بی سر و صدا با جدول کار می کند، یعنی pg_repack ابتدا تمام خطوط زنده موجود در آنجا را منتقل می کند. طبیعتاً نوعی رکورد در جدول وجود دارد. او فقط این دم اسبی را پرتاب می کند.

یعنی باز هم در آخر انجام می دهد؟

در پایان، یک قفل انحصاری برای تعویض این فایل ها می گیرد.

آیا سریعتر از VACUUM FULL خواهد بود؟

VACUUM FUL، همانطور که شروع شد، بلافاصله یک قفل منحصر به فرد گرفت. و تا زمانی که همه کارها را انجام ندهد، او را رها نمی کند. و pg_repack فقط در زمان جایگزینی فایل ها یک قفل انحصاری می گیرد. در این مرحله، شما آنجا نمی نویسید، اما داده ها از بین نخواهند رفت، همه چیز مرتب خواهد بود.

سلام! شما در مورد کار اتو وکیوم صحبت کردید. یک نمودار با سلول های قرمز، زرد و سبز رکورد وجود داشت. یعنی زردها - آنها را به عنوان حذف شده علامت گذاری کرد. و در نتیجه می توانید چیز جدیدی در آنها بنویسید؟

آره. Postgres ردیف ها را حذف نمی کند. او چنین ویژگی خاصی دارد. اگر خط را به روز می کردیم، خط قدیمی را به عنوان حذف شده علامت گذاری می کنیم. شناسه تراکنش که این خط را تغییر داده است در آنجا قرار می گیرد و ما یک خط جدید می نویسیم. و ما جلساتی داریم که به طور بالقوه می توانند آنها را بخوانند. در برخی موارد، آنها کاملا پیر می شوند. و ماهیت autovacuum این است که از میان این خطوط عبور می کند و آنها را به عنوان غیر ضروری علامت گذاری می کند. و در آنجا می توانید داده ها را بازنویسی کنید.

من میفهمم. اما سوال در این مورد نیست. من موافق نبودم فرض کنید یک میز داریم. دارای فیلدهای با اندازه متغیر است. و اگر بخواهم چیز جدیدی وارد کنم، ممکن است به سادگی در سلول قدیمی قرار نگیرد.

خیر، در هر صورت کل خط به روز می شود. Postgres دارای دو مدل ذخیره سازی است. از نوع داده انتخاب می کند. داده هایی وجود دارد که مستقیماً در جدول ذخیره می شوند و داده های tos نیز وجود دارد. اینها حجم زیادی از داده ها هستند: متن، json. آنها در قرص های جداگانه ذخیره می شوند. و طبق این الواح همین داستان با نفخ اتفاق می افتد، یعنی همه چیز همان است. آنها فقط به طور جداگانه فهرست شده اند.

با تشکر از گزارش! استفاده از درخواست‌های مهلت بیانیه برای محدود کردن مدت زمان چقدر قابل قبول است؟

بسیار قابل قبول ما از آن در همه جا استفاده می کنیم. و از آنجایی که ما خدمات خود را نداریم، پشتیبانی از راه دور ارائه می دهیم، مشتریان بسیار متنوعی وجود دارد. و همه از این موضوع کاملا راضی هستند. یعنی ما در کرون چک مشاغل داریم. فقط مدت جلسات با مشتری مذاکره می شود که قبل از آن میخ نمی زنیم. ممکن است یک دقیقه باشد، ممکن است 10 دقیقه باشد. این بستگی به بار روی پایه و هدف آن دارد. اما همه ما از pg_stat_activity استفاده می کنیم.

با تشکر از گزارش! من سعی می کنم گزارش شما را برای برنامه هایم امتحان کنم. و به نظر می رسد که ما یک تراکنش را در همه جا شروع می کنیم و به صراحت آن را در همه جا تکمیل می کنیم. اگر استثنا وجود داشته باشد، همان بازگشت مجدد اتفاق می افتد. و بعد فکر کردم پس از همه، معامله نمی تواند به طور صریح شروع شود. این یک اشاره به دختر است، حدس می زنم. اگر فقط یک به‌روزرسانی رکورد انجام دهم، آیا تراکنش در PostgreSQL شروع می‌شود و تنها زمانی که اتصال قطع شود پایان می‌یابد؟

اگر اکنون در مورد سطح برنامه صحبت می کنید، به درایوری که استفاده می کنید و ORM مورد استفاده بستگی دارد. تنظیمات زیادی در آنجا وجود دارد. اگر commit خودکار را فعال کرده باشید، تراکنش از آنجا شروع می شود و بلافاصله بسته می شود.

یعنی بلافاصله بعد از آپدیت بسته میشه؟

بستگی به تنظیمات داره من یکی از تنظیمات را نام بردم. این commit خودکار است. او بسیار رایج است. اگر فعال باشد، تراکنش باز و بسته شده است. مگر اینکه به صراحت گفته باشید «شروع معامله» و «پایان تراکنش»، اما به سادگی درخواستی را وارد جلسه کرده باشید.

سلام! با تشکر از گزارش! تصور کنید که ما یک پایگاه داده داریم که متورم و متورم می شود و سپس فضای سرور تمام می شود. آیا ابزاری برای رفع این وضعیت وجود دارد؟

مکان روی سرور به خوبی نیاز به نظارت دارد.

به عنوان مثال، DBA برای نوشیدن چای رفت، در یک استراحتگاه بود و غیره.

هنگامی که یک سیستم فایل ایجاد می شود، حداقل فضای ذخیره ای ایجاد می شود که در آن داده ها نوشته نمی شوند.

اگر کاملا صفر باشد چه؟

در آنجا به آن فضای رزرو شده می گویند، یعنی می توان آن را آزاد کرد و بسته به اینکه چقدر بزرگ ساخته شده است، فضای آزاد دریافت می کنید. به طور پیش فرض، من نمی دانم چند نفر هستند. و در مورد دیگر دیسک ها را تحویل دهید تا جایی برای انجام عملیات بازیابی داشته باشید. می توانید جدولی را که تضمین شده است به آن نیاز ندارید حذف کنید.

آیا ابزار دیگری وجود ندارد؟

همیشه دست سازه و در آن مکان مشخص می شود که چه کاری بهتر است در آنجا انجام شود، زیرا داده هایی وجود دارد که حیاتی هستند، غیر بحرانی هستند. و برای هر پایگاه داده و برنامه ای که با آن کار می کند، بستگی به کسب و کار دارد. همیشه در محل تصمیم گیری می شود.

با تشکر از گزارش! دو تا سوال دارم ابتدا اسلایدهایی را نشان دادید که در آن نشان داده شد که در مورد تراکنش های آویزان، هم میزان فضای جدول و هم اندازه شاخص رشد می کند. و در ادامه گزارش، یکسری ابزارهای کمکی وجود داشتند که تبلت را بسته بندی می کردند. و در مورد شاخص چطور؟

آنها را هم بسته بندی می کنند.

اما خلاء روی شاخص تاثیر نمی گذارد؟

برخی با شاخص کار می کنند. به عنوان مثال pg_rapack، pgcompacttable. خلاء شاخص ها را دوباره ایجاد می کند، بر آنها تأثیر می گذارد. VACUUM FULL ماهیت بازنویسی همه چیز را دارد، یعنی با همه کار می کند.

و سوال دوم. من متوجه نشدم که چرا گزارش های مربوط به ماکت ها تا این حد به خود تکرار بستگی دارد. به نظرم می رسید که گزارش ها خواندن است و تکرار نوشتن.

چه چیزی باعث تضاد تکرار می شود؟ ما یک استاد داریم که فرآیندها روی آن انجام می شود. ما اتو وکیوم داریم. اتو وکیوم در واقع چه کاری انجام می دهد؟ او چند خط قدیمی را قطع می کند. اگر در این زمان ما درخواستی روی ماکتی داشته باشیم که این خطوط قدیمی را می‌خواند، و روی Master وضعیتی وجود داشت که autovacuum این خطوط را برای بازنویسی علامت‌گذاری کرده بود، آن‌ها را بازنویسی کردیم. و ما یک بسته داده دریافت کردیم، زمانی که باید خطوطی را که درخواست نیاز دارد روی replica بازنویسی کنیم، سپس فرآیند تکرار منتظر مهلت زمانی می ماند که پیکربندی کرده اید. و سپس PostgreSQL تصمیم خواهد گرفت که چه چیزی برای آن مهم تر است. و Replication برایش مهمتر از درخواست است و درخواست انجام این تغییرات را روی ماکت شلیک می کند.

اندرو، من یک سوال دارم. این گرافیک‌های فوق‌العاده‌ای که در حین ارائه نشان دادید، آیا این نتیجه کار مفید شماست؟ نمودارها چگونه ساخته شدند؟

این یک سرویس است اوک متر.

آیا این محصول تجاری است؟

آره. این یک محصول تجاری است.

منبع: www.habr.com