نوشته های شهریار بیات

افسانه درونگرایی و برونگرایی

شهریار بیات — Thu, 02 Jan 2025 22:14:29 +0330

افسانه درونگرایی و برونگراییشما درون‌گرا هستید یا برون‌گرا؟ احتمالاً همه‌ی ما جواب حاضر و آماده‌ای برای این سوال داریم، یا خودمان را در دسته‌ی درون‌گراها می‌گذاریم، یا در دسته‌ی برون‌گراها. اگر کسی دلیل این را بپرسد برای پاسخ احتمالاً به دریافت انرژی اشاره خواهیم کرد: «من درون‌گرا هستم، چون انرژیم رو از دنیای درونم می‌گیرم» یا «من برون‌گرا هستم، چون از بودن با دیگران انرژی می‌گیرم». خیلی هم خوب. اما اگر صد و پنجاه سال پیش این پرسش را از یک شهروند می‌پرسیدیم، احتمالاً جوابی برای آن نداشت یا اساساً خود را درون این طبقات دسته‌بندی نمی‌کرد. به واقع این کلاهی است که در یک قرن گذشته سر خود گذاشته‌ایم.📌تاریخچه‌ی مطرح شدن موضوع درون‌گرایی-برون‌گرایی به اندیشه‌های «کارل گوستاو یونگ»، در دهه‌ی ۱۹۲۰ برمی‌گردد. نگاه او به‌واسطه‌ی پیشینه‌ی روانکاوی‌اش نگاه نسبتاً درست‌تری به ماجرای درون‌گرایی-برون‌گرایی بود. او معتقد بود که غیر از این‌ها، دسته‌ی میانه‌ای هم وجود دارد که بعدها پژوهشگران برای این دسته نام «ambiverts» را انتخاب کردند. یعنی افرادی که در میانه‌ی این دو قرار دارند.📌بعد از یونگ، شاخص‌ترین افرادی که این مفهوم را گسترش دادند هانس آیزنک، ریموند کتل، کاترین بریگز و دخترش ایزابل بریگز مایر بودند که آن را به یکی از محبوب‌ترین مفاهیم روانشناختی قرن گذشته تبدیل کردند. «نظریه‌ی صفات» در راستای همین ایده‌ها، از میانه‌های قرن گذشته اوج گرفت تا جایی که یکی از واضعان اصلی آن -هانس آیزنک- زمانی که زنده بود، بیشترین ارجاع مقاله را در ژورنال‌های معتبر داشت.📌در طول چندین دهه، اینگونه نظریات، افراد را در یک سری طبقات محدود دسته‌بندی کرده بودند و او را وادار می‌کردند که بر اساس این دسته‌بندی شغل انتخاب کند، استعدادهایش را در همان طبقه پیگیری کند و حتا همسرش را هم بر اساس این دسته‌بندی انتخاب کند. آزمون پنج عامل بزرگ شخصیت (معروف به Big Five) بر اساس همین نظریه‌ی صفات ساخته شده است و هنوز یکی از مهمترین آزمون‌ها در پایان‌نامه‌های دانشجویی، پژوهش‌ها، کلینیک‌ها و در سازمان‌هاست. آزمون مایرز-بریگز (ام‌بی‌تی‌آی) یکی از پرکاربردترین آزمون‌هایی است که آدم‌ها را در این دسته‌بندی‌ها قرار می‌دهد و بویژه برای انتخاب مشاغل استفاده می‌شود. یکی از مطرح‌ترین موسسه‌های انحصاری این آزمون در ایران، سالانه صدها نفر را با این شیوه آموزش می‌دهد، دسته‌بندی می‌کند و برایشان تعیین تکلیف می‌کند.درونگرا یا برونگرا📌در صد سال اخیر بخشی از بدنه‌ی روانشناسی همواره با این دسته‌بندی‌ها مخالف بوده ولی ماجرای رشد یک ایده صرفاً با دانش علمی پیش نمی‌رود، بلکه برخی چیزها صرفاً به خاطر بارآوری‌شان پیش می‌روند و درون‌گرایی-برون‌گرایی بازار خوبی برای موسسات مختلف بود. دهه‌های متوالی است که برون‌گرایی به عنوان یک ارزش شناخته می‌شود. هنوز که هنوز است نیازمندی‌های شغلی پر است از آگهی‌هایی که افراد «با روابط عمومی بالا»، «برون‌گرا»، «اجتماعی» و از این دست خصلت‌های نامتقارن را به عنوان ملاک استخدام قرار می‌دهند تا همین اواخر که موجی از گرایش به درون‌گرایی راه افتاد و مُد روز شد. کتاب «سکوت، قدرت درونگراها» نوشته‌ی سوزان کین یکی از پرفروش‌ترین کتاب‌های دو سال اخیر در تمام کشورهای منتشر شده است.📌پژوهش‌های علمی عموماً در این جور موقعیت‌ها نادیده گرفته می‌شوند. برای مثال اخیراً پژوهشی مفهوم جالبی را ارائه داده است. پژوهشگران با استفاده از مفهوم «self-as-story» می‌گویند افراد با قرار دادن خود در یکی از این دسته‌ها، دیگر بخش‌های خود را نادیده می‌گیرند. برای مثال کسی که خود را در دسته‌بندی «درون‌گرا» قرار می‌دهد، ویژگی‌های خود را که مشخصاً برونگرایانه است را نادیده می‌گیرد. آنها می‌گویند افرادی که خودشان را اینگونه «روایت» می‌کنند، کارکردهای روانشناختی‌شان حتا ضعیف‌تر می‌شود.📌واقعیت این است که انسان هم درون‌گراست و هم برون‌گرا. اگر در برقراری ارتباط مصالحه‌آمیز با دیگران مشکل دارید، به معنای این نیست که درون‌گرا هستید، شاید ارتباط برقرار کردن با دیگران با اضطراب‌های ناخودآگاهتان مرتبط است. اگر نمی‌توانید در خودتان غور و تعمق کنید، به معنای این نیست که برون‌گرا هستید، شاید تعمق کردن آنقدر برای‌تان رنج‌آور است که مجبور می‌شوید ارتباط با خودتان را قطع کنید. به جای دسته‌بندی، خودتان را واکاوی کنید. چنین دسته‌بندی‌هایی فقط باورهایی خود-محدودکننده هستند.📌انسان ترکیب پیچیده‌ای از واحدهای ارتباطی است که در روان‌اش بازنمایی شده‌اند. کاهش دادن انسان به چنین دسته‌بندی‌هایی بیش از آنکه موجب شناخت انسان شود، موجب نادیده گرفته شدن کلیت یکپارچه‌ی او می‌شود.نویسنده مهدی میناخانی - مدرسه علوم انسانی

ویژگی skip locked تو دیتابیس mariadb

شهریار بیات — Wed, 02 Oct 2024 19:33:06 +0330

ویژگی skip locked تو دیتابیس mariadb ویژگی SKIP LOCKED یکی از امکانات کاربردی جدید تو دیتابیس MariaDB هست که از روی MySQL کپی گرفته شده. با استفاده از این قابلیت، تو عملیات SELECT یا UPDATE می‌تونیم ردیف‌هایی که قفل شدن رو نادیده بگیریم. این ویژگی به‌خصوص برای برنامه‌هایی که منابع محدودی مثل اجاره اقامتگاه، صندلی‌های پرواز یا بلیط‌های کنسرت رو رزرو می‌کنن خیلی مفیده.سیستم رزرو اقامتگاه رو تصور کنین. وقتی یه کاربر داره اتاقی رو رزرو می‌کنه، ممکنه همزمان چند کاربر دیگه هم درخواست بدن و اون اتاق قفل بشه (یعنی موقتاً رزرو بشه). اگه بخوای بدون این که معطل کاربر اول بشی، سریعاً بری سراغ اتاق‌های دیگه و اونایی که قفل نیستن رو به کاربر پیشنهاد بدی، SKIP LOCKED دقیقاً همین کارو برات انجام میده.حالا توی یه مثال واقعی فرض کنید ما یه جدول به اسم rooms داریم که اطلاعات اقامتگاه توشه. وقتی بخوایم یه اتاق آزاد پیدا کنیم و رزرو کنیم، دستورمون به این شکل میشه:SELECT * FROM rooms WHERE status = 'available' FOR UPDATE SKIP LOCKED;این دستور، فقط اتاق‌هایی که آزاد و بدون قفل هستن رو برمی‌گردونه و اتاق‌های قفل شده رو رد می‌کنه، بدون این که منتظر بمونه قفل باز شه.این ویژگی برای اپلیکیشن‌هایی که باید سریع عمل کنن و منتظر آزاد شدن ردیف‌های قفل نباشن، فوق‌العاده مفیده. مثلاً توی فروش بلیط کنسرت وقتی چند نفر همزمان می‌خوان صندلی انتخاب کنن، باید سریع بتونی بلیط‌های در دسترس رو به بقیه نمایش بدی.وقتی از SKIP LOCKED استفاده می‌کنی، دیتابیس به صورت خودکار رکوردهایی که قفل شدن رو نادیده می‌گیره. با این روش، همزمانی رو مدیریت می‌کنیم و از ایجاد Deadlock (یعنی حالتی که دو تراکنش منتظر همدیگه بمونن و هیچکدوم نتونن پیش برن) جلوگیری می‌کنیم.اما بریم ببینیم Under the hood چه خبره؟دیتابیس‌ها از مکانیزم‌های قفل‌گذاری برای اطمینان از data consistency در شرایط رقابتی استفاده می‌کنن.دو نوع قفل‌گذاری اصلی داریم shared locks & exclusive locks بریم ببینیم هرکدومشون برای چه سناریو هایی مناسب هستن.قفل گذاری اشتراکی برای عملیات SELECT اعمال می‌شه و اجازه می‌ده چندین کاربر همزمان دیتا رو بخونن.قفل اختصاصی تو عملیات‌هایی مثل UPDATE و DELETE استفاده می‌شه و فقط یک کاربر اجازه تغییرات داره.وقتی ردیفی قفل میشه، اگر دسترسی همزمان دیگه‌ای بخواد اون ردیف رو تغییر بده، درخواست اون دسترسی تا وقتی که قفل باز شه معلق می‌مونه. اما با SKIP LOCKED، دیتابیس اون ردیف‌های قفل شده رو رد می‌کنه و رکوردهای بدون قفل رو در اختیار قرار میده، بدون اینکه نیاز باشه منتظر آزاد شدن قفل‌ها بمونی.

قابلیت invisible index برای پیدا کردن بدترین ایندکس

شهریار بیات — Wed, 25 Sep 2024 11:44:25 +0330

ویژگی Ignored Indexes تو MariaDBویژگی Ignored Indexes تو MariaDB یکی از ویژگی‌های جدید و خیلی کاربردیه که این امکان و میده ایندکس‌ها رو موقع عملیات select نادیده بگیره. یعنی ایندکس‌ها همچنان نگهداری و به‌روزرسانی میشن، ولی Optimizer دیگه از اونا تو کوئری‌ها استفاده نمیکنه. این ویژگی شبیه قابلیت Invisible Indexes تو دیتابیس MySQL نسخه ۸ هست. این ویژگی مخصوصا تو تست‌هایی که می‌خواهید ببینید حذف یه ایندکس چه تاثیری روی کارایی و سرعت کوئری‌ها داره به درد میخوره. با این کار میتونید قبل از حذف نهایی یه ایندکس، اونو به حالت ignore دربیارین و اگه با مشکلی مثل کم شدن سرعت کوئری یا کم شدن پرفورمنس روبرو شدید، به راحتی دوباره اونو فعال کنید.یه مثال ساده تو دیتابیس MariaDB ببینیمفرض کنید جدولی به اسم users داریم و یه ایندکس روی ستون email درست کردیم. حالا میخوایم بررسی کنیم که اگه این ایندکس ignore بشه، چه تاثیری روی عملکرد کوئری ها داره. با استفاده از دستور زیر میتونیم این کار رو انجام بدیم:ALTER TABLE users ALTER INDEX email_index IGNORED;تو این حالت، ایندکس همچنان نگه داشته میشه و داده‌های جدید به آن اضافه میشه، ولی optimizer دیتابیس ازش استفاده نمیکنه. اگه بعد از یه مدتی دیدین که نادیده گرفتن ایندکس باعث شده سرعت کوئری کم بشه یا پرفورمنسش اومده پایین ، میتونید به راحتی با این دستور دوباره فعالش کنید:ALTER TABLE users ALTER INDEX email_index NOT IGNORED;عملکرد در MySQL:این قابلیت تو MySQL 8 با اسم Invisible Indexes معرفی شده. مکانیزمش دقیقا شبیه دیتابیس mariadb فقط کلمه کلیدی هاشون متفاوت هست. اینجا میتونیم ایندکس‌ها رو به حالت invisible در بیاریم و optimizer ازش استفاده نمیکنه ولی همچنان ایندکس ها رو نگه میداره. دستورش هم به این شکل استفاده میشه:ALTER TABLE users ALTER INDEX email_index INVISIBLE;برای برگردوندن ایندکس به حالت قابل استفاده:ALTER TABLE users ALTER INDEX email_index VISIBLE;قابلیت invisible index توی دیتابیس PostgreSQL چطوریه؟تو دیتابیس PostgreSQL ویژگی invisible index به صورت پیش‌فرض وجود نداره و به صورت built-in این قابلیت رو ارائه ندادن متاسفانه.بریم ببینیم Under the Hood چه خبره؟وقتی یه ایندکس به حالت Ignored یا Invisible تو MariaDB و MySQL درآورده میشه، دیتابیس همچنان ایندکس رو به‌روزرسانی میکنه و برای عملیات INSERT، UPDATE و DELETE همچنان تغییرات رو اعمال میکنه. اما الگوریتم optimizer موقع اجرای کوئری‌ها، ایندکس و نادیده میگیره. این کار باعث میشه بدون تغییر ساختار اصلی ایندکس‌ها، بتوینم تاثیر اونارو روی عملکرد کوئری‌ها تست کنیم.اینجا یه الگوریتم ساده استفاده کردن که ایندکس‌های قابل استفاده رو از لیست حذف میکنه و برای بهینه‌سازی کوئری فقط از ایندکس‌های visible استفاده میکنه. این انعطاف‌پذیری به ما اجازه میده تا تصمیم دقیق‌تر و بهتری در مورد نگهداری یا حذف ایندکس‌ها بگیریم. بدون اینکه نیاز باشه ایندکس و کامل حذف کنیم و ریسک از دست دادن سرعت و پرفورمنس و بخوایم بپذیریم.در نهایت ویژگی Ignored Indexes تو MariaDB و Invisible Indexes تو MySQL برنامه نویس ها و دیتابیس ادمین ها کمک میکنه که ایندکس‌های بدون استفاده یا کم‌اثر رو به سادگی تست کنن. این کار به بهینه‌سازی دیتابیس کمک میکنه و ما میتونیم قبل از اعمال تغییرات دائمی، اول تاثیر اونارو رو بررسی کنیم بعد تصمیم بگیریم برای حذف ایندکس یا نگه داشتنش.تو مصاحبه ها اگر ازتون در مورد ایندکس گذاری روی فیلدهای دیتابیس پرسیدن میتونین این فیچر و به عنوان راه حل نهایی ارائه بدین.امیدوارم این پست براتون مفید بوده باشه و مرسی که حمایت میکنید و باعث میشین به دست بقیه هم برسه این پست.

اهمیت داستان خوندن

شهریار بیات — Tue, 24 Sep 2024 19:13:54 +0330

تصمیم گیری در شرایط عدم قطعیتشک گرا ها میگن برای تصمیمات پیچیده نمیشه نسخه واحد پیچید، درست هم میگن متغیرهای خیلی زیادی بصورت غیرخطی تعامل میکنن و سرو کله میزنن تا به شکل الگوی پیش بینی پذیر دربیان. پیچیدگی هر موضوعی خاص و منحصربفرده، هر تصمیم بزرگ مثل دونه برف یا اثر انگشت منحصربفرده نمیشه تصمیم هارو براساس الگوهای کلیشه‌ای دسته بندی کرد.تو رمان جنگ و صلح تولستوی یه بخشی هست که شاهزاده آندری “علم جنگ”، که نظامیان روس فکر میکنن توش خیلی سرآمد هستند و به چالش میکشه. اونجا که شاهزاده آندری میپرسه «وقتی اوضاع و شرایط ناشناخته‌ست و اطمینانی به نیروهای فعال نیست، کدام نظریه یا علم جوابگوعه؟»قصد تولستوی اینجا طرح کردن نوعی استفهام انکاری بود.جواب میتونه این باشه که علم امروز به ما ابزارهایی رو داده که بتونیم جزییات و شرایط پیچیده رو بهتر درک کنیم، اما نکته اینجاست که عینک علم محدودیت‌هایی داره و نمیتونه دامنه گسترده تجربیات زیسته انسانها رو شامل بشه ، چه تجربه جنگ باشه چه مشکلات برنامه‌نویسی یا مدیریتیتولستوی میگه«همه چیز بستگی به شرایط بیشماری دارد که اهمیت آنها در لحظه‌ای خاص مشخص می‌شود و هیچ‌کس نمی‌داند آن لحظه کی فرا می‌رسد.»اینجور که تولستوی میگه زندگی هرکسی مجموعه‌ای منحصر بفرد از شانس و شرایط مختلف که همیشه چیزهای جدیدی هم بهش اضافه میشه و نمیشه همه‌ی این پیچیدگی هارو (بقول دوستم علیرضا) فروکاست کرد به فعل و انفعالات شیمیایی، و اگر این کار و بکنیم حتما از یه سری چیزها غافل موندیم.ما برای اینکه روزانه بتونیم تصمیم بگیریم واقعیت های پیچیده رو به کشف های کوچیک فروکاست میکنیم این روش معمولا برای تصمیم های کم اهمیت جواب میده ولی برای تصمیم‌های بزرگ و مهم چی؟تمثیل و حکایت ها و پندهای اخلاقی ، موضوعات و بشدت فروکاست میکنن در حد پیام اخلاقی مثل حکایت های ملانصرالدینولی داستان و رمان تجربه زیسته رو به همراه پیچیدگی های حقیقی به شکل تقریبا کاملی بیان میکنن مخصوصا رمان‌های واقع‌گراتوی جنگ و صلح هم شاهزاده آندری میخواد لحظات پیش بینی ناپذیر شرایط بیشمار پیچیده جنگ و مشخص کنه.وقتی این رمان ها رو میخونیم فقط سر خودمونو گرم نمیکنیم بلکه تجربیات واقعی خودمونو از جهان مرور میکنیم. در واقع کاری که این داستان ها رمان‌ها با ما میکنه اینه که نگاه تیزبینانه به پیچیدگی‌ها و حقایق جهان میده. اونا نسخه‌ برمون نیمیپیچن که چیکار باید کرد یا نکرد اما چیزی که به ما میدن به اندازه نسخه ارزشمنده «تمرین»وقتی قراره تو زندگی انتخاب های سخت انجام بدیم همین نگاه تیزبین و ذهن تمرین داده‌ شده‌ با داستان که به کمکون میاد تا اگاهانه و با چشم باز و با درنظر گرفتن همه جوانب و پیچیدگی ها انتخاب کنیم.

بررسی confluence برای تیم های نرم افزاری

شهریار بیات — Thu, 19 Sep 2024 18:38:32 +0330

بررسی confluence برای تیم های نرم افزاریابزار داکیومنت نویسی Confluence یه ابزار فوق‌العاده برای داکیومنت‌کردن و مدیریت دانش توی تیم‌های فنی و مهندسی نرم‌افزاره. به تیم‌ها کمک می‌کنه که دانش و اطلاعاتشون رو به صورت متمرکز جمع‌آوری و به اشتراک بذارن. confluence به تیم‌های برنامه‌نویسی، DevOps و مدیریت پروژه اجازه می‌ده که تسک‌ها، فیچرها، مستندات پروژه و حتی جلساتشون رو به صورت سازمان‌دهی‌شده توی یه فضای مشترک داشته باشن. یه جورایی میشه گفت، همون Google Doc، ولی مخصوص تیم‌های فنی و بزرگ‌تر.چرا Confluence آره و چرا Google Docs نه؟درسته، Google Docs یه ابزار عالی برای نوشتن و به اشتراک‌گذاریه، ولی وقتی بحث به کار تیمی و پروژه‌های نرم‌افزاری برسه، Confluence خیلی جلوتره. Google Docs معمولاً برای کارهای سبک‌تر و تیم‌های کوچیک‌تر استفاده می‌شه، ولی Confluence امکانات بیشتری داره. مثلا قابلیت ایجاد صفحه‌های درختی داره که بهت کمک می‌کنه کل داکیومنت‌ها و اطلاعات تیم رو به صورت مرتب و سازمان‌یافته ذخیره کنی. هر تغییری هم که داده بشه، همه اعضای تیم می‌تونن به راحتی دنبال کنن و تاریخچه تغییرات رو ببینن.یکی دیگه از رقبای اصلی ، Notion هست که بعضی‌ها دوست دارن ازش استفاده کنن. Notion خیلی خوشگل و کاربرپسنده و برای نوشتن نوت‌ها و داکیومنت‌های سریع عالیه. ولی وقتی کار تیمی و پروژه‌های بزرگ می‌شه، Confluence بیشتر به درد تیم‌های فنی می‌خوره چون از سیستم‌ها و ابزارهای فنی بهتر پشتیبانی می‌کنه.چرا تیم‌های فنی باید از Confluence استفاده کنن؟وقتی تو یه تیم فنی کار می‌کنی، با چالش‌های پیچیده‌ای مواجه می‌شی. حالا فرض کن یه DevOps یا برنامه‌نویس دیگه بعد از تو قراره با سیستم کار کنه. اگه دقیقاً ندونه که تو چیکار کردی، کلی زمان باید بزاره که سردربیار چی به چی بوده. به همین خاطره که مستندسازی، مخصوصا تو تیم‌های فنی و DevOps خیلی مهمه.بهترین روش برای استفاده از Confluence اینه که هر بار یه فیچر یا تسک جدید انجام می‌دی، بیای دقیق توضیح بدی چی شده. مثلا اگه به عنوان یه برنامه‌نویس داری یه ماژول جدید اضافه می‌کنی یا توی سیستم لاجیک خاصی رو تغییر می‌دی، همه چی رو به‌وضوح تو Confluence مستند کنی. از جزئیات ریز مثل نوع دیتابیس یا زبان برنامه‌نویسی استفاده‌شده گرفته تا چالش‌هایی که داشتی و راه‌حل‌هایی که براش پیدا کردی. اینطوری نفرات بعدی به‌راحتی می‌تونن مستندات رو بخونن و متوجه بشن باید چی‌کار کنن.حالا DevOps ها که قضیه‌شون حتی حساس‌تره. اونا معمولاً با کانفیگ‌های پیچیده، سرورها و دیپلوی‌های سنگین سروکار دارن. اگه یکی از کارای DevOps درست مستند نشه و نفر بعدی نتونه باهاش کار کنه، ممکنه کل سرویس به مشکل بخوره. بهترین راه اینه که DevOps‌ ها هم داکیومنت‌های کانفیگ، پروسه دیپلوی، ابزارهای CI/CD و هر کاری که مربوط به نگهداری سیستم میشه رو تو Confluence بنویسن.بهترین روش مستندسازی توی Confluence چیه؟برای اینکه از Confluence بهترین استفاده رو ببری، می‌تونی این مراحل دنبال کنی:اول برای هر پروژه یه صفحه مستقل بساز و زیرشاخه‌های مرتبط رو به صورت درختی بهش اضافه کن. مثلاً می‌تونی یه صفحه برای پروژه X درست کنی و زیرش صفحه‌های مربوط به دیتابیس، بک‌اند، فرانت‌اند، و دیپلوی رو قرار بدی.هر فیچری که انجام می‌دی یا هر تسکی که به تیم محول می‌شه رو دقیق مستند کن. بگو چرا این کار انجام شده، چه چالش‌هایی داشته و چطور حلش کردی.برای DevOps ها، باید همه تنظیمات سرور، کانفیگ‌های داکر، CI/CD و هر چیزی که مربوط به زیرساخت‌هاست رو بنویسی.اگه تصمیم مهمی برای معماری یا توسعه سیستم گرفته شده، حتماً اون رو مستند کن که نفرات بعدی بدونن چرا این تصمیم گرفته شده و چه گزینه‌هایی مد نظر بوده.مستندات باید به‌روز باشه. هر تغییری که توی پروژه یا کانفیگ‌ها ایجاد می‌شه رو بیایید تو Confluence بنویسید. این کار به همه اعضای تیم کمک می‌کنه تا همیشه با آخرین وضعیت آشنا باشن.بریم ببینیم ویژگی‌های کلیدی Confluence چیه؟سیستم جستجوی خیلی راحت و سریعی داره و به سادگی می‌تونید مستندات و اطلاعات مورد نیازتون رو داخلش پیدا کنین.ارتباط مستقیم با ابزار مدیریت تسک‌ها و پروژه‌ها مثل جیرا، به تیم‌های فنی کمک می‌کنه تا مستندات و تسک‌ها رو به هم متصل کنند.می‌تونید به سادگی برای هر داکیومنت دسترسی‌های مختلف تعریف کنید.اعضای تیم می‌تونن به صورت همزمان روی یک داکیومنت کار کنند و تغییرات رو به صورت لحظه‌ای مشاهده کنند.می‌تونید تمام تغییرات هر داکیومنت رو به همراه نویسنده‌ش ببینید و نسخه‌های قبلی رو بازیابی کنید.بهترین روش استفاده از Confluence اینه که هر تیم فنی، مخصوصاً برنامه‌نویسان و دواپس‌ها، به صورت منظم داکیومنت‌های مربوط به فیچرها، باگ‌ها و تغییرات رو ثبت کنند. به عنوان مثال، وقتی روی فیچری کار می‌کنید، مراحل پیچیده پیاده‌سازی و چالش‌هایی که برخوردید رو به دقت مستند کنید. این کار کمک می‌کنه تا افراد جدیدی که به تیم اضافه میشن یا نفرات دیگه در آینده، بدون سردرگمی بتونن با سیستم کار کنند.بریم یه مثال عملی هم ازش بزنیم.فرض کنید تیم دواپس در حال تنظیم CI/CD هست. تمام مراحل تنظیمات، ابزارهایی که استفاده شده و حتی خطاهایی که ممکنه بهشون برخورد بشه، باید مستند بشه تا همکاران بعدی بدونند از کجا شروع کنند و کدوم راه‌حل‌ها بهترین کارایی رو داشته.زیر پوست Confluence چیه و چطور همه‌چی رو مدیریت می‌کنه؟وقتی می‌گیم "کشف خودکار" یعنی دیگه نیازی نیست دونه‌دونه مستندات رو مدیریت کنی یا نگران بشی که چی کجاست. Confluence به‌صورت خودکار تغییرات رو ردگیری می‌کنه و تاریخچه همه صفحات رو ذخیره می‌کنه. اینطوری حتی اگه چیزی رو اشتباه پاک کنی یا تغییری بدی که به درد نمی‌خوره، می‌تونی برگردی به نسخه قبلی.از طرفی Confluence می‌تونه به Jira، Bitbucket و ابزارهای دیگه هم وصل بشه. مثلاً می‌تونی تسک‌های Jira رو به مستندات Confluence لینک بدی که اعضای تیم بدونن هر کاری چه زمانی و چطور انجام شده.نتیجه‌گیریاگه توی تیم فنی کار می‌کنی، چه برنامه‌نویس باشی چه DevOps، استفاده از Confluence می‌تونه به تیم و پروژه‌هاتون کلی کمک کنه. مستندسازی دقیق، به‌روز و منظم باعث می‌شه همه اعضای تیم همیشه به اطلاعات لازم دسترسی داشته باشن و پروژه‌ها سریع‌تر و بهتر پیش بره. Confluence بهترین ابزار برای این کاره چون هم ساده‌ست و هم قدرت بالایی داره و با ابزارهای دیگه هم به‌راحتی یکپارچه میشه.

بررسی عمیق تر کشف خودکار سرویس‌ها در traefik

شهریار بیات — Fri, 06 Sep 2024 12:41:01 +0330

کشف خودکار سرویس‌ها در traefikحالا که با Traefik آشنا شدیم، توی این مقاله می‌خوام در مورد یکی از قابلیت‌های جذاب و پرکاربردش به اسم "کشف خودکار سرویس‌ها" (Automatic Service Discovery) صحبت کنم. این ویژگی باعث می‌شه سرویس‌ها و کانتینرهای جدید به‌صورت خودکار توسط Traefik شناسایی بشن و نیازی به کانفیگ دستی نداشته باشیم.اول بریم ببینیم اصلا کشف خودکار سرویس‌ها چیه؟فرض کن داری تو محیطی مثل Docker یا Kubernetes کار می‌کنی که پر از سرویس‌ها و کانتینرهای مختلفه. این سرویس‌ها ممکنه خیلی داینامیک باشن؛ یعنی هر لحظه بالا بیان یا از بین برن. اگر بخوای هر بار که سرویس جدیدی راه افتاد یا متوقف شد، تنظیمات رو به‌صورت دستی تغییر بدی، عملاً از کار و زندگی می‌افتی! اینجاست که قابلیت کشف خودکار سرویس‌های Traefik به دادمون میرسه. این ویژگی به Traefik این توانایی رو می‌ده که خودش سرویس‌های جدید رو کشف کنه و بر اساس تنظیماتی که براش تعریف کردی، به‌طور خودکار ترافیک رو به اون‌ها هدایت کنه.چطور کار می‌کنه؟تو Traefik دو روش برای کانفیگ کردن وجود داره: داینامیک و استاتیکروش داینامیک همین لیبل هایی که توی داکر تعریف میشه یا anotation های کوبرنتیز رو میگن.روش استاتیک کانفیگ هایی که توی فایل کانفیگ خود traefik مینویسیم یا توی cli وارد میکنیم یا متغیر هایی که تو فایل env میزاریم.تو Traefik هر سرویسی که بخواد شناسایی بشه، باید از طریق label (توی Docker) یا annotation (توی Kubernetes) معرفی بشه. این لیبل ها به Traefik می‌گن که چطور و از کجا باید ترافیک رو به سرویس مربوطه هدایت کنه.اما جالب‌ترین بخش ماجرا اینجاست که این پروسه کاملاً داینامیکه. مثلاً وقتی یه سرویس جدید میاد بالا، Traefik به کمک سیستم کشف خودکار سرویس‌ها، اون رو شناسایی می‌کنه و ترافیک رو به‌طور خودکار به سمتش هدایت می‌کنه، بدون اینکه لازم باشه دست به تنظیمات بزنی. برعکس، وقتی سرویس از کار می‌افته یا متوقف می‌شه، Traefik هم ترافیک رو به اون سرویس هدایت نمی‌کنه.حالا بریم ببینیم این فرایند دقیقا چطور اتفاق می‌افته و under the hood چه خبره؟وقتی Traefik به یه سیستم مدیریت کانتینر مثل Docker یا Kubernetes متصل می‌شه، به APIهای اون‌ها گوش می‌ده. مثلاً تو Docker، Traefik به Docker Daemon متصل می‌شه و وقتی کانتینر جدیدی راه‌اندازی می‌شه یا سرویس جدیدی بالا میاد، این تغییرات رو از طریق Docker Events دریافت می‌کنه. به همین ترتیب، وقتی سرویسی از کار می‌افته یا حذف می‌شه، Traefik از این تغییرات هم مطلع می‌شه و تنظیمات خودش رو آپدیت می‌کنه.این یعنی هر تغییری تو سیستم Docker یا Kubernetes فوراً توسط Traefik دریافت و پردازش می‌شه و این پردازش به‌طور کامل داینامیکه. تو Kubernetes هم Traefik همین روش رو استفاده می‌کنه و از APIهای Kubernetes برای شناسایی و مدیریت سرویس‌ها کمک می‌گیره.چه تنظیماتی لازمه؟برای اینکه سرویس‌ها به‌طور خودکار توسط Traefik کشف بشن، باید براشون label یا annotation مناسب تعریف بشه. مثلاً تو Docker، می‌تونی این برچسب‌ها رو به کانتینرت اضافه کنی:labels: - "traefik.enable=true" - "traefik.http.routers.myservice.rule=Host(`example.com`)" -"traefik.http.services.myservice.loadbalancer.server.port=80"این مثال نشون می‌ده که کانتینر موردنظر ترافیک رو به پورت ۸۰ هدایت می‌کنه و هر درخواست HTTP که به دامین example.com بیاد، به این کانتینر فرستاده می‌شه. همین روند تو Kubernetes هم به همین شکل انجام می‌شه با استفاده از annotationها.مقایسه با Nginx و Caddyخب، حالا که با Traefik و قابلیت کشف خودکار سرویس‌هاش آشنا شدیم، بد نیست یه مقایسه کوچیک هم با ابزارهای دیگه مثل Nginx و Caddy داشته باشیم. تو Nginx، هر وقت سرویس جدیدی میاد بالا یا کانفیگ تغییر می‌کنه، باید فایل‌های کانفیگ به‌صورت دستی ویرایش بشن و Nginx هم باید reload بشه. اما تو Traefik این کارها داینامیک و خودکار انجام می‌شه. Caddy هم تا حدودی شبیه Traefik عمل می‌کنه و قابلیت‌های خوبی برای کشف سرویس‌ها داره، ولی توی یکپارچگی با سیستم‌های پیچیده مثل Kubernetes و Docker به‌اندازه Traefik انعطاف‌پذیر نیست.نتیجه‌گیریابزار Traefik با قابلیت کشف خودکار سرویس‌ها کار رو تو محیط‌های پیچیده و داینامیک مثل Docker و Kubernetes خیلی راحت کرده. این ویژگی نه‌تنها نیاز به تنظیمات دستی رو از بین می‌بره، بلکه باعث می‌شه زیرساختت همیشه آپدیت بشه و ترافیک بدون هیچ وقفه‌ای به سمت سرویس‌های درست هدایت بشه.اگر تو محیط‌هایی کار می‌کنی که سرویس‌ها مدام در حال تغییرن، Traefik یه انتخاب عالیه که کارها رو برات راحت و بی‌دردسر می‌کنه.

آشنایی و بررسی اولیه ترافیک - Traefik

شهریار بیات — Thu, 05 Sep 2024 18:00:37 +0330

ترافیک (Traefik) یه reverse proxy مدرن و داینامیکه که به خاطر سادگی و ویژگی‌های قدرتمندش محبوب شده. تو این پست، یه نگاهی بهش بندازیم و با فیچر هاش یکم آشنا بشیم و ببینیم چه قابلیت هایی رو بهمون میده و ببینیم چطوری میتونیم ازش برای زیرساخت وب استفاده کنیم و همچنین تفاوت هاش و با رقیباش مثل nginx و بقیه بررسی کنیم و ببینیم چه برتری ها چه ضعف هایی در برابر اونا داره.ترافیک ابزاریه که برای معماری‌های میکروسرویس طراحی شده. این ابزار به عنوان یه پروکسی معکوس عمل می‌کنه و بدون نیاز به کانفیگ دستی، سرویس‌های بک‌اند رو به صورت خودکار شناسایی می‌کنه و ترافیک ورودی رو بهشون هدایت می‌کنه. از ویژگی‌های اصلی ترافیک میشه به این موارد اشاره کرد:شناسایی خودکار سرویس‌ها: ترافیک بصورت داینامیک سرویس‌های بک‌اند جدید رو شناسایی می‌کنه و به درد محیط‌های داینامیک مثل اپلیکیشن‌های کانتینری می‌خوره.کانفیگ از طریق لیبل‌ها: از لیبل‌ها برای تعریف قوانین مسیریابی، تنظیمات لود بالانسینگ و بقیه کانفیگ‌هاش استفاده می‌کنه که کار رو توی تعریف اپ‌ها و کانتینرها خیلی راحت‌تر می‌کنه.ادغام با Let’s Encrypt: ترافیک فرآیند دریافت و تمدید گواهینامه‌های SSL/TLS رو با ادغام مستقیم با Let’s Encrypt خیلی راحت‌تر می‌کنه. انقدر راحت که یه ایمیل از شما میگیره خودش گواهینامه ssl میگیره و تمدید میکنه.لود بالانسینگ: ترافیک از روش‌های مختلف لود بالانسینگ مثل Round Robin و Least Connections پشتیبانی می‌کنه تا ترافیک ورودی به‌طور بهینه بین سرورهای بک‌اند توزیع بشه.وب UI و متریک‌ها: ترافیک یه داشبورد وب کاربردی داره که به کمکش می‌تونی همه چیز رو مانیتور کنی و همچنین متریک‌هایی برای ابزارهای مانیتورینگ مثل Prometheus ارائه می‌ده.به طور کلی، Traefik یه ابزار قدرتمنده که با ادغام بومی با پلتفرم‌های مدیریت کانتینر مثل Docker و Kubernetes، کارها رو تو محیط‌های کانتینری راحت‌تر و اتوماتیک‌تر می‌کنه.یه قابلیت خیلی خوبی که Traefik داره اینه که با محیط‌های کلاستر و کانتینر خیلی خوب کار می‌کنه و کارهارو اتوماتیک میکنه و آسون تر میشه همه چیز. برعکس ابزارهای سنتی مثل NGINX، ابزار Traefik خودکار با سرویس‌های کانتینری مثل Docker، Kubernetes، و Rancher سازگاره و خیلی راحت باهاشون ارتباط می‌گیره. این یعنی وقتی سرویس جدیدی اضافه می‌کنی، Traefik اتوماتیک اون رو شناسایی و کانفیگ می‌کنه.مقایسه با nginx و caddyوب سرور NGINX هم می‌تونه به عنوان Load Balancer و Reverse Proxy استفاده بشه. اما نسبت به Traefik، کانفیگ کردنش پیچیدگی بیشتری داره. مثلا اگه بخوای به طور خودکار یه سرویس جدید توی Docker اضافه کنی، لازمه که کانفیگ NGINX رو دستی آپدیت کنی. ولی Traefik این کار رو اتوماتیک انجام میده.وب سرور Caddy شبیه به Traefik، یک وب سرور سبک و ساده‌ست که ویژگی‌هایی مثل SSL اتوماتیک و کانفیگ ساده رو داره. اما بیشتر برای سرویس‌های کوچک و متوسط مناسبه. اما Traefik، مخصوصا توی محیط‌های کانتینری بزرگ، مثل Kubernetes، خیلی بهتر عمل می‌کنه و امکانات بیشتری میده.امیدوارم این پست مفید و کاربردی بوده باشه براتونروزهای آینده تک تک فیچر های ترافیک و بررسی میکنم با مثال

مدیریت IO threads در دیتابیس mariadb

شهریار بیات — Wed, 04 Sep 2024 14:23:32 +0330

مدیریت IO threads در دیتابیس mariadbتوی نسخه ۱۰.۱۱ دیتابیس mariadb، یه تغییر خیلی مهم و جالب اتفاق افتاده که مربوط به یه سری فرآیندهای پس‌زمینه‌ای (background) هست که توی دیتابیس اتفاق می‌افته. این فرآیندها شامل نوشتن و خوندن داده‌ها از دیسک هستن که با استفاده از یه سری IO threads انجام می‌شن.حالا ماجرا از این قراره که توی نسخه‌های قبلی mariadb، این تنظیمات مربوط به IO threads ، یعنی همون‌هایی که به نوشتن و خوندن داده‌ها از دیسک کمک می‌کنن، ثابت بودن و اگه می‌خواستی تنظیماتشون رو تغییر بدی، حتماً باید سرویس دیتابیس رو ری‌استارت می‌کردی. این یعنی اگه وسط کار بودی و نیاز داشتی که مثلاً تعداد IO threads رو برای بهتر شدن عملکرد تغییر بدی، باید یه وقفه توی کار ایجاد می‌کردی که این خودش می‌تونست دردسرساز بشه.اما توی نسخه ۱۰.۱۱، این داستان کلاً تغییر کرده. یعنی دیگه نیازی به ری‌استارت نیست! حالا می‌تونی تنظیمات مربوط به این threads ها رو به‌صورت داینامیک تغییر بدی. مثلاً اگه دیدی که سرور خوب کار نمی‌کنه و می‌خوای تعداد IO threads رو بیشتر کنی، بدون اینکه نیاز به ری‌استارت باشه، می‌تونی این کار رو انجام بدی. این ویژگی جدید به شدت به بهبود عملکرد و انعطاف‌پذیری سیستم کمک می‌کنه.اما بزارین ببینیم دقیقاً چی میشه؟خب، بزار یکم فنی‌تر به قضیه نگاه کنیم. توی mariadb دو تا متغیر مهم داریم به اسم‌های innodb_write_io_threads و innodb_read_io_threads. اینا همون متغیرهایی هستن که تعداد IO threads ها رو تعیین می‌کنن. IO threads ها یه سری فرآیندهایی هستن که توی بک گراند، داده‌ها رو از حافظه روی دیسک می‌نویسن یا برعکس از روی دیسک میخونن و به حافظه انتقال میدن. هر چقدر تعداد این threads ها بیشتر باشه، توانایی سرور برای انجام هم‌زمان این کارها بیشتر میشه. اما از اون طرف، اگه تعدادشون خیلی زیاد باشه، ممکنه باعث افزایش مصرف منابع بشه. پس باید تو بهینه ترین حالت ممکن نگهشون داریم.توی نسخه‌های قبلی، این متغیرها ثابت بودن و اگه می‌خواستی تغییرشون بدی، باید کل سرور رو ری‌استارت می‌کردی. این یعنی هر بار تغییر، یه وقفه توی کارهای سرور ایجاد می‌کرد. اما حالا توی نسخه ۱۰.۱۱، این متغیرها داینامیک شدن. یعنی بدون ری‌استارت، می‌تونی تغییرشون بدی و فوراً تاثیرش رو توی عملکرد سرور ببینی.مثلاً فرض کن که سرورت داره زیر بار فشار زیادی قرار می‌گیره. تو می‌تونی سریعاً تعداد IO threads ها رو بیشتر کنی تا سرور بتونه سریع‌تر داده‌ها رو بخونه یا بنویسه و بار سرور کاهش پیدا کنه. اینجاست که می‌بینی چقدر این قابلیت جدید مهمه و به بهبود عملکرد کمک می‌کنه.یه نکته دیگه هم اینه که این قابلیت جدید باعث میشه مدیریت سرور و تنظیماتش خیلی راحت‌تر بشه. قبلاً شاید دیتابیس ادمین ها یا مسئولین فنی (مثل من) مجبور بودن شب‌ ها از خوابشون بزنن و با کلی استرس ، تغییرات رو اعمال کنن تا ری‌استارت باعث اختلال توی کار کاربران نشه. اما حالا دیگه این مشکل رو نداریم و می‌تونیم هر وقت که نیاز بود بدون استرس و نگرانی ، تنظیمات رو بهینه کنیم.ویژگی IO threads تو دیتابیس های دیگه در مقایسه با mariadb چه وضعیتی داره؟تو مقایسه با دیتابیس‌های دیگه تا جایی که من سرچ کردم و دیدم ، تو mysql تا نسخه 8.0 این متغیرها هنوز استاتیک هستن و برای هر تغییری نیاز به ری‌استارت کل سرور هست.تو PostgreSQL، مدیریت IO کلا با دیتابیس های دیگه متفاوته، و به این شکل که از سیستم‌عامل برای مدیریت IO استفاده میکنه. به همین دلیل، دیتابیس PostgreSQL دیگه اصلا نیازی به این تنظیمات مستقیم IO threads نداره، و بیشتر به بهینه‌سازی‌های سیستم‌عامل و تنظیمات حافظه وابسته است.در کل، این تغییر به نظر کوچیک، تاثیر خیلی زیادی توی عملکرد و انعطاف‌پذیری mariadb داره و یکی از ویژگی‌های مهم نسخه ۱۰.۱۱ به حساب میاد. اگه از mariadb استفاده می‌کنی یا می‌خوای ازش استفاده کنی، حتمااااا به این ویژگی خیلی مهم توجه ویژه‌ای بکن و سعی کن ازش به بهترین شکل ممکن بهره ببری.امیدوارم این پست مفید بوده باشه براتون و مرسی که حمایت میکنین

ویژگی undo tablespaces در دیتابیس mariadb

شهریار بیات — Wed, 04 Sep 2024 13:08:27 +0330

تو نسخه‌های قدیمی‌تر mariadb, وقتی داده‌ای تغییر می‌کرد و نیاز به ثبت اون تغییرات داشتیم، این تغییرات به‌صورت undo log در سیستم جداول ذخیره می‌شد. حالا، تو نسخه 10.11 mariadb, داستان یه کم فرق کرده. تو این نسخه، به جای اینکه همه چیز تو یه فضای مشترک (یا همون system tablespace) نوشته بشه، سه تا فایل جداگانه برای ثبت این تغییرات در نظر گرفته شده که هر کدوم تو یه دایرکتوری جداگانه به نام innodb_undo_directory ذخیره می‌شن. اینجوری هم performance بالاتر میره و هم مدیریت راحت‌تر.تو نسخه‌های قبلی، عدد پیش‌فرض برای innodb_undo_tablespaces صفر بود. یعنی همه تغییرات تو همون فضای اصلی ثبت می‌شد. ولی الان این عدد به 3 رسیده که یعنی سه تا فضای جداگانه برای ثبت این تغییرات در نظر گرفته شده. نکته مهم اینجاست که تو نسخه‌های قدیمی‌تر mariadb، بعد از ساخت دیتابیس، نمی‌شد این مقدار رو تغییر داد. اما تو نسخه‌های جدید این مشکل حل شده.اول ببینیم undo log چی هست و چیکار میکنه؟توی دیتابیسی مثل undo log ,mariadb بخشی از فرایند تراکنش‌هاست که نقش خیلی مهمی تو حفظ یکپارچگی داده‌ها داره. وقتی شما یه تراکنش رو اجرا می‌کنید، مثل insert کردن رکورد جدید، یا آپدیت کردن یا حتی حذف ، این تغییرات به‌صورت موقتی ثبت میشن تا زمانی که تراکنش کامل بشه. حالا اینجا undo log وارد میشه.وظیفه undo log اینه که در صورت بروز خطا، یا اگر به هر دلیلی تراکنش لغو بشه، بتونه تغییرات رو به حالت قبل برگردونه. به زبان ساده‌تر، undo log یه کپی از داده‌های اصلی رو قبل از تغییرات نگه میداره. اگه مثلاً وسط یه عملیات آپدیت یه مشکل پیش بیاد یا شما بخواید تغییرات رو لغو کنید، سیستم با استفاده از این undo log برمی‌گرده به حالت قبلی، انگار که اصلاً هیچ تغییری انجام نشده.این کار باعث میشه که دیتابیس همیشه در حالت پایداری باشه و اطلاعات نهایی فقط وقتی ثبت بشه که همه مراحل تراکنش به درستی انجام شده باشن. به این صورت، اگه یه مشکل غیرمنتظره پیش بیاد، اطلاعات شما از دست نمیره و دیتابیس به حالت قبلی خودش برمی‌گرده.توی mariadb، این undo log ها به‌صورت فایل‌هایی در undo tablespaces ذخیره میشن و همونطور که قبلاً گفتم، تو نسخه‌های جدید، شما می‌تونید چندین undo tablespaces داشته باشید که این کار باعث بهبود عملکرد و افزایش امنیت داده‌ها میشه.حالا ببینیم چرا این تغییر مهمهوقتی چندین undo log داریم، می‌تونید داده‌های بیشتری رو همزمان پردازش کنید. این کار باعث میشه که سیستم با سرعت بیشتری کار کنه و در عین حال، از تداخل داده‌ها جلوگیری کنه. اگه تو نسخه‌های قدیمی، یکی از undo log ها مشکلی پیدا می‌کرد، کل فرآیند ممکن بود به مشکل بخوره. ولی حالا با داشتن سه تا فایل جداگانه، اگر یکی خراب بشه، دو تای دیگه هنوز سالم هستن و کار رو ادامه میدن.از نظر فنی، وقتی شما تغییری تو داده‌ها ایجاد می‌کنید، این تغییرات اول تو undo log ثبت می‌شن تا اگه به هر دلیلی لازم شد، بتونید به وضعیت قبلی برگردید. حالا، وقتی این undo log ها تو سه فضای جداگانه ذخیره میشن، سیستم بهتر می‌تونه این تغییرات رو مدیریت کنه و اگر بخوایم برگردیم به حالت قبل، این کار سریع‌تر و مطمئن‌تر انجام میشه.بنابراین، این تغییرات جدید تو نسخه 10.11 mariadb باعث میشه که هم کارایی بهتر بشه و هم مدیریت undo log ها راحت‌تر و مطمئن‌تر بشه. این یه ویژگی مهمه که باعث میشه دیتابیس شما با اطمینان بیشتری کار کنه و از خطرات احتمالی که ممکن بود تو نسخه‌های قبلی پیش بیاد، جلوگیری بشه.

بررسی semi sync replication در دیتابیس mariadb

شهریار بیات — Mon, 02 Sep 2024 15:20:29 +0330

بررسی semi sync replication در دیتابیس mariadbقبلا در مورد replication توی دیتابیس‌ mariadb پست گذاشتم و مفصل صحبت کردیم میدونیم که تئوری CAP باعث میشه همیشه یه جای کار بلنگه. اما mariadb اومده یه راه حلی ارائه داده که یکم تعادل بیشتری بینشون برقرار بشه. الان میخوام semi synchronous replication و توی دیتابیس mariadb بررسی کنم.اول بریم به نگاهی به همه حالت های replication بندازیمحالت اول Asynchronous Replication: این روش ساده‌ترین و سریع‌ترین حالت هست. وقتی داده‌ای روی سرور Master تغییر می‌کنه، این تغییر به سرورهای Replica ارسال میشه، اما سرور Master منتظر تأییدیه از سرورهای Replica نمی‌مونه و بلافاصله به کار خودش ادامه میده. این روش باعث میشه تا عملیات‌ها سریع‌تر انجام بشه، ولی یه مشکل جدی داره، اگه سرور Master قبل از اینکه سرورهای Replica داده‌ها رو دریافت کنن خراب بشه، اون داده‌ها از دست میرن.حالت دوم Synchronous Replication: تو این حالت، سرور Master هر زمان که داده‌ای تغییر کرد، منتظر می‌مونه تا تمام سرورهای Replica تأیید کنن که داده‌ها رو دریافت کردن. تا زمانی که این تأییدیه‌ها نیاد، Master نمیره سراغ عملیات بعدی. این روش خیلی امنه، ولی باعث کاهش سرعت میشه، چون Master باید منتظر بمونه تا تمام Replica ها جواب بدن.حالت سوم Semi-Synchronous Replication: این روش یه حالت بینابینیه. اینجا، Master منتظر می‌مونه تا حداقل یکی از سرورهای Replica تأیید کنه که داده‌ها رو دریافت کرده و بعد به کار خودش ادامه میده. اینطوری هم امنیت داده‌ها تضمین میشه و هم سرعت عملیات خیلی کاهش پیدا نمی‌کنه.بریم ببینیم Semi-Synchronous Replication چطوری کار میکنه؟وقتی یه تغییر تو node master اتفاق می‌افته، این تغییر تو فایلی به اسم Binlog (مخفف Binary Log) ثبت میشه. بعد این تغییرات به سرورهای Replica ارسال میشه. Master منتظر می‌مونه تا حداقل یکی از Replica ها اعلام کنه که این تغییرات رو گرفته و فقط بعد از این تأییدیه‌ست که عملیات بعدی رو انجام میده.مزایای استفاده از Semi-Synchronous Replication چیه؟این روش یه تعادل نسبی خوب بین سرعت و امنیت فراهم می‌کنه. در حالی که در روش Asynchronous ممکنه داده‌ها از دست برن و در روش Synchronous سرعت کاهش پیدا می‌کنه، این روش یه راه حل میانه است که هم سرعت خوبی داره و هم از، ازدست رفتن داده‌ها جلوگیری می‌کنه.پشت پرده یا Under the Hood چه خبره؟پشت پردش اینجوریه که این فرآیند با Binlog (که تغییرات رو ثبت می‌کنه) و یه تایمر انجام میشه. وقتی Master تغییرات رو به Replica ها می‌فرسته، منتظر می‌مونه تا تأییدیه بیاد. اگه بعد از یه مدت زمان مشخص تأییدیه‌ای نیاد، سرور Master ممکنه عملیات رو شکست‌خورده ثبت کنه یا دوباره تلاش کنه.حالا چرا این روش مهمه؟تو روش Asynchronous، اگه سرور Master بپره (یعنی به هر دلیلی از دسترس خارج بشه)، اون داده‌هایی که تازه ثبت شدن و به دست سرورهای Replica نرسیدن، ممکنه از دست برن. این یعنی درسته که سرعت ثبت داده‌ها بالاست، ولی خطر از دست دادن داده‌ها وجود داره. در مقابل، تو روش Synchronous، سرور Master برای ثبت هر تغییر صبر می‌کنه تا تمام سرورهای Replica تأیید کنن که داده‌ها رو دریافت کردن. این یعنی امنیت بالا ولی با هزینه کاهش سرعت.اما تو Semi-Synchronous Replication، یه تعادل خوب بین این دو حالت داریم. اینجا سرور Master منتظر می‌مونه تا حداقل یکی از سرورهای Replica تأیید کنه که داده‌ها رو گرفته. اینطوری اگه یه مشکل برای Master پیش بیاد، حداقل یکی از سرورهای دیگه داده‌ها رو داره و می‌تونید با خیال راحت به کارتون ادامه بدید. البته هنوزم یه ذره سرعت نسبت به روش Asynchronous پایین‌تره، ولی عوضش امینت داریم.برای محیط‌هایی که نیاز به سرعت و امنیت باهم داریم، این روش می‌تونه خیلی مفید باشه. مثلاً توی یه ecommerce project ، میتونیم نسبتا سریع به درخواست های کاربران پاسخ بدیم و هم مطمئن بشیم که اطلاعات هیچ وقت از دست نمی‌رن، این روش یه انتخاب خوبه.

چطوری کانتینر داکر و debug کنیم؟

شهریار بیات — Fri, 30 Aug 2024 15:43:12 +0330

docker debugفرض کن یه پروژه بزرگ داری و همه چیز رو با Docker مدیریت می‌کنی. همه سرویس‌ها و اپلیکیشن‌هات رو ریختی توی کانتینرها و فکر می‌کنی که دیگه خیالت راحته. اما یه روز صبح از خواب پا می‌شی و می‌بینی که یکی از کانتینرها کار نمی‌کنه و مشکلش هم معلوم نیست! اینجا میخوام بررسی کنم مرحله به مرحله و قدم به قدم چطور باید پیش بریم که بتونیم دیباگ کنیم و مشکل و برطرف کنیم.دیباگ کردن با استفاده از ابزارهای ساده‌ی Dockerاولین قدم برای دیباگ کردن اینه که وضعیت کانتینرها رو چک کنی. برای این کار می‌تونی از دستور docker ps استفاده کنی تا ببینی کدوم یکی از کانتینرها به مشکل خوردن. اگه کانتینری متوقف شده یا در حال ری‌استارت ، اولین چیزی که باید چک کنی لاگ‌هاست. خوندن لاگ ها باعث میشه سریع تر متوجه مشکل کانتینر بشی.docker logs [container_id]docker psمثلاً فرض کن که توی لاگ‌ها یه خطایی مثل "Could not connect to database" می‌بینی. این یعنی کانتینر‌ت نمی‌تونه به دیتابیس وصل بشه. حالا باید وارد کانتینرت بشی تا از داخل کانتینر بررسی کنی که آیا سرویس دیتابیس درست کار می‌کنه یا نه.حل مشکلات شبکه‌ای بین کانتینرهایه مشکل رایج دیگه، مشکل تو ارتباط بین کانتینر هاست. مثلاً کانتینرت نتونه با سرویس‌های دیگه ارتباط برقرار کنه. برای این کار باید شبکه‌های Docker رو چک کنی.با این دستورها می‌تونی لیست شبکه‌ها رو ببینی و با ببینی که آیا کانتینرت به درستی به شبکه متصل شده یا نه.docker network lsdocker inspect [network_name]استفاده از Snapshot برای دیباگیه قابلیت خیلی خوب Docker اینه که می‌تونی از وضعیت فعلی کانتینرت Snapshot بگیری. این Snapshot بعداً می‌تونه بهت کمک کنه که اگه یه تغییر مشکل‌زا توی کانتینرت انجام دادی، به حالت قبل برگردی.بیایین یکم روی snapshot گرفتن عمیق تر بشیم ببینیم دقیقا چیکار میشه باهاش کرد و چه کمکی میکنه بهمون.فرض کنید یک کانتینر دارید که به دلایلی به درستی کار نمی‌کنه. شما می‌تونید با استفاده از Docker Commit یک Snapshot از اون بگیرید:docker commit با این دستور، یک docker image جدید از کانتینر فعلی شما ساخته می‌شه. حالا می‌تونید تغییرات مختلف رو روی کانتینر اعمال کنید، مثل نصب پکیج‌های جدید، تغییرات در فایل‌های کانفیگ، یا هرچیز دیگه ای که برای تست نیاز دارید. اگر تغییرات باعث شد مشکلات کانتینر برطرف شد می‌تونید همین و ادامه بدین. اما اگر تغییرات باعث شد مشکل جدیدی بوجود بیاد می‌تونید به راحتی به Snapshot قبلی برگردید.مثال:فرض کنید یک کانتینر Nginx دارید که برای اجرای وب‌سرور به کار می‌ره و شما به مشکل برخوردید. با دستور زیر از وضعیت فعلی کانتینر یک Snapshot می‌گیرید:docker commit nginx_container my_nginx_snapshotحالا می‌تونید تغییرات مختلفی روی کانتینر انجام بدین. اگر مشکلی به وجود اومد، کافیه کانتینر جدیدی از Snapshot قبلی بسازید و با اون کار رو ادامه بدید:docker run -d my_nginx_snapshotاین روش این امکان رو می‌ده که بدون نگرانی از دست دادن وضعیت فعلی کانتینر، تغییرات لازم رو انجام بدین و در صورت نیاز، به وضعیت قبلی برگردید. این قابلیت به خصوص در فرآیندهای دیباگ و تست بسیار مفیده و می‌تونه زمان زیادی رو صرفه‌جویی کنه.نکاتی برای جلوگیری از بروز مجدد مشکلاتبعد از اینکه مشکل رو پیدا کردی و حلش کردی، باید به فکر این باشی که چطور می‌تونی جلوی بروز مجدد این مشکل رو بگیری. یه راه اینه که Dockerfile رو بهینه‌سازی کنی یا تنظیمات Docker Compose رو بهتر کنی. مثلاً می‌تونی کانفیگ شبکه رو چک کنی، وابستگی‌ها رو به دقت مدیریت کنی، و از ابزارهای مانیتورینگ برای بررسی وضعیت کانتینرها استفاده کنی.استفاده از ابزارهای پیشرفته‌تر برای دیباگبجز ابزارهای پیشفرضی که خود Docker ارائه می‌ده، می‌تونی از ابزارهای پیشرفته‌تری مثل strace یا gdb برای دیباگ مشکلات عمیق‌تر استفاده کنی. مثلاً اگه مشکلت با یه پردازش خاص داخل کانتینر باشه، می‌تونی با استفاده از این ابزارها ردیابی کنی که دقیقاً چه اتفاقی داره می‌افته.بزارین یکم عمیق تر بشیم روی trace , gdb و ببینیم چی هستن و چه کاربردی میتونن برامون داشته باشن؟ابزار strace یکی از ابزارهای قدرتمند توی لینوکس که به شما اجازه میده سیستم‌کال‌ها (سیستم‌کال‌ها درخواست‌هایی هستن که برنامه‌ها برای انجام کارهای سطح پایین به کرنل لینوکس ارسال میکنن) و سیگنال‌های دریافت‌شده توسط برنامه رو ردیابی کنید. استفاده از ابزار strace برای دیباگ کانتینرها کمک میکنه تا بدونیم دقیقاً چه اتفاقی داخل کانتینر می افته.فرض کن میخوایم برنامه‌ای که توی کانتینر اجرا شده رو track کنیم. با استفاده از این دستور میتونیم سیستم‌کال‌ها و سیگنال‌های این برنامه رو ببینم:docker exec -it [container_id] strace -p [process_id]این دستور تمام سیستم‌کال‌هایی که توسط کانتینر داکر به کرنل لینوکس ارسال میشه رو به ما نشون میده. اگر مشکل در دسترسی به فایل‌ها، شبکه یا سیستم‌های دیگه باشه، strace کمک میکنه تا مشکل را شناسایی کنیم.اما دستور gdb یا GNU Debugger یه دیباگره، که اجازه میده برنامه‌های در حال اجرا رو بررسی و کنترل کنیم. این ابزار برای پیدا کردن باگ‌ها در source code خیلی میتونه کاربردی باشه.تکنیک‌های بهبود عملکرد کانتینرگاهی اوقات مشکل کانتینر میتونه به دلیل پایین بودن عملکردش باشه. برای بهبود عملکرد کانتینرها، باید تنظیمات منابع رو بهینه کنی. مثلاً اگه کانتینرت داره بیش از حد از CPU یا RAM استفاده می‌کنه، می‌تونی با تنظیم منابع مثل --cpu-shares یا --memory مقدار مصرف منابع رو محدود کنی. همچنین، استفاده از Multistage Builds توی Dockerfile می‌تونه حجم نهایی image رو کاهش بده و باعث بهبود سرعت اجرای کانتینر بشه.امیدوارم این مطلب مفید بوده باشه براتون و مرسی که حمایت میکنید.

کش در دیتابیس mariadb

شهریار بیات — Thu, 29 Aug 2024 20:44:12 +0330

ما تو هومسا یه چالشی داشتیم برای افزایش ظرفیت کش دیتابیس ، این شد بهونه ای برای اینکه یه نگاهی به کش دیتابیس mariadb بندازیم و ببینیم چه نقطه قوت و ضعفی داره و چه قابلیت هایی رو بهمون ارائه میده.کش دیتابیس توی MariaDB یکی از اون چیزهای مهمیه که اگه خوب تنظیمش کنی، سرعت و عملکرد دیتابیس رو حسابی بالا می‌بره. حالا فرض کن یه کوئری رو چند بار پشت سر هم اجرا می‌کنی. به جای اینکه هر بار از اول همه چی اجرا بشه، نتیجه رو توی کش ذخیره می‌کنه و سری بعد از همون استفاده می‌کنه. این کار باعث میشه سرور کمتر زیر بار بره و زمان پاسخ‌دهی هم سریع‌تر بشه.کش دیتابیس دو تا بخش اصلی داره: یکی Query Cache و یکی دیگه هم Buffer Pool.کوئری کش (Query Cache) همونطور که از اسمش معلومه، نتایج کوئری‌ها رو ذخیره می‌کنه. یعنی اگه همون کوئری دوباره اجرا بشه، نتیجه از کش برمی‌گرده. اما نکته‌ای که وجود داره اینه که توی نسخه‌های جدیدتر MariaDB، این قابلیت کم کم حذف شده چون هماهنگ کردنش با تغییرات داده‌ها خیلی دردسر داشت.قابلیت Buffer Pool همون جاییه که داده‌ها و صفحات رو توی RAM نگه می‌داره. وقتی یه رکورد رو می‌خونی، اگه قبلاً خونده شده باشه، به جای اینکه دوباره از دیسک بخونه، از اینجا برمی‌گردونه. اینطوری سرعت دسترسی به داده‌ها خیلی میره بالا.حالا اگه بخوای مقایسه کنی، MySQL هم کش دیتابیس مشابهی داره، ولی توی نسخه‌های جدیدش مثل MariaDB، Query Cache رو حذف کردن. علتش هم اینه که مدیریت این کش توی سیستم‌های بزرگ سخت و پیچیده بود. در عوض، بیشتر تمرکزشون رو گذاشتن روی بهبود Buffer Pool و راهکارهای دیگه‌ای برای مدیریت کش.دیتابیس PostgreSQL اما یه راه متفاوتی رو رفته. این دیتابیس اصولاً Query Cache نداره، ولی سیستم کشینگش خیلی بهینه‌تره. از یه چیزی به اسم Shared Buffers استفاده می‌کنه که داده‌ها رو توی حافظه نگه داره. در کل، PostgreSQL بیشتر رو بهینه‌سازی سیستم‌عامل و استفاده بهینه‌تر از حافظه تمرکز داره.الگوریتم‌های کش، مثل LRU (Least Recently Used)، معمولاً تضمین می‌کنن که داده‌های قدیمی‌تر و کم‌استفاده‌تر از حافظه حذف بشن تا جا برای داده‌های جدیدتر و مهم‌تر باز بشه. اگه بخوای عملکرد کش رو بهتر کنی، می‌تونی اندازه Buffer Pool رو بیشتر کنی یا پارامترهای مرتبط با کش رو تنظیم کنی.در نهایت، برای اینکه کش دیتابیس توی MariaDB بهتر کار کنه، باید به پارامترهایی مثل innodb_buffer_pool_size دقت کنی. این پارامتر تعیین می‌کنه که اندازه Buffer Pool چقدر باشه و افزایشش می‌تونه عملکرد دیتابیس رو بهبود بده. همچنین استفاده از ابزارهای مانیتورینگ برای مشاهده عملکرد کش و تنظیمات دقیق‌تر، خیلی کمک می‌کنه.