البته اینایی که میگم خیلی کلیه و دقیقا این نیست. مثلا یکی از هزاران راه اینه. خیلی بسته به محیط و سرویس و دیتابیسی که استفاده میشه و این موارده. مثلا یک راهم همونطور که بچهها زیر پست هم نوشتن، اینه که ما یه نود رپلیکا بیاریم روی کار که با مستر سینک میشه و بعدش سینک رو قطع کنیم روی نود رپلیکا و تغییرات رو انجام بدیم. اصلا حتی اگر تغییرات n ساعت هم طول بکشه، سرویس ما همچنان به نود مستر دیتابیس وصله و کار میکنه. اینجا یه بدی خب مثلا هست اینه که داریم دو برابر منابع مصرف میکنیم دیگه. ولی مهمترین نکته اینه که زمانی که سینک رپلیکا با مستر قطع شد که بره روش تغییرات ایجاد شه، در این زمان دادههایی که روی مستر نوشته میشه چی میشن؟
بحث اینه که واقعا ماهیت دیتابیسها فرق میکنه. مثلا زمانی که رپلیکا از مستر برای سینک خارج شه، حالا فرضا تایپ اون ستونی که میخواستیم از int شد string. حین این تغییر مثلا دادههای 1 و 2 و 3 هم نوشته شد روی مستر و از اونجایی که رپلیکا دیگه سینک نیست، پس این دادهها روی رپلیکا وجود نداره دیگه. بعد که مجددا بخواد رپلیکا برگرده به مدار، دیتابیس postgre این قابلیت رو داده که بتونه دادههای 1 و 2 و 3 رو بنویسه توی رپلیکا ولی با تایپ جدید. و حالا میتونیم سرویس رو وصل کنیم به رپلیکا و مستر رو شروع کنیم ادیت کردن.
بحث اینه که واقعا ماهیت دیتابیسها فرق میکنه. مثلا زمانی که رپلیکا از مستر برای سینک خارج شه، حالا فرضا تایپ اون ستونی که میخواستیم از 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
https://cloud.google.com/blog/products/databases/how-cloud-sql-maintenance-works-to-keep-instances-updated
Google Cloud Blog
How Cloud SQL maintenance works to keep instances updated | Google Cloud Blog
A technical breakdown of the Cloud SQL maintenance workflow helps illuminate instance updates and downtime periods
👍1
Dutchman Daily
پیرو این مسئله، امروز چون یکم وقت داشتم گفتم بنویسم. حقیقتش اینه که شرکتای بزرگ عموما آپدیتهای اینشکلی روی تیبلها نمیرن. به عبارتی شرکتایی مثل گوگل، متا، آمازون و کلا حالا زیر سرویسهای اینّا که دیتابیسهای خیلی عظیم الحجمی دارن، کلا آپدیت مثلا فیلد رو…
ولی این مورد که شرکتای بزرگ عموما مایگریشن نمیزنن وجود داره. یعنی مثلا توی طول عمر سنتری فکر کنم یبار یه مایگریشن بزرگ وجود داشته که توی آپدیت ورژن سنتری مثلا دیتابیس هم باید آپدیت میشده. و اونم مثلا بخاطر این بوده که سنتری اومده از بیخ اصلا معماریش رو کامل عوض کرده.
بحث دیگه، دیتابسهای ارشیو نگهدارنده هستند. بحث اینه که عموما شرکتا نباید دیتاهای خیلی زیادی داشته باشن به صورت لایو که بخوان روشون کوئری بزنن. یعنی اگر دارن نگهمیدارن اشتباهه.
مثلا اسنپ شاید چند صد ترا بایت دیتا داشته باشه توی دیتابیسش (حتی شاید بیشتر چون من واقعا نمیدونم و صرفا حدسه)، ولی این دیتا، دیتای به روز و لایوی نیست. یعنی مثلا اسنپ دیتای ۶ سال پیش رو که نیاز نداره که. نهایتا دیتای یک هفته اخیر رو میخواد اونم صرفا واسه ساپورتش که پیگیری میکنه یا کاری میکنه.
اینجاس که میان از دیتابیسهای آرشیو استفاده میکنن و دیتاهاشون رو آرشیو میکنن. این عملا باعث میشه دیتاهای چند صد ترا تبدیل میشن به چند صد گیگ که آپدیتهای گوناگون روی این حجم از دیتا حتی اگر بخواد موجب downtime شه هم خیلی نیست و خیلی راحتتره.
مثلا چیزایی مثل mongoDB خیلی مناسب برای آرشیو کردن دیتا و این صحبتا.
مثلا اسنپ شاید چند صد ترا بایت دیتا داشته باشه توی دیتابیسش (حتی شاید بیشتر چون من واقعا نمیدونم و صرفا حدسه)، ولی این دیتا، دیتای به روز و لایوی نیست. یعنی مثلا اسنپ دیتای ۶ سال پیش رو که نیاز نداره که. نهایتا دیتای یک هفته اخیر رو میخواد اونم صرفا واسه ساپورتش که پیگیری میکنه یا کاری میکنه.
اینجاس که میان از دیتابیسهای آرشیو استفاده میکنن و دیتاهاشون رو آرشیو میکنن. این عملا باعث میشه دیتاهای چند صد ترا تبدیل میشن به چند صد گیگ که آپدیتهای گوناگون روی این حجم از دیتا حتی اگر بخواد موجب downtime شه هم خیلی نیست و خیلی راحتتره.
مثلا چیزایی مثل mongoDB خیلی مناسب برای آرشیو کردن دیتا و این صحبتا.
👍1
امروز این MR رو توی ریپوی pwntools دیدم خیلی باحال بود. میتونه از بایتهایی که توی مموری ذخیره شده بیاد elf مربوطه شو بسازه و ذخیره کنه.
https://github.com/Gallopsled/pwntools/pull/2574/commits/97ea9af0465c0e8c564fecdda7d4885bb7c88e56
https://github.com/Gallopsled/pwntools/pull/2574/commits/97ea9af0465c0e8c564fecdda7d4885bb7c88e56
GitHub
Allow creating an ELF from in-memory bytes by clubby789 · Pull Request #2574 · Gallopsled/pwntools
This updates the ELF constructor to also accept the raw bytes of an ELF
Closes #2155.
Closes #2155.
🤮3👍1
Dutchman Daily
بحث دیگه، دیتابسهای ارشیو نگهدارنده هستند. بحث اینه که عموما شرکتا نباید دیتاهای خیلی زیادی داشته باشن به صورت لایو که بخوان روشون کوئری بزنن. یعنی اگر دارن نگهمیدارن اشتباهه. مثلا اسنپ شاید چند صد ترا بایت دیتا داشته باشه توی دیتابیسش (حتی شاید بیشتر…
برگردیم به توضیحات این. همونطور که گفتم، چیزایی مثل postgre اینا میتونن هندل بکنن این دادههایی که جدیده و روی مستر نوشته فقط و اونا رو میتونن سینک کنن با رپلیکا. منتهی باقی دیتابیسهایی که نمیتونن اگر بخوان از این مسیر برن پس چی؟
راستش راهی نیست. یعنی حداقل به ذهن من نیومد و سرچم کردم چیزی پیدا نکردم. تنها راهش اینه چیزی روی مستر نیاد دیگه. یعنی به عبارتی کلا read-only شه نود مستر هم. ولی خب این خودش خیلی بستگی به این داره که رفتار application چطوریه؟ یعنی به عبارتی read-only شدن یک دیتابیس خیلی خیلی دیپند به این هست که آیا اصلا اون سرویس این ریدآنلی رو هندل میکنه یا نه.
یعنی ممکنه دیتابیس read-only شه و هیچی به جز صفحهی لندینگ نشه دید دیگه اصلا. چرا؟ چون مثلا سشنها هم داره توی دیتابیس ذخیره میشه و طرف لاگاین هم نمیتونه بکنه حتی.
خلاصه اینکه شرکتهای بزرگ که چه عرض کنم، یکم بزرگ و شرکتای خوب کلا، پروداکتی که میدن از ریدآنلی شدن هم تبعیت میکنه. یعنی اصلا سرویسشون جوری طراحی شده که میتونه بره روی readl-only mode که ux خوبی هم واسه کاربر داشته باشه و خیلی اذیت نشه و کاربر بفهمه صرفا یه سری کارا رو نمیتونه انجام بده صرفا.
راستش راهی نیست. یعنی حداقل به ذهن من نیومد و سرچم کردم چیزی پیدا نکردم. تنها راهش اینه چیزی روی مستر نیاد دیگه. یعنی به عبارتی کلا read-only شه نود مستر هم. ولی خب این خودش خیلی بستگی به این داره که رفتار application چطوریه؟ یعنی به عبارتی read-only شدن یک دیتابیس خیلی خیلی دیپند به این هست که آیا اصلا اون سرویس این ریدآنلی رو هندل میکنه یا نه.
یعنی ممکنه دیتابیس read-only شه و هیچی به جز صفحهی لندینگ نشه دید دیگه اصلا. چرا؟ چون مثلا سشنها هم داره توی دیتابیس ذخیره میشه و طرف لاگاین هم نمیتونه بکنه حتی.
خلاصه اینکه شرکتهای بزرگ که چه عرض کنم، یکم بزرگ و شرکتای خوب کلا، پروداکتی که میدن از ریدآنلی شدن هم تبعیت میکنه. یعنی اصلا سرویسشون جوری طراحی شده که میتونه بره روی readl-only mode که ux خوبی هم واسه کاربر داشته باشه و خیلی اذیت نشه و کاربر بفهمه صرفا یه سری کارا رو نمیتونه انجام بده صرفا.
🔥5❤1💊1
خیلی از لحاظ روحی خسته، پاره، کوفته و دارای میل شدید به خودکشیام. ولی خب خالم شام قیمه گذاشته.
🤣22🔥6😍2❤1👎1
🔥3💩3
اینو باز کنید اگر اندروید باشید تلگرامتون کرش میکنه. روی ویندوز و آیفون نمیکنه علیالحساب.
دلیلش اینه که کلاینت اندروید فاز شده و با یه ورودیای باعث شده کرش کنه. اون ورودی روی کدک صدای این ویدئوعه و اگر پلیش کنید میره به اون فانکشن و کرش میکنه تلگرامتون.
دلیلش اینه که کلاینت اندروید فاز شده و با یه ورودیای باعث شده کرش کنه. اون ورودی روی کدک صدای این ویدئوعه و اگر پلیش کنید میره به اون فانکشن و کرش میکنه تلگرامتون.
🔥28👎1
Forwarded from Byte | بایت
00000010.pdf
35 MB
«شماره ۲ نشریۀ علمی بایت»
• #آرش_شاهحسینی
• #سیدپارسا_نشایی
• #عماد_امامجمعه
• #آروین_طاهری #متین_غیاثی
• #تحریریه
• #معین_آعلی
• #تحریریه
• #امیرحسین_انصاری
• #امیرحسین_رازلیقی #مهدی_بهرامیان #محمد_مصیبی #محمدمهدی_سمیعی
• #سعید_فراتیکاشانی
• #بردیا_رضاییکلانتری
• #تحریریه
• #امیرحسین_شهیدی
• #مهدی_علینژاد
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍1
This media is not supported in your browser
VIEW IN TELEGRAM
😁40❤17🦄6😢3👍1