<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های امیرحسین حاجی محمدی</title>
        <link>https://virgool.io/feed/@a-hajimohammadi</link>
        <description>یه دواپس سرسخت و عاشق تکنولوژی که بیشتر تو دنیای سرورهاست!  همیشه دنبال یه بهینه‌سازی جدید ☕️</description>
        <language>fa</language>
        <pubDate>2026-06-16 18:02:53</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/3810646/avatar/KWRmAX.jpg?height=120&amp;width=120</url>
            <title>امیرحسین حاجی محمدی</title>
            <link>https://virgool.io/@a-hajimohammadi</link>
        </image>

                    <item>
                <title>🤯 آیا AI جای مهندس‌ها رو می‌گیره؟ بررسی نقش n8n و MCP در آینده اتوماسیون</title>
                <link>https://virgool.io/@a-hajimohammadi/%D8%A2%DB%8C%D8%A7-ai-%D8%AC%D8%A7%DB%8C-%D9%85%D9%87%D9%86%D8%AF%D8%B3-%D9%87%D8%A7-%D8%B1%D9%88-%D9%85%DB%8C-%DA%AF%DB%8C%D8%B1%D9%87-%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%86%D9%82%D8%B4-n8n-%D9%88-mcp-%D8%AF%D8%B1-%D8%A2%DB%8C%D9%86%D8%AF%D9%87-%D8%A7%D8%AA%D9%88%D9%85%D8%A7%D8%B3%DB%8C%D9%88%D9%86-elvhbg9ayons</link>
                <description>Brain Systemاین روزا هر طرف رو نگاه می‌کنیم، صحبت از هوش مصنوعیه (همون AI خودمون) و ابزارهایی که کارای تکراری رو خودکار می‌کنن و سرویس‌های مختلف رو به هم وصل می‌کنن، حسابی سروصدا به پا کردن. تو این مقاله می‌خوایم با هم ببینیم اصلاً این AI چیه، ابزارهایی مثل n8n و MCP چه نقشی تو این ماجرا دارن، چند تا ابزار باحال دیگه هم بشناسیم، بفهمیم آیا اینا دارن جای مهندس‌ها رو می‌گیرن یا نه، یه وقت گیج نشیم تو این همه ابزار، و آخرش هم یه راه درست و حسابی برای یاد گرفتن و استفاده کردن از این دنیای بزرگ رو با هم مرور کنیم. خیالتون راحت، همه چی رو ساده و خودمونی می‌گیم، پس بریم که داشته باشیم!هوش مصنوعی (AI)؛ یه نگاه سریعهوش مصنوعی یعنی اینکه به ماشین‌ها یاد بدیم مثل آدم‌ها فکر کنن و کار کنن. از تشخیص عکس و نوشتن متن گرفته تا تصمیم گرفتن و پیش‌بینی کردن اتفاقات. این روزا مدل‌های زبانی بزرگ (که بهشون می‌گن LLM) مثل GPT و Claude خیلی معروف شدن و تو چت‌بات‌ها، تحلیل داده‌ها و سیستم‌هایی که بهمون پیشنهاد فیلم و سریال میدن، کلی کاربرد دارن.ابزارهای اصلی: n8n و MCP‏n8n:چیه؟ یه جور پلتفرم رایگان و متن‌باز که باهاش می‌تونین کارهای مختلف رو بدون اینکه کد بنویسین، خودکار کنین (به این کار می‌گن ساختن Workflow).چیا داره؟ می‌تونین نودهای مختلف رو بکشین و بندازین تا یه جریان کاری (workflow) درست کنین.صدها نود آماده داره که می‌تونین به APIهای مختلف، دیتابیس‌ها و سرویس‌های دیگه وصل بشین.می‌تونین رو سرور خودتون نصبش کنین و خیالتون راحت باشه که اطلاعاتتون دست خودتونه.ربطش با AI چیه؟ می‌تونین یه نود اضافه کنین که با مدل‌های LLM مثل GPT حرف بزنه تا متن تولید کنه، یه چیزی رو تحلیل کنه یا حتی با اطلاعات شما یه کارایی انجام بده.‏MCP (Model Context Protocol)چیه؟ یه جور زبون مشترک و استاندارد که برای ارتباط بین مدل‌های AI و جاهایی که اطلاعات هست یا ابزارهای دیگه ساخته شده.چیا داره؟یه روش یکسان برای اینکه مدل‌های AI از سرویس‌های مختلف درخواست بدن و جواب بگیرن.امنیتش دست خودتونه و می‌تونین هر جور که می‌خواین سطح دسترسی‌ها رو تنظیم کنین.دیگه لازم نیست برای هر سرویس یه جور راه اتصال جدا بسازین.ربطش با AI چیه؟ ربات‌های هوشمند (که بهشون Agent هم می‌گن) می‌تونن مستقیم به APIها، دیتابیس‌ها یا سرویس‌های شما وصل بشن و از اطلاعات اونا برای جواب دادن‌های هوشمندانه استفاده کنن.ابزارهای دیگه که بد نیست بشناسیدعلاوه بر n8n و MCP، این پایین چند تا ابزار دیگه هم هستن که تو این زمینه خیلی به درد می‌خورن:‏Zapier: یه ابزار آسون برای خودکارسازی کارها، بیشتر برای کسب‌وکارهای کوچیک و متوسط خوبه. خیلی سریع می‌تونین سرویس‌های مختلف رو به هم وصل کنین.‏Make (Integromat): یه رابط گرافیکی خیلی قوی داره که می‌تونین باهاش جریان‌های کاری پیچیده رو طراحی کنین.‏Apache Airflow: برای وقتی که می‌خواین جریان‌های کاری خیلی بزرگ رو مدیریت کنین، مثلاً تو پروژه‌های یادگیری ماشین (MLOps) و تیم‌های داده خیلی کاربرد داره.‏Prefect: یه رقیب برای Airflow هست، ولی کار کردن باهاش یه کم آسون‌تره و بیشتر روی خودکارسازی کارهای هوشمند تمرکز داره.‏LangChain: یه جور جعبه ابزار پایتونیه که باهاش می‌تونین برنامه‌هایی بسازین که از مدل‌های LLM استفاده می‌کنن و به منابع اطلاعاتی مختلف وصل می‌شن.‏MLflow: برای مدیریت کل مراحل ساخت و استفاده از مدل‌های یادگیری ماشین خوبه، از ثبت آزمایش‌ها گرفته تا نسخه‌بندی و راه‌اندازی مدل‌ها.آیا این ابزارها جای مهندس‌ها رو می‌گیرن؟اصلاً این‌طور نیست! این ابزارها بیشتر کارای تکراری و حوصله‌سربر رو از دوش مهندس‌ها برمی‌دارن:طراحی معماری: هنوزم نیاز هست که یکی بیاد و تصمیم‌های مهم بگیره و ساختار کلی سیستم رو درست طراحی کنه.بهینه‌سازی و نگهداری: نظارت کردن روی سیستم، پیدا کردن و رفع ایرادها و به‌روزرسانی کردنشون همیشه کار مهندس‌هاست.ساخت قابلیت‌های خاص: بعضی وقتا لازمه یه سری قابلیت‌های مخصوص برای یه کسب‌وکار خاص نوشته بشه.امنیت و حریم خصوصی: طراحی سیستم‌های امن و رعایت قوانین مربوط به حریم خصوصی (مثل GDPR) کار آدم‌های متخصصیه.در نتیجه، این ابزارها به جای اینکه مهندس‌ها رو حذف کنن، وقتشون رو برای کارهای مهم‌تر و خلاقانه‌تر آزاد می‌کنن.این همه ابزار آدم رو گیج نمی‌کنه؟اگه بدون برنامه شروع کنین یا بخواین یه دفعه همه اینا رو یاد بگیرین، ممکنه یه کم قاطی کنین.ولی اگه این‌جوری پیش برین، خیلی هم ساده‌ست:اول ببینین واقعاً به چه چیزایی نیاز دارین.با یه ابزار ساده شروع کنین و کم‌کم جلو برین.قبل از اینکه برین سراغ ابزار بعدی، اول یه ابزار رو خوب یاد بگیرین.یه راه خوب برای یادگیری و استفادهاول مبانی API و HTTP رو یاد بگیرین: مفهوم REST، JSON و کار کردن با Postman یا curl رو بفهمین.با ابزارهای No-Code/Low-Code شروع کنین: یه کار ساده رو با n8n یا Zapier خودکار کنین (مثلاً فرستادن یه ایمیل خودکار).با پروتکل‌ها و فریم‌ورک‌های AI آشنا بشین: یه سرور یا کلاینت MCP راه بندازین.- یه برنامه ساده با LangChain بسازین (مثلاً یه چت‌بات برای سوالات متداول).کم‌کم وارد دنیای MLOps و اورکستریشن بشین: یه pipeline تو Airflow یا Prefect تعریف کنین.- مدل‌های یادگیری ماشین رو با MLflow نظارت و ردیابی کنین.پروژه‌محور کار کنین و همه چی رو مستند کنین: کدها و فلوهاتون رو تو GitHub بذارین.- یه راهنما برای کار کردن با پروژه‌تون بنویسین.همیشه به‌روز باشین: خبرنامه‌های مربوط به AI و اتوماسیون رو دنبال کنین (مثل AI Weekly یا n8n Newsletter).- تو وبینارها و کارگاه‌های آنلاین شرکت کنین.جمع‌بندیابزارهایی مثل n8n، MCP و بقیه رفقاشون، دنیای اتوماسیون و AI رو خیلی جذاب‌تر و کاربردی‌تر کردن. اگه با یه برنامه درست پیش برین، نه تنها گیج نمی‌شین، بلکه سرعت و کیفیت کارتون هم خیلی بهتر می‌شه. کلید موفقیت اینه که ساده شروع کنین، مرحله به مرحله یاد بگیرین و با پروژه‌های واقعی تمرین کنین. حالا شما چی فکر می‌کنین؟ تجربه‌ای تو این زمینه داشتین؟ تو کامنت‌ها برام بنویسین تا بیشتر با هم گپ بزنیم!</description>
                <category>امیرحسین حاجی محمدی</category>
                <author>امیرحسین حاجی محمدی</author>
                <pubDate>Tue, 13 May 2025 13:23:26 +0330</pubDate>
            </item>
                    <item>
                <title>‏Kubelet: با طعم Best Practices!</title>
                <link>https://virgool.io/@a-hajimohammadi/kubelet-%D8%A8%D8%A7-%D8%B7%D8%B9%D9%85-best-practices-kctu5iqvuxoa</link>
                <description>Kubeletاگه داری با Kubernetes حال می‌کنی (یا شاید هم داری زور می‌زنی که حال کنی 😅)، حتماً اسم Kubelet به گوشت خورده. ایشون در اصل مغز متفکر هر Node توی کلاسترته؛ یه جورایی کارگر وفاداریه که همیشه توی صحنه‌ست!حالا بیایم ببینیم چطور می‌تونیم این موجود دوست‌داشتنی رو به بهترین شکل ممکن کانفیگ کنیم تا هم بهتر کار کنه و هم کمتر اذیت‌مون کنه.‏🤖 Kubelet دقیقاً چیه؟قبل از اینکه بریم سراغ کانفیگ حرفه‌ای، یه یادآوری کوچیک: Kubelet یه agent روی هر نود توی Kubernetes هست که وظیفه‌ش اجرای پادها، بررسی سلامتی‌شون (health)، و گزارش دادن به کنترل پلینه.‏🛠️ راه‌های کانفیگ Kubelet‏Kubelet چند روش برای تنظیمات داره:‏Command-line flags (مثل --v=2)‏Configuration file (kubelet config YAML) از نسخه 1.10 به بعد توصیه‌شده‏‏Environment variables (تو برخی سیستم‌ها)‏🎯 Best Practice: به جای فلگ‌های خط فرمان، از فایل کانفیگ استفاده کن! هم خوندنش راحت‌تره، هم مانیتورش آسون‌تره.‏🧾 ساختار فایل کانفیگ Kubelet (YAML)یه نمونه از فایل کانفیگ:apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
authentication:
   anonymous:
      enabled: false
   webhook:
       enabled: true
authorization:
   mode: Webhook
readOnlyPort: 0
cgroupDriver: systemd
failSwapOn: true
maxPods: 110
rotateCertificates: true
serverTLSBootstrap: true‏💎 Best Practiceها برای کانفیگ Kubelet‏1. 🔐 امنیت حرف اول رو می‌زنهخاموش کردن پورت Read-Only:readOnlyPort: 0فعال کردن Webhook برای authn/authz:authentication:
   webhook:
      enabled: true
   authorization:
      mode: Webhook‏2. 🎯 مدیریت منابع در Kubelet: هنر تعادل!مدیریت منابع توی Kubelet مثل هنر بالانس کردن بشقاب‌هاست!اگه درست انجامش ندی، یا Kubelet له می‌شه زیر فشار، یا سیستم‌عامل هنگ می‌کنه، یا پادها شروع می‌کنن به مردن بی‌صدا. 😵‏📌 منابع اصلی قابل تنظیم:‏systemReserved – برای سیستم‌عامل (مثل journald، systemd)‏kubeReserved – برای خود اجزای Kubernetes (مثل kubelet، kube-proxy)‏eviction thresholds – مدیریت بحران کمبود منابع‏QoS Classes و cgroupها – کنترل اولویت پادها‏🧠 systemReserved و kubeReservedبرای اینکه سیستم‌عامل و Kubelet خودش زیر فشار پادها از پا درنیاد، منابع رزرو براشون بذار:systemReserved:
   cpu: &amp;quot200m&amp;quot
   memory: &amp;quot512Mi&amp;quot
   ephemeral-storage: &amp;quot1Gi&amp;quot

kubeReserved:
   cpu: &amp;quot100m&amp;quot
   memory: &amp;quot256Mi&amp;quot
   ephemeral-storage: &amp;quot1Gi&amp;quot‏💡 سیستم‌های بزرگ‌تر = منابع بیشترمثال: برای نودهای با 8 CPU و 32GB RAM، شاید بد نباشه 500m CPU و 1GB RAM برای systemReserved در نظر بگیری.‏💣 Eviction Thresholdها: فرار از بحران!اگه منابع خیلی کم بشن، Kubelet پادها رو پاک می‌کنه تا خودش و نود زنده بمونن.evictionHard:
   memory.available: &amp;quot100Mi&amp;quot
   nodefs.available: &amp;quot10%&amp;quot
   imagefs.available: &amp;quot15%&amp;quot

evictionSoft:
   memory.available: &amp;quot300Mi&amp;quot
   nodefs.available: &amp;quot15%&amp;quot

evictionSoftGracePeriod:
   memory.available: &amp;quot1m&amp;quot
   nodefs.available: &amp;quot30s&amp;quot‏✅ با این تنظیمات، Kubelet اول هشدار می‌ده (soft)، اگه وضع وخیم‌تر شد می‌زنه پادهای سبک‌تر رو حذف می‌کنه.‏🧠 QoS Classها و Cgroupهابر اساس requests و limits، Kubelet پادها رو تو سه کلاس قرار می‌ده:❗ پادهای BestEffort اولین قربانی‌های eviction هستن!‏3. 📦 محدود کردن تعداد پادها در هر نودmaxPods: 110بسته به حجم منابع نود، این عدد رو تنظیم کن. برای نودهای سبک، 60 تا 80 پاد منطقی‌تره.‏4. 🧹 زباله‌جمع‌کنی حرفه‌ای با ImageGC و PodGCimageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 70وقتی دیسک پر می‌شه، ایمیج‌هایی که مدت طولانی استفاده نشدن رو حذف می‌کنه.‏5. 🔁 چرخش خودکار TLS CertrotateCertificates: true
serverTLSBootstrap: trueحوصله نداری هر ۹۰ روز cert رو دستی عوض کنی؟ این گزینه رو روشن کن 😎‏6. 🧪 Health Check داخلی KubelethealthzPort: 10248
healthzBindAddress: 127.0.0.1❗ حواست باشه این پورت فقط روی localhost باز باشه، نه کل شبکه!‏7. 🐧 تنظیم صحیح Cgroup DrivercgroupDriver: systemdاگه container runtime (مثل containerd) از systemd استفاده می‌کنه، Kubelet هم باید باهاش هماهنگ باشه.‏8. 🧾 فعال‌سازی Static Pod LoggingstaticPodPath: /etc/kubernetes/manifests‏✅ نمونه کامل فایل KubeletConfigurationapiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
readOnlyPort: 0
healthzBindAddress: 127.0.0.1
authentication:
   anonymous:
      enabled: false
   webhook:
      enabled: true
authorization:
   mode: Webhook
rotateCertificates: true
serverTLSBootstrap: true
cgroupDriver: systemd
failSwapOn: true
maxPods: 100
kubeReserved:
   cpu: &amp;quot100m&amp;quot
   memory: &amp;quot256Mi&amp;quot
   ephemeral-storage: &amp;quot1Gi&amp;quot
systemReserved:
   cpu: &amp;quot200m&amp;quot
   memory: &amp;quot512Mi&amp;quot
   ephemeral-storage: &amp;quot1Gi&amp;quot
evictionHard:
   memory.available: &amp;quot100Mi&amp;quot
   nodefs.available: &amp;quot10%&amp;quot
   imagefs.available: &amp;quot15%&amp;quot
evictionSoft:
   memory.available: &amp;quot300Mi&amp;quot
   nodefs.available: &amp;quot15%&amp;quot
evictionSoftGracePeriod:
   memory.available: &amp;quot1m&amp;quot
   nodefs.available: &amp;quot30s&amp;quot
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 70
staticPodPath: /etc/kubernetes/manifests‏🧠 نتیجه‌گیری‏Kubelet یه سرباز همیشه بیداره تو ارتش Kubernetes!اگه خوب بهش منابع بدی، درست تنظیمش کنی، و گوش به حرفاش بدی (تو لاگ‌ها)، کلاسترت همیشه سالم و خوشحال می‌مونه.</description>
                <category>امیرحسین حاجی محمدی</category>
                <author>امیرحسین حاجی محمدی</author>
                <pubDate>Wed, 09 Apr 2025 13:23:52 +0330</pubDate>
            </item>
                    <item>
                <title>چگونه مصرف RAM نودهای مستر Elasticsearch را کنترل کنیم؟ (و اعصابمان را راحت کنیم!) 🚀🔥</title>
                <link>https://virgool.io/@a-hajimohammadi/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D9%85%D8%B5%D8%B1%D9%81-ram-%D9%86%D9%88%D8%AF%D9%87%D8%A7%DB%8C-%D9%85%D8%B3%D8%AA%D8%B1-elasticsearch-%D8%B1%D8%A7-%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%DA%A9%D9%86%DB%8C%D9%85-%D9%88-%D8%A7%D8%B9%D8%B5%D8%A7%D8%A8%D9%85%D8%A7%D9%86-%D8%B1%D8%A7-%D8%B1%D8%A7%D8%AD%D8%AA-%DA%A9%D9%86%DB%8C%D9%85-pjc1adiuhqhh</link>
                <description>داستانی از نودهای مستری که RAM را بلعیدند!یک روز خوب و خوش، نودهای مستر ما که قرار بود فقط مدیریت کلاستر را انجام دهند، شروع کردند به بلعیدن RAM مثل یک آدم گرسنه ! 🍕😅 با ۱۲ گیگابایت رم برای هر مستر نود، انتظار داشتیم که اوضاع آرام باشد، اما وقتی دیدیم مصرف RAM تا ۹۰٪ پر شده، فهمیدیم که اینجا چیزی درست کار نمی‌کند.خب، دست به کار شدیم و تصمیم گرفتیم یک عملیات نجات برای حافظه سرورهای عزیزمان اجرا کنیم! 🚑۱. بررسی Heap Memory (آیا بیش از حد RAM می‌خواهیم؟)یافته‌ها:‏Heap Memory برای نودهای مستر ۸ گیگابایت تنظیم شده بود.نودهای مستر نباید هیولاهای حافظه باشند، بلکه فقط کارهای مدیریتی انجام دهند.راه‌حل:‏✅ Heap Size را کاهش دادیم تا مصرف غیرضروری را کنترل کنیم.‏🔧 تنظیمات در jvm.options به این صورت شد:-Xms6g
-Xmx6g‏💡 مستر نود به 6 گیگ Heap بیشتر نیاز ندارد، چون کارش فقط مدیریت است، نه ذخیره‌سازی داده‌ها!۲. بررسی Garbage Collection (آیا JVM با RAM قهر کرده؟)🔍 نتایج بررسی:‏‏Young GC حدود ۲۷۴۱ بار اجرا شده بود، ولی Old GC تقریباً خوابیده بود.‏G1GC خوب کار می‌کرد، اما بهینه‌تر کردنش ضرری نداشت.‏✅ G1GC را فعال و تنظیم کردیم تا بهتر حافظه را مدیریت کند:-XX:+UseG1GCبعدش یک ری‌استارت زدیم و زندگی شیرین‌تر شد! 😎۳. محدود کردن تعداد Threadها (مستر نودها، لطفاً کمتر حرف بزنید!)بعضی از مستر نودها فکر می‌کنند که باید توی همه‌ی کارها دخالت کنند! اما حقیقت اینه که این نودها نباید درخواست‌های سرچ و نوشتن داده را پردازش کنند. پس تصمیم گرفتیم که کمی آن‌ها را ساکت کنیم. 🤫✅ در elasticsearch.yml این مقادیر را اضافه کردیم:thread_pool.search.size: 2
thread_pool.write.size: 1💡 این باعث شد که نودهای مستر دست از سر پردازش درخواست‌ها بردارند و فقط مدیریت کنند. (بالاخره فهمیدند که نقش‌شان چیه! 😆)۴. بررسی Page Cache و مصرف مستقیم RAM🔍 با یک بررسی ساده فهمیدیم که Page Cache حافظه زیادی مصرف نمی‌کند، ولی با افزایش refresh_interval کمی فشار را کم کردیم.✅ تنظیم refresh_interval برای کاهش فشار روی RAM:PUT _all/_settings
{
   &amp;quotindex&amp;quot: {
       &amp;quotrefresh_interval&amp;quot: &amp;quot30s&amp;quot
  }
}این کار باعث شد که Elasticsearch کمتر داده‌ها را از دیسک به RAM بخواند و مصرف حافظه کمتر شود. نتایج نهایی (و جشن کاهش مصرف RAM!) 🎉بعد از انجام این تغییرات، مصرف RAM نودهای مستر به‌شدت کاهش پیدا کرد و عملکرد کلی Elasticsearch بسیار بهتر شد. 🚀 حالا دیگه نودهای مستر مثل قبل حافظه را نمی‌بلعند و ما هم می‌تونیم با خیال راحت قهومون را بنوشیم! ☕😎خلاصه کارهایی که انجام دادیم:‏✅ Heap Size را کاهش دادیم (۸ گیگ به 6 گیگ).‏✅ Garbage Collection را بهینه کردیم (G1GC را فعال کردیم).‏✅ تعداد Threadهای غیرضروری را کم کردیم (برای سرچ و نوشتن).‏✅ Page Cache را بهینه کردیم.‏💡 اگر شما هم با مصرف بالای RAM در نودهای مستر Elasticsearch مشکل دارید، همین روش‌ها را اجرا کنید و نتیجه را ببینید! 😉</description>
                <category>امیرحسین حاجی محمدی</category>
                <author>امیرحسین حاجی محمدی</author>
                <pubDate>Sun, 09 Mar 2025 15:52:31 +0330</pubDate>
            </item>
                    <item>
                <title>‏Pghero: قهرمان مانیتورینگ پایگاه داده‌های PostgreSQL</title>
                <link>https://virgool.io/@a-hajimohammadi/pghero-%D9%82%D9%87%D8%B1%D9%85%D8%A7%D9%86-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7%DB%8C-postgresql-up41w8i7ajvt</link>
                <description>pghero dashboardحتماً تا حالا شده که سیستم‌تون کند بشه و ندونید که دقیقاً مشکل از کجاست؟ یا مثلاً فکر کنید دیتابیس‌تون حالش خوبه، ولی در واقع پشت پرده کلی کوئری کند داره اجرا می‌شه که حسابی به سرورش فشار میاره؟ خب، اینجاست که یه ابزار خفن به نام PgHero میاد وسط و مثل یه قهرمان، دیتابیس شما رو نجات می‌ده! 🦸‍♂️‏PgHero چیه و چرا بهش نیاز داریم؟‏PgHero یه ابزار متن‌باز برای مانیتورینگ و بهینه‌سازی PostgreSQL هست که به شما کمک می‌کنه:ببینید کدوم کوئری‌ها کند هستن و چی باعث این مشکل شده.بفهمید چقدر ایندکس‌هاتون کارآمد هستن و آیا بهینه‌سازی نیاز دارن یا نه.وضعیت کلی کانکشن‌ها و میزان مصرف منابع دیتابیس رو بررسی کنید.همه اینا رو توی یه رابط کاربری خیلی خفن و ساده ببینید. 🎨نصب و راه‌اندازی PgHeroنصب با Docker 🐳اگر از Docker استفاده می‌کنید، خیلی راحت می‌تونید PgHero رو اجرا کنید:docker run -d --name pghero -p 8080:8080 \
  -e DATABASE_URL=postgres://user:password@host:port/database \
  ankane/pgheroبعد از اجرا، کافیه برید به http://localhost:8080 و از داشبورد خوشگل PgHero لذت ببرید. 😎نصب در Kubernetes با Helm 🚀برای کسایی که Kubernetes استفاده می‌کنن، ما یه Helm Chart آماده کردیم که نصب PgHero رو خیلی راحت‌تر می‌کنه. میتونی از اینجا دانلودش کنی.چه چیزایی رو می‌تونیم با PgHero ببینیم؟ 👀وقتی PgHero رو اجرا کنید، یه داشبورد جذاب بهتون نشون می‌ده که اطلاعات مختلفی توش هست:‏Long Running Queries: کوئری‌هایی که خیلی طول می‌کشن.‏Query Stats: آماری از کوئری‌های اجرا شده.‏Slow Queries: کوئری‌هایی که بهینه اجرا نمی‌شن.‏Index Usage: بررسی اینکه آیا ایندکس‌های شما درست کار می‌کنن یا نه.‏Connections: تعداد کانکشن‌های باز به دیتابیس.یه مثال واقعی 🎭فرض کنید یه فروشگاه اینترنتی دارید و کاربرا میان و ازتون خرید می‌کنن. اگر دیتابیس شما مشکل داشته باشه، ممکنه خریدها با تأخیر انجام بشن و کاربرا عصبانی بشن. 😡 با PgHero می‌تونید ببینید که مثلاً کوئری مربوط به محصولات خیلی کند اجرا می‌شه و احتمالاً یه ایندکس کم داره. بعد با یه بهینه‌سازی کوچیک، سرعت رو چند برابر کنید و تجربه کاربری رو بهبود بدید! 🎉نتیجه‌گیری‏PgHero یه ابزار فوق‌العاده برای کساییه که PostgreSQL دارن و می‌خوان دیتابیس‌شون رو بهینه‌تر کنن. چه برای DevOpsها، چه برای بک‌اند دولوپرها و چه حتی برای مدیرای سیستم، این ابزار می‌تونه حسابی مفید باشه. پس وقتشه که قهرمان دیتابیس‌تون بشید و PgHero رو نصب کنید! 💪🔥لینک‌های مفید:‏PgHero در گیت‌هاب‏Pghero Helm chart</description>
                <category>امیرحسین حاجی محمدی</category>
                <author>امیرحسین حاجی محمدی</author>
                <pubDate>Wed, 05 Mar 2025 17:56:40 +0330</pubDate>
            </item>
                    <item>
                <title>با Redis Sentinel دیگه نگران کرش کردن Master نباش!</title>
                <link>https://virgool.io/SnappTripBlog/%D8%A8%D8%A7-redis-sentinel-%D8%AF%DB%8C%DA%AF%D9%87-%D9%86%DA%AF%D8%B1%D8%A7%D9%86-%DA%A9%D8%B1%D8%B4-%DA%A9%D8%B1%D8%AF%D9%86-master-%D9%86%D8%A8%D8%A7%D8%B4-ltnivfkqqmj1</link>
                <description>Redis Sentinelمقدمهاگر تا حالا با Redis کار کردید، احتمالاً می‌دونید که این دیتابیس سریع و دوست‌داشتنی چقدر توی کش کردن و مدیریت داده‌های موقتی محبوبه. اما چالش از اونجایی شروع می‌شه که قراره High Availability رو پیاده کنیم. خب، بیاید ببینیم چه گزینه‌هایی داریم و چرا Redis Sentinel یه انتخاب هوشمندانه‌ست!انواع مدل‌های پیاده‌سازی Redis:۱.  مدل Standalone (تک‌نفره! 🤷‍♂️)یه نمونه Redis داریم و همه درخواست‌ها رو اون پاسخ می‌ده.خب، ولی اگه این کرش کنه، فاتحه!۲. مدل Master-Slave (سلطنت دو نفره! 👑)یه Master داریم که می‌نویسه، Slaveها فقط می‌خونن.اگه Master بمیره، دستی باید جابه‌جا کنیم که خیلی سخته!۳. مدل Cluster Mode (جمع باحال! 🎉)داده‌ها رو Sharding می‌کنه و تو چندتا نود پخش می‌شه.اما مدیریت و راه‌اندازی یه کم دردسر داره.۴. مدل Sentinel (ناظر وفادار! 👀)یه سیستم نظارت خودکار که Master رو پایش می‌کنه و اگه مرد، سریعاً یه Slave رو جایگزین می‌کنه.نیازی نیست دستی مداخله کنیم، و خب، فوق‌العاده برای High Availability! سوال بزرگ: Redis Sentinel چگونه کار می‌کند؟جناب Redis Sentinel از سه مؤلفه اصلی تشکیل شده است: ‏Monitoring: به‌صورت مداوم Master و Replicaها را بررسی می‌کند تا اطمینان حاصل شود که سالم هستند.‏Notification: اگر مشکل یا خرابی‌ای تشخیص دهد، می‌تواند به ادمین اطلاع دهد.‏Automatic Failover: اگر Master از دسترس خارج شود، یکی از Replicaها را به Master تبدیل کرده و سایر Replicaها را به آن متصل می‌کند.مکانیزم Failover در Sentinel به این شکل است:‏Sentinelها به‌صورت quorum (یکم پایینتر توضیح میدم چیه) تصمیم می‌گیرند که Master خراب شده است.پس از تایید خرابی، یک Sentinel به عنوان Leader انتخاب می‌شود.‏Leader یک Replica را به عنوان Master جدید معرفی کرده و سایر نودها را مجدداً پیکربندی می‌کند.کلاینت‌ها با استفاده از Sentinelها، اطلاعات به‌روزرسانی‌شده Master جدید را دریافت می‌کنند.این یعنی نیازی به مداخله دستی نیست و همه‌چیز خودکار مدیریت می‌شود!حالا Quorum چیست و چرا مهم است؟در سیستم Sentinel، چندین نود وظیفه بررسی Master را دارند. برای اینکه Failover اتفاق بیافتد، حداقل n/2+1 از Sentinelها باید تأیید کنند که Master واقعاً از کار افتاده است. این مکانیزم که Quorum نام دارد، جلوی Failoverهای اشتباه را می‌گیرد و باعث ثبات در سیستم می‌شود.‏مزایای Redis Sentinel چیه؟‏✅ Failover اتوماتیک: اگه Master بمیره، خودش یه Slave رو ارتقا می‌ده.‏✅ Load Balancing برای Read: کلاینت می‌تونه به چند تا Replica متصل بشه و فشار کم بشه.‏✅ Monitoring &amp; Notification: اگه Redis یه مشکلی پیدا کنه، بهت اطلاع می‌ده. ✅ بدون نیاز به کلاینت خاص: همون کلاینت Redis معمولی کار می‌کنه. ‏✅ Self-healing: به‌صورت خودکار شبکه رو تنظیم می‌کنه.‏مشکلاتی که Sentinel حل می‌کنه‏🚀 دستکاری دستی در مواقع خرابی: دیگه لازم نیست خودمون نگران Failover باشیم. ‏🛑 Single Point of Failure: بدون Sentinel اگه Master بمیره، کلی مشکل داریم. 📈 افزایش عملکرد: درخواست‌های Read بین Replicaها پخش می‌شه. ⚠️ کاهش ریسک Data Loss: به دلیل مدیریت خودکار Failover.انتخاب Master توی Redis Sentinel، یه جور انتخابات هوشمندانه! 🎭وقتی Master بی‌خبر غیبش می‌زنه، Sentinelها دور هم جمع می‌شن و یه تصمیم مهم می‌گیرن: کی بشه Master بعدی؟! 🤔۱. تشخیص مرگ Master 😵‏Sentinelها همیشه حواسشون به Master هست. هر چند ثانیه یه پینگ می‌فرستن و منتظر جواب می‌شن. اگه چندتا Sentinel ببینن که دیگه Master جواب نمی‌ده، می‌گن: «خب، به‌نظر می‌رسه که کارش تمومه!». 😬 اما این کافی نیست!باید حداقل نصف Sentinelها + ۱ تا، نظرشون این باشه که Master واقعاً غیبش زده (به این می‌گن Quorum).اگه Quorum تأیید کنه که Master از دنیا رفته، می‌ره توی ODOWN (Objectively Down) و پروژه انتخاب جایگزین شروع می‌شه.۲. انتخاب یه Sentinel به عنوان رئیس جمهور! 🤴وقتی Master از دسترس خارج می‌شه، Sentinelها رأی‌گیری می‌کنن تا یکی‌شون نقش لیدر رو بگیره و هدایت Failover رو به دست بگیره.این رأی‌گیری یه جورایی مثل انتخابات کلاس درسه! هر Sentinel تلاش می‌کنه رأی بگیره.هرکی رأی اکثریت رو بیاره، می‌شه Leader و بقیه ازش تبعیت می‌کنن. 😎اگه هیچ‌کس رأی نیاره؟ رأی‌گیری دوباره انجام می‌شه تا یکی بالاخره انتخاب بشه.۳. تعیین جانشین (Replica جدید برای Master شدن!) 👑خب، حالا که رئیس انتخاب شد، باید یه Master جدید پیدا کنه. ولی هر Replica‌ای مناسب این کار نیست! Sentinel چند تا چیزو چک می‌کنه:آخرین داده‌ها: کدوم Replica به‌روزتره؟در دسترس بودن: کدومش جواب می‌ده؟اولویت (priority): اگه تو تنظیمات یه Replica بالاتر باشه، شانسش بیشتره.‏Latency: هرچی سریع‌تر باشه، بهتره.بعد از کلی بررسی، یه Replica انتخاب می‌شه و با اجرای SLAVEOF NO ONE تبدیل به Master جدید می‌شه. 🎉۴. اعلام رسمی تغییرات! 📢حالا که Master جدید انتخاب شد، وقتشه که به کلاینت‌ها و سایر نودها بگه: «هی بچه‌ها! این رئیس جدیدتونه!»‏Sentinel اطلاعات رو آپدیت می‌کنه.‏Replicaهای دیگه به Master جدید متصل می‌شن.کلاینت‌ها هم بعد از یه مدت کوتاه خودشون به Master جدید وصل می‌شن.۵. نظارت مداوم روی Master جدید 👀‏Sentinelها همچنان کارشون رو ادامه می‌دن و اگه Master جدید هم یه وقت غیبش زد، دوباره همین پروسه رو انجام می‌دن.جمع‌بندی Failover توی Redis Sentinel‏✅ Sentinelها دائماً Master رو چک می‌کنن.✅ اگه Master بمیره، رأی‌گیری می‌شه و یه Sentinel لیدر می‌شه.✅ لیدر یه Replica رو انتخاب و به Master جدید تبدیل می‌کنه.✅ کلاینت‌ها و Replicaهای دیگه آپدیت می‌شن.✅ ‏Sentinel همچنان روی Master جدید نظارت داره.و اینجوری Redis Sentinel بدون نیاز به دخالت دستی، یه سیستم همیشه در دسترس رو مدیریت می‌کنه! 😎🚀اتصال کلاینت به Redis Sentinel‏نمونه کد در Pythonimport redis
sentinels = [(&amp;quotredis-sentinel-0&amp;quot, 26379), (&amp;quotredis-sentinel-1&amp;quot, 26379), (&amp;quotredis-sentinel-2&amp;quot, 26379)]
rs = redis.sentinel.Sentinel(sentinels, socket_timeout=0.1)
master = rs.master_for(&amp;quotmymaster&amp;quot, socket_timeout=0.1)
slave = rs.slave_for(&amp;quotmymaster&amp;quot, socket_timeout=0.1)
master.set(&amp;quotkey&amp;quot, &amp;quotvalue&amp;quot)
print(slave.get(&amp;quotkey&amp;quot))‏نمونه کد در Golangpackage main
import (
    &amp;quotfmt&amp;quot
    &amp;quotgithub.com/go-redis/redis/v8&amp;quot
    &amp;quotcontext&amp;quot
)

var ctx = context.Background()
func main() {
    sentinel := redis.NewFailoverClient(&amp;redis.FailoverOptions{
        MasterName:    &amp;quotmymaster&amp;quot,
        SentinelAddrs: []string{&amp;quotredis-sentinel-0:26379&amp;quot, &amp;quotredis-sentinel-1:26379&amp;quot, &amp;quotredis-sentinel-2:26379&amp;quot},
    })
err := sentinel.Set(ctx, &amp;quotkey&amp;quot, &amp;quotvalue&amp;quot, 0).Err()
    if err != nil {
        panic(err)
    }
val, err := sentinel.Get(ctx, &amp;quotkey&amp;quot).Result()
    if err != nil {
        panic(err)
    }
fmt.Println(&amp;quotValue:&amp;quot, val)
}‏راه‌اندازی Redis Sentinel روی Kubernetes با Helmخب، بریم سر اصل مطلب و یه Helm Chart برای Redis Sentinel روی Kubernetes دپلوی کنیم.یه Helm Chart مخصوص بسازیم.helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-redis bitnami/redis --set architecture=replication,sentinel.enabled=true‏۲. بررسی وضعیت پادهاkubectl get pods‏۳. دریافت اطلاعات Sentinelkubectl exec -it my-redis-master-0 -- redis-cli INFO SENTINEL‏‏مانیتورینگ Redis Sentinel با Prometheusخیلی راحت توی values.yml چارتتون تو قسمت podAnnotations دو تا پارامتر زیر رو اضافه کنید (البته این مدلی فقط در صورتی کار میکنه که روی کلاسترتون یه Prometheus داشته باشید تا بتونه متریکای پاداتون رو Scrape کنه. اینم بعدا حس و حالش باشه مقالشو مینویسم براتون):podAnnotations:
    prometheus.io/scrape: &amp;quottrue&amp;quot
    prometheus.io/port: &amp;quot9121&amp;quotچندتا از متریک هایی که بهمون میده:‏- redis_master_last_io_seconds_ago : مدت زمان (به ثانیه) از آخرین ارتباط موفق بین مستر و یک رپلیکا.   
- redis_commands_processed_total : تعداد کل دستورات پردازش‌شده  .   
- redis_connected_slave_lag_seconds : لگ (به ثانیه) بین مستر و  رپلیکا.  
 - redis_connected_clients :  تعداد کلاینت‌های متصل در حال حاضر به ردیس.
 - redis_db_keys_expiring : تعداد کلیدهایی که در تمام دیتابیس‌های دارای تاریخ انقضا هستند.   
- redis_db_keys : تعداد کل کلیدهای ذخیره‌شده در تمام دیتابیس‌های.‏در قدم آخر میتونید یه dashboard باحال توی گرافانا براش درست کنید:برید از اینجا داشبورد رو import کنید و حالشو ببرید.نتیجه‌گیریحالا ما یه سیستم Redis Sentinel داریم که روی Kubernetes اجرا می‌شه و با GitLab CI/CD میتونیم پروسه دپلوی رو خودکار کنیم. تازه داریم با Prometheus و Grafana هم مانیتورش میکنیم.این یعنی دردسر کمتر، آرامش بیشتر! 😌🔥اگه تا اینجا اومدی، حتماً توی کامنتا نظرتو بگو! 😃</description>
                <category>امیرحسین حاجی محمدی</category>
                <author>امیرحسین حاجی محمدی</author>
                <pubDate>Tue, 11 Feb 2025 17:18:32 +0330</pubDate>
            </item>
                    <item>
                <title>داستان مهاجرت ما از PostgreSQL 9.6 به 17 با pglogical: هم کمتر خوابیدیم، هم بیشتر یاد گرفتیم!</title>
                <link>https://virgool.io/SnappTripBlog/%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%D9%85%D8%A7-%D8%A7%D8%B2-postgresql-96-%D8%A8%D9%87-17-%D8%A8%D8%A7-pglogical-%D9%87%D9%85-%DA%A9%D9%85%D8%AA%D8%B1-%D8%AE%D9%88%D8%A7%D8%A8%DB%8C%D8%AF%DB%8C%D9%85-%D9%87%D9%85-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-%DB%8C%D8%A7%D8%AF-%DA%AF%D8%B1%D9%81%D8%AA%DB%8C%D9%85-neruo9zeu9bx</link>
                <description>۱. داستان از کجا شروع شد؟فکر کنید یک دیتابیس غول‌آسا دارید روی PostgreSQL 9.6 (که دیگه آخرای عمرشه!)، با جدول‌هایی که بعضی‌هاشون ۴۰، ۶۰ گیگ و حتی بیشتر حجم دارن. بعد می‌خواید علاوه بر ارتقا به نسخه‌ی ۱۷، اوبونتوی تازه ۲۴.۰۴ رو هم تست کنید. هدف: ارتقا با کمترین قطعی ممکن (Near-zero downtime)!سرور قدیمی: PostgreSQL 9.6، آی‌پی: 10.10.10.50، دیتابیس: acme_dbسرور جدید: اوبونتو ۲۴.۰۴ با PostgreSQL 17، آی‌پی: 10.10.10.60می‌شد با pg_upgrade سریع ارتقا داد، ولی Downtime داشت، و ما می‌خواستیم دیتابیس تا حد امکان بالا بمونه. همچنین نیاز داشتیم دیتابیس رو روی یه سرور جدید بیاریم. به این نتیجه رسیدیم که از pglogical (Logical Replication) استفاده کنیم تا انتقال داده به صورت زنده انجام بشه و در نهایت با یک لحظه‌ی کوتاه Cutover، دیتابیس رو سوئیچ کنیم.۲. چرا pglogical؟کمترین downtime ممکن: نمیخواستیم دیتابیس ساعت ها down باشه و سرویس و business دچار مشکل بشن. ارتقا بین نسخه‌های دور (9.6 به 17): استریم رپلیکیشن عادی این فاصله رو پشتیبانی نمی‌کنه. pglogical گفت: «من هستم!» سرور و سیستم‌عامل جدید: قصد داشتیم تمام مراحل روی یک VM تر و تمیز در اوبونتوی ۲۴.۰۴ اجرا بشه.۳. آماده‌سازی اولیهروی سرور ۹.۶، به‌دلیل پایان عمر، لازم بود pglogical رو از سورس کامپایل کنیم (یا از مخازن قدیمی در دسترس).در postgresql.conf سرور قدیمی (۱۰.۱۰.۱۰.۵۰):wal_level = logical
max_wal_senders = 10
max_replication_slots = 10در pg_hba.conf هم دسترسی به آی‌پی سرور جدید رو باز گذاشتیم.یک کاربر رپلیکیشن با SUPERUSER ساختیم:CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD &#039;secret_password&#039;;ری‌استارت PostgreSQL 9.6 تا تغییرات اعمال بشه.روی سرور جدید (۱۰.۱۰.۱۰.۶۰) هم PostgreSQL 17 رو نصب کردیم و ماژول pglogical رو اضافه کردیم. دیتابیسی به نام acme_db ساختیم تا آماده‌ی ایمپورت باشه.۴. نقشه کلی مهاجرت با pglogical۱. گرفتن dump فقط اسکیما (schema-only) از سرور قدیمی و ری‌استور روی سرور جدید تا ساختار جداول و ایندکس‌ها یکسان بشه.۲. کپی دستی جداول خیلی بزرگ (مثلاً ۶۰ گیگ) با --data-only پیش از اینکه pglogical کپی کنه (اصطلاحاً Pre-copy). اینجوری اگر خطایی وسط کار پیش بیاد، مجبور به کپی دوباره‌ی حجم عظیم نخواهیم شد.۳. بقیه جداول کوچک/متوسط رو می‌گذاریم pglogical خودش سینک کنه.۴. جداول بزرگ در Replication Set با synchronize_data = false اضافه می‌شن، تا فقط تغییرات جدید رو دریافت کنن، نه کپی اولیه حجیم.۵. بعد از کامل‌شدن همگام‌سازی، Cutover می‌کنیم: یک لحظه اپلیکیشن رو از سرور قدیمی به سرور جدید وصل می‌کنیم.۵. مراحل قدم‌به‌قدم۵.۱. دامپ schema-only و restore# on old server
pg_dump -h 10.10.10.50 -U repuser -s -d acme_db &gt; acme_db_schema.sql

# on new server
psql -h 10.10.10.60 -U repuser -d acme_db -f acme_db_schema.sqlحالا ساختار جدول‌ها، ایندکس‌ها و کانسترینت‌ها در دو سرور یکسان می‌شود.۵.۲. جدوال بزرگ رو pre-copy میکنیممثلاً جدول orders (~۶۰ گیگ):# only-data dump
pg_dump -h 10.10.10.50 -U repuser -d acme_db --data-only -t public.orders &gt; orders_data.sql

# restore on new server
psql -h 10.10.10.60 -U repuser -d acme_db -f orders_data.sqlاگر کلیدهای خارجی دارید، حتماً داده‌ی جدول والد زودتر بارگذاری شود تا خطا نگیره. این کار رو برای هر جدول حجیم تکرار کنید.۵.۳. تنظیم pglogical در سرور قدیمی (Provider)CREATE EXTENSION pglogical;

SELECT pglogical.create_node(
  node_name := &#039;acme_provider&#039;,
  dsn       := &#039;host=10.10.10.50 dbname=acme_db user=repuser password=secret_password&#039;
);۵.۴. انتخاب جداول برای Replication Set# Add all tables by default
SELECT pglogical.replication_set_add_all_tables(
  &#039;default&#039;, ARRAY[&#039;public&#039;], true
);

# Remove pre-copied tables
SELECT pglogical.replication_set_remove_table(&#039;default&#039;,&#039;public.orders&#039;);
...

# Add gain but with synchronization=false
SELECT pglogical.replication_set_add_table(
 &#039;default&#039;,
  &#039;public.orders&#039;,
  false
);
...۵.۵. تنظیم pglogical در سرور جدید (Subscriber)CREATE EXTENSION pglogical;

SELECT pglogical.create_node(
  node_name := &#039;acme_subscriber&#039;,
 dsn       := &#039;host=10.10.10.60 dbname=acme_db user=repuser password=secret_password&#039;
);۵.۶. ساخت SubscriptionSELECT pglogical.create_subscription(
 subscription_name := &#039;acme_sub&#039;,
  provider_dsn      := &#039;host=10.10.10.50 dbname=acme_db user=repuser password=secret_password&#039;,
 replication_sets  := ARRAY[&#039;default&#039;],
  synchronize_data  := true
);جداول کوچک به طور کامل کپی می‌شوند؛ جداول بزرگ که قبلاً بارگذاری کردید، فقط تغییرات جدید را می‌گیرند.۵.۷. مانیتور کردن و بررسیSELECT * FROM pglogical.show_subscription_status();اگر status شد replicating، عالی است. اگر down شد، لاگ‌ها را ببینید. حواستان به wal_keep_size باشد که کم نباشد (وگرنه وسط کار لاگ پاک می‌شود).۵.۸. نهایی‌کردن (Cutover)1. در یک لحظه کوتاه، اپلیکیشن را یا متوقف یا به حالت Maintenance ببرید. 2. اجازه دهید چند ثانیه آخرین WALها منتقل شوند. 3. آدرس اتصال اپلیکیشن را عوض کنید به سرور ۱۰.۱۰.۱۰.۶۰ (نسخه ۱۷).4. کار تمام است!۶. مشکلاتی که خوردیم و درس‌هایی که گرفتیم مشکل Foreign Keyها و خالی ماندن جداولاگر جدول فرزند پیش از جدول والد لود شود، خطای FK می‌دهد و آن جدول فرزند خالی می‌ماند.راهکار: ترتیب صحیح لود داده، یا غیرفعال‌کردن موقت کانسترینت.۲. مشکل“relation already exists”اگر اسکیما قبلاً وجود داشته باشد و فایل دامپ شما شامل CREATE TABLE باشد، خطا می‌دهد.راهکار: --data-only برای جداولی که اسکیماشان هست.3. جداول بزرگ و سرعتدامپ متنی تکی ممکن است کند باشد؛ ما از فرمت Directory + pg_restore -j 4 برای کارهای موازی سود بردیم.اگر ایندکس‌های سنگین دارید، می‌توانید اول بدون ایندکس لود کنید و بعد ایندکس را بسازید.4. مشکل WAL retentionهمگام‌سازی ممکن است ساعت‌ها طول بکشد؛ بنابراین wal_keep_size و فضای دیسک را کم نگذارید.اگر WAL زود پاک شود، Subscription وسط راه می‌شکند.5. مشکل Subscription downاغلب به‌خاطر اختلاف اسکیما، FK ناقص، یا اتصال ناکافی است. خطا را برطرف کنید و اگر لازم شد، Subscription را drop/recreate کنید.۷. مشکلات مربوط به Sequence در حین Cutoverیکی از چالش‌های مهمی که ما تجربه کردیم، نابرابری Sequenceها پس از Cutover بود. در PostgreSQL، Sequence وظیفه‌ی تولید ID (مثلاً برای ستون‌های SERIAL/BIGSERIAL) را دارد. اگر شما با pglogical یا Dump/Restore داده‌ها را منتقل کنید، احتمالاً مقادیر واقعی ID در جداول از مقدار Sequence جلوتر یا عقب‌تر باشد. نتیجه؟ممکن است بعد از Cutover، Insertهای جدید خطای duplicate key بدهند؛ چراکه Sequence عددی را ارائه می‌دهد که قبلاً در جدول وجود دارد.راه‌حل:۱. جستجو و شناسایی Sequenceها:می‌توانید با کوئری زیر، همه‌ی جداول و ستون‌هایشان که وابسته به Sequence هستند را پیدا کنید:SELECT
    t.relname AS table_name,
    a.attname AS column_name,
    s.relname AS sequence_name
    FROM pg_class s
    JOIN pg_depend d  ON d.objid = s.oid
    JOIN pg_class t   ON d.refobjid = t.oid
    JOIN pg_attribute a
    ON a.attrelid = t.oid
    AND d.refobjsubid = a.attnum
    WHERE s.relkind = &#039;S&#039;
    AND t.relkind IN (&#039;r&#039;,&#039;p&#039;)
    AND d.deptype = &#039;a&#039;
    ORDER BY t.relname;2. تنظیم مجدد Sequence (setval):برای هر سکانس، با SELECT max(id) از جدول مرتبطش، مقدار نهایی ID را به‌دست آورده و آن را یک واحد افزایش دهید. مثل:SELECT setval(&#039;some_table_id_seq&#039;, (SELECT COALESCE(MAX(id), 0) FROM some_table) + 1, false);اگر جداول زیاد هستند، می‌توانید این را در یک بلوک DO $$ ... $$ پیاده کنید که همه را به‌صورت خودکار انجام دهد.3. انجام این کار قبل از شروع Insertهای جدید:درست بعد از Cutover و قبل از اینکه اپلیکیشن روی سرور جدید Insert بزند، Sequenceها را یکسان‌سازی کنید.به این ترتیب، Sequence ها به حداکثر مقدار موجود در جدول +۱ تنظیم می‌شوند و دیگر خطای Duplicate نخواهید داشت.۸. چند توصیه‌ی طلایی (Best Practices)1. در محیط تست تمرین کنید. با دیتای کوچک، چالش‌های FK و Sequence را در محیط آزمایشی کشف کنید.2. جداول خیلی بزرگ را جداگانه یا در Subscription های جدایا کلاً دستی Pre-copy کنید تا اگر مشکلی شود، از صفر مجبور نباشید ۶۰ گیگ داده بکشید.3. لاگ‌ها را جدی بگیریداگر Subscription به down رفت، سریع لاگ سرور قدیمی و جدید را بررسی کنید.4. ایندکس‌ها و Constraintsدر صورت نیاز، برای سرعت بیشتر ابتدا بدون آن‌ها لود کنید و سپس بسازید/فعال کنید.5. همگام سازی و Sequence Syncبعد از پایان انتقال داده، Sequenceها را با setval یکسان کنید تا با MAX(id)+1 همخوانی داشته باشند.۹. جمع‌بندیبه کمک این رویکرد توانستیم دیتابیس ۹.۶ را تقریباً بدون Downtime به نسخه ۱۷ ببریم و همزمان یک سرور Ubuntu 24.04 جدید راه بیندازیم. چالش عمده شامل FKها، WAL retention و مخصوصاً Sequenceها بود. در نهایت با Pre-copy جداول بزرگ، مدیریت درست FKها و تنظیم Sequenceها، مهاجرت با موفقیت و کمترین اختلال انجام شد.امیدواریم این تجربه که قدم‌ به‌قدم و عملی بیان شد، بتواند برای دیگران هم مفید باشد و در ارتقاهای بعدی، کابوسی به نام “از صفر شروع‌کردن” یا “داون‌تایم طولانی” را از شما دور کند!</description>
                <category>امیرحسین حاجی محمدی</category>
                <author>امیرحسین حاجی محمدی</author>
                <pubDate>Mon, 03 Feb 2025 16:11:35 +0330</pubDate>
            </item>
            </channel>
</rss>