shadPS4 is an early PlayStation 4 emulator for Windows, Linux and macOS written in C++.

https://github.com/shadps4-emu/shadPS4

این‌ها رو می‌بینم و با خودم می‌گم که هرگز اینقدر خفن نخواهم شد در زندگیم.

یکی از راه‌هایی که میشه جلوی حمله‌ی DNS Cache Poisoning رو گرفت، دادن درخواست با ترکیب بزرگ و کوچک حروف هست. مثلا به جای درخواست google.com بدیم GoOGle.cOm.

توی این لینک توضیح داده شده که این عمل چجوری جلوی این حمله رو می‌گیره:
https://hypothetical.me/short/dns-0x20/

چجوری کلادفلر آنالیز ۱ میلیون درخواست بر ثانیه رو هندل می‌کنه؟

https://blog.cloudflare.com/how-cloudflare-analyzes-1m-dns-queries-per-second/

Barry Schwartz - Why We Work

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

اگر خواستید بدونید که AS یک آدرس IP چه کسی یا سازمانی هست:
https://bgp.tools/

امروز یه مسئله بامزه raise شد.

شما فرض کنید که یک کمپانی هست که حدود ۲ ۳ ترا دیتا داره روی mysql. زجری که این کمپانی می‌کشه اینه که با هر آپدیت گنده‌ای که میخواد روی دیتابیسش بره، چیزی حدود ۱ ساعت down عه. چون حجم دیتا زیاده و مثلا یه تغییر جنس یه فیلد روی چندتا تیبل یه downtime یک ساعتی داره براشون. چرا؟ چون برای اپدیت تیبل‌ها، اون تیبل‌ها لاک می‌شن و کوئری‌های write بسته می‌شن. حتی بعضا توی mysql، کوئری‌های read هم بسته می‌شن. دغدغه اینجاس که چجوری این کمپانی می‌تونه بدون هیچ downtimeای، دیتابیسشو آپدیت کنه.

این ما رو به این داشت که شرکت‌های بزرگ چکار می‌کنن؟ مثلا گوگل که نمیاد بگه عزیزان لطفا امروز سرچ نکنید ما downاین تا ما این تیبل‌هامونو اپدیت کنیم که. حالا در ادامه (نه دقیقا همین الان) یه سری چیز میز که چجوری شرکتای گنده بدون downtime می‌تونم دیتابیس‌ و تیبل‌ها و داده‌های گنده رو آپدیت کنن رو می‌گم. خیلی بامزه‌ن.

فیبر نوری خونه رو راه انداختم. صرفا جهت شوعاف.

این یه نمونه واسه دیتابیس‌های schemeless عه.

https://www.cockroachlabs.com/blog/how-to-update-database-schema/

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

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

بحث اینه که واقعا ماهیت دیتابیس‌ها فرق می‌کنه. مثلا زمانی که رپلیکا از مستر برای سینک خارج شه، حالا فرضا تایپ اون ستونی که می‌خواستیم از int شد string. حین این تغییر مثلا داده‌های 1 و 2 و 3 هم نوشته شد روی مستر و از اونجایی که رپلیکا دیگه سینک نیست، پس این داده‌ها روی رپلیکا وجود نداره دیگه. بعد که مجددا بخواد رپلیکا برگرده به مدار، دیتابیس postgre این قابلیت رو داده که بتونه داده‌های 1 و 2 و 3 رو بنویسه توی رپلیکا ولی با تایپ جدید. و حالا می‌تونیم سرویس رو وصل کنیم به رپلیکا و مستر رو شروع کنیم ادیت کردن.

اینم بلاگ قشنگیه که خوندنش پیشنهاد میشه:
https://cloud.google.com/blog/products/databases/how-cloud-sql-maintenance-works-to-keep-instances-updated

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

بحث دیگه، دیتابس‌های ارشیو نگه‌دارنده هستند. بحث اینه که عموما شرکتا نباید دیتاهای خیلی زیادی داشته باشن به صورت لایو که بخوان روشون کوئری بزنن. یعنی اگر دارن نگه‌میدارن اشتباهه.

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

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

مثلا چیزایی مثل mongoDB خیلی مناسب برای آرشیو کردن دیتا و این صحبتا.

امروز این MR رو توی ریپوی pwntools دیدم خیلی باحال بود. می‌تونه از بایت‌هایی که توی مموری ذخیره شده بیاد elf مربوطه شو بسازه و ذخیره کنه.

https://github.com/Gallopsled/pwntools/pull/2574/commits/97ea9af0465c0e8c564fecdda7d4885bb7c88e56

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

راستش راهی نیست. یعنی حداقل به ذهن من نیومد و سرچم کردم چیزی پیدا نکردم. تنها راهش اینه چیزی روی مستر نیاد دیگه. یعنی به عبارتی کلا read-only شه نود مستر هم. ولی خب این خودش خیلی بستگی به این داره که رفتار application چطوریه؟ یعنی به عبارتی read-only شدن یک دیتابیس خیلی خیلی دیپند به این هست که آیا اصلا اون سرویس این رید‌آنلی رو هندل میکنه یا نه.

یعنی ممکنه دیتابیس read-only شه و هیچی به جز صفحه‌ی لندینگ نشه دید دیگه اصلا. چرا؟ چون مثلا سشن‌ها هم داره توی دیتابیس ذخیره میشه و طرف لاگ‌این هم نمی‌تونه بکنه حتی.

خلاصه اینکه شرکت‌های بزرگ که چه عرض کنم، یکم بزرگ و شرکتای خوب کلا، پروداکتی که میدن از ریدآنلی شدن هم تبعیت می‌کنه. یعنی اصلا سرویس‌شون جوری طراحی شده که می‌تونه بره روی readl-only mode که ux خوبی هم واسه کاربر داشته باشه و خیلی اذیت نشه و کاربر بفهمه صرفا یه سری کارا رو نمی‌تونه انجام بده صرفا.