تناقض داده ها در AWS Amazon Aurora Postgres با Local Write Forwarding حل شد؟

Summarize this content to 400 words in Persian Lang
من از طرفداران پر و پا قرص Postgres هستم. من همچنین از طرفداران پر و پا قرص AWS Aurora Postgres هستم. هنگامی که به عنوان مشاور بهینه سازی پایگاه های داده برای مشتریان کار می کردم، از نزدیک شاهد مقیاس پذیری شگفت انگیزی بودم که با این دو فناوری امکان پذیر است. اما همه چیز خورشید و گل سرخ نیست.

یوتیوب ویدیوهای بسیار خوبی در مورد معماری پشت AWS Aurora دارد. در سطح بسیار بالایی، AWS Postgres بالادست را می گیرد، موتور ذخیره سازی را جایگزین می کند و برخی تغییرات دیگر را در موتور برنامه ریزی انجام می دهد. با این حال، موتور ذخیره‌سازی بزرگ‌ترین تغییر است که داده‌ها را در خوشه‌های ذخیره‌سازی اختصاصی جدا شده از محاسبات زیربنایی بارگذاری می‌کند. این مزایا بسیار زیادی را به همراه دارد، اما یک مشکل بزرگ را نیز ایجاد می‌کند، یا تا همین اواخر چنین بود.

خوشه های شفق از یک نمونه نویسنده واحد و نمونه های صفر یا بیشتر خواننده تشکیل شده اند. من بدون سرور Aurora را نادیده می‌گیرم، زیرا این یک جانور دیگر است و موضوعی برای یک روز دیگر است. در ساده‌ترین راه‌اندازی، خوشه یک نقطه پایانی نویسنده و یک نقطه پایانی خواننده واحد را فراهم می‌کند. کلاینت‌ها درخواست‌های فقط خواندنی را به نقطه پایانی خواننده ارسال می‌کنند، که از DNS دور روبین برای هدایت (احمقانه) ترافیک به نمونه‌های خواننده استفاده می‌کند. مشتریان ارسال می کنند INSERT، UPDATE و DELETE ترافیک، بدون تعجب، به نقطه پایانی نویسنده، که همیشه ترافیک را از طریق DNS به نمونه نویسنده فعلی هدایت می کند.

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

بنابراین، اگر تغییری را از طریق رایتر انجام دهیم و سپس یک پرس و جو را در یک خواننده انجام دهیم، پس از انجام موفقیت آمیز تغییر در رایتر، داده‌های جدید خود را برمی‌گردانیم، درست است؟ بستگی دارد.

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

Aurora از لینوکس روی EC2 برای محاسبات زیربنایی استفاده می کند. هسته لینوکس از یک صفحه کش برای نگهداری داده ها از بلوک های اخیراً در حافظه فرار (RAM) استفاده می کند. و این همان چیزی است که می تواند منجر به نتایج ناسازگار پرس و جو شود. این سناریو را در نظر بگیرید:

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

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

من از خوشه Aurora Postgres با استفاده از موتور نسخه 16.4 استفاده خواهم کرد، یک نمونه نویسنده و یک نمونه خواننده واحد، که هر دو در حال اجرا هستند. db.t4g.medium نمونه ها به عنوان یک مشتری آزمایشی از a استفاده خواهم کرد t3a.micro نمونه EC2 نویسنده، خواننده و مشتری تست همگی در AZ های مختلف، در یکسان هستند eu-west-1 منطقه

برای آزمایش از یک اسکریپت ساده پایتون استفاده خواهم کرد. اسکریپت اقدامات زیر را انجام خواهد داد:

بسته به سناریوی آزمایشی، اتصالات پایگاه داده را به نویسنده، خواننده یا هر دو باز کنید.
یک ردیف در جدول را با شمارنده ای که از 0 شروع می شود و به صورت متوالی تا حداکثر تعداد تکرار افزایش می یابد، به روز کنید.
مدت زمان فزاینده‌ای صبر کنید، بدون انتظار شروع کنید و تا 100 میلی‌ثانیه ادامه دهید.
همان ردیف را به عقب بخوانید و بررسی کنید که آیا شمارنده مقدار جدید (سازگار) را دارد یا همچنان مقدار قبلی را دارد (ناسازگار).
مراحل 2-4 را تا رسیدن به حداکثر 10000 تکرار تکرار کنید.

زمان صرف شده بین مراحل 2 و 4 همچنین شامل زمان لازم برای اجرای اسکریپت است که باید در نظر گرفته شود. پس بیایید بررسی کنیم که چقدر طول خواهد کشید. بیایید بدون هیچ تاخیری در مرحله 3 اجرا کنیم، با هر دو نوشتن و خواندن به نمونه نویسنده. این بهترین حالت مطلق ما از نظر تأخیر کد خواهد بود، و در این سناریو، کد (M=0.12795ms، SD=0.000155) از انجام موفقیت آمیز تراکنش در مرحله 2 تا صدور خواندن اندازه گیری می شود. درخواست در مرحله 4 با 100000 تکرار. بسیار سریع، و بیش از اندازه کافی برای آزمایش ما سریع است.

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

بیایید آنچه را که می‌توانیم در اینجا ببینیم، مرور کنیم، زیرا بسیار مهم است.

در سناریوی ما، وقتی از طریق نمونه نویسنده به‌روزرسانی می‌کنیم و سپس داده‌ها را از یک نمونه خواننده بازخوانی می‌کنیم، با فاصله کمتر از 25 میلی‌ثانیه بین پرس‌و‌جوها، داده های اشتباه را پس خواهید گرفت. هنگام به‌روزرسانی و سپس بازخوانی فوری، نرخ شکست (خط قرمز) 99.36 درصد را مشاهده می‌کنیم که با اضافه شدن تاخیر مصنوعی 12.5 میلی‌ثانیه به 59.96 درصد کاهش می‌یابد. این اساساً با کاری که یک پایگاه داده سازگار با ACID باید انجام دهد در تضاد است. (اگرچه مشاهده در نمودار غیرممکن است، اما با اضافه شدن 50 میلی ثانیه تاخیر، نرخ شکست 0.02٪ را دریافت می کنیم).

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

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

به جز، این است یک ایده واقعا بد.

در Aurora Postgres، شما هستید به طور معمول محدود به یک نمونه نویسنده و حداکثر 15 نمونه خواننده. من به طور معمول می گویم، همانطور که اخیرا Aurora Postgres Limitless به GA رفت، که مقیاس خودکار افقی نمونه های نویسنده را ارائه می دهد، اما این موضوع برای روز دیگری است زیرا دارای جزئیات طراحی قابل توجهی است که باید در نظر گرفته شود. با کنار گذاشتن محصول Limitless، این بدان معناست که شما همیشه به یک نمونه نویسنده در هر خوشه Aurora Postgres محدود خواهید بود. بنابراین نمونه نویسنده باید فقط برای پرس و جوهایی که به روز رسانی را انجام می دهند، با تمام پرس و جوهای دیگر که توسط نمونه های مقیاس خودکار خواننده انجام می شود، استفاده شود. اما چه گزینه دیگری داریم؟ اگر به‌روزرسانی‌ها را انجام می‌دهیم و سپس باید آن داده‌ها را با یکپارچگی بازخوانی کنیم، بر اساس این یافته‌ها باید از نمونه نویسنده استفاده کنیم یا یک تاخیر مصنوعی اضافه کنیم، اینطور نیست؟

این امر تا زمان عرضه عمومی ارسال نوشتاری محلی Aurora Postgres در دسترس بود، که این مشکل خاص را با برخی اخطارها حل می‌کند.

ارسال محلی نوشتن یکی از ویژگی‌های Aurora Postgres (و Aurora MySQL) است که به شما امکان می‌دهد یک سطح سازگاری برای نوشته‌ها ارسال کنید، که سپس به خواننده نمونه ها نمونه خواننده دریافت کننده ترافیک، پرس و جو را به عنوان یک به روز شناسایی می کند و آن را به نمونه نویسنده ارسال می کند. بسته به سطح سازگاری درخواستی، سپس به صورت اختیاری منتظر می ماند تا تغییر با سطح مشخص شده سازگار شود، قبل از اینکه تراکنش به عنوان موفقیت آمیز برای مشتری تأیید شود.

ارسال محلی نوشتن در سطح خوشه فعال است و پس از فعال شدن کلاینت ها می توانند سطح سازگاری مورد نیاز خود را هنگام استفاده از این ویژگی مشخص کنند:

OFF: غیرفعال است، به‌روزرسانی‌های ارسال شده به یک نمونه خواننده فوراً با شکست مواجه می‌شوند.SESSION: پیش‌فرض در خوشه‌ای که ارسال محلی نوشتن فعال است. این بدان معنی است که هر تغییری که در یک جلسه ایجاد شود همیشه در آن جلسه ثابت خواهد بود، اما ممکن است در جلسات دیگر سازگار نباشد.EVENTUAL: این امکان را برای ارسال به‌روزرسانی‌ها به نمونه‌های خواننده برای ارسال به نمونه نویسنده فراهم می‌کند، اما کاملاً فراهم می‌کند نه تضمین می کند که داده ها فوراً سازگار خواهند بود.GLOBAL: تنظیم چکش سورتمه. این تضمین می کند که همه به روز رسانی های ارسال شده از طریق جلسه به تکرار می شود همه نمونه های خواننده قبل از بازگشت تراکنش.

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

همانطور که انتظار می رفت، همچنان شاهد شکست هایی با نرخی مشابه قبل هستیم. حالا بیایید سعی کنیم با SESSION قوام

بدون شکست دیگر! و در نهایت، بیایید با آن تلاش کنیم GLOBAL قوام

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

بیایید کمی دقیق تر به اعداد نگاه کنیم:

سطح سازگاری
تأخیر (ms)
افزایش از غیر فعال

از کار افتاده است
4.461590695
0%

اتفاقی
5.70614152
27.89٪

جلسه
5.927728486
32.86٪

جهانی
6.418921375
43.87٪

افزایش چشمگیر 43.87٪ در تاخیر در مقایسه با عدم استفاده از ارسال محلی نوشتن و این در یک خوشه کاملاً خالی، منزوی و بیکار است، یک چشم انداز کاملا غیر واقعی در دنیای واقعی.

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

آمازون هنگام اضافه کردن ارسال ارسال نوشتاری محلی، وضعیت‌های انتظار جدیدی را به Performance Insights اضافه کرده است. نمودار زیر یک نمونه خواننده را نشان می دهد که به طور فعال ترافیک را به نمونه نویسنده ارسال می کند. این معیارهای جدید واقعاً مفید خواهند بود زیرا بارهای کاری تولید روی خوشه‌هایی با فعال کردن ارسال نوشتاری محلی فعال است و به تشخیص موقعیت‌هایی که ویژگی باعث ایجاد گلوگاه‌های غیرمنتظره می‌شود کمک می‌کند.

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

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