← شروع آموزش

WIUNIX ACADEMY

آموزش نصب Redis Sentinel در اوبونتو و دبیان

صفحهٔ 4 از 4؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

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

Ubuntu 24.04 LTSبررسی‌شده با مستندات رسمی · 2026-10-20

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

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

ویرایش 5 مقدار این آموزش

تمرین خرابی فقط با قطع مسیر نویسندهٔ آزمایشی

پنل توقف و شروع فقط برای همین نمونه‌های اختصاصی و دورریختنی است، نه سرویس عملیاتی. نوشتن آزمایشی را متوقف و با کنترل شبکهٔ موجود آزمایشگاه، دسترسی همهٔ کلاینت‌ها به پورت دادهٔ A را قطع کنید؛ مسیر مدیر و Sentinel باقی بماند. خاموش‌کردن پردازش به‌تنهایی طرح حصارگذاری یک نویسندهٔ جداافتاده در محیط زنده نیست. ابتدا بکاپ و داده بررسی شوند. اگر A دیگر نویسندهٔ اعلام‌شده نیست، اینجا توقف کنید و بر اساس نقش واقعی تصمیم بگیرید. ارتقای دستی دو سرور یا راه‌اندازی با فایل قدیمی اولیه مجاز نیست.

24

قدم بعدی

شبیه‌سازی توقف نویسندهٔ آزمایشی

فقط در A و پس از تأیید نقش فعلی، رسیدن نشانگر به B و C و قطع مسیر کلاینت به A اجرا شود. Sentinel میزبان A روشن می‌ماند. این آزمون توقف سرویس است و خرابی فیزیکی میزبان یا استقلال دامنه‌های خرابی را ثابت نمی‌کند.

sudo systemctl stop redis-server
sudo systemctl is-active redis-server

از کجا بدانم درست انجام شد؟

سرویس دادهٔ آزمایش خاموش است؛ خروج غیرصفر is-active در این مرحله انتظار می‌رود و Sentinel فعال می‌ماند.

25

قدم بعدی

مشاهدهٔ انتخابات و مقصد جدید

در B و C با پنل ورود مدیریتی Sentinel وصل شوید. حداکثر۱۸۰ ثانیه وضعیت را مشاهده کنید: نشانی باید از A تغییر کند، CKQUORUM موفق باشد و رأی‌دهنده‌ها بر مقصد تازه توافق کنند. نبود ارتقا نیاز به عیب‌یابی دارد؛ کم‌کردن حد نصاب یا درخواست مکرر جابه‌جایی مناسب نیست. زمان به وضعیت واقعی اتصال و انتخابات بستگی دارد.

SENTINEL GET-MASTER-ADDR-BY-NAME academy
SENTINEL CKQUORUM academy
SENTINEL MASTER academy
QUIT

از کجا بدانم درست انجام شد؟

نقش، مقدار دقیق و پاسخ مشخص‌شده در توضیح همین مرحله بررسی شود؛ نتیجهٔ غیرمنتظره ادامهٔ کار را متوقف می‌کند.

26

قدم بعدی

اتصال به نویسندهٔ اعلام‌شده

در میزبان کلاینت، DISCOVERED_PRIMARY_IP با نشانی B یا C که همین حالا برگشته جایگزین شود. رمز APP در ورودی مخفی داده شود. پیش از اجازهٔ نوشتن با سیاست حداقل یک نسخه، سرور دادهٔ باقی‌مانده باید دریافت‌کنندهٔ نویسندهٔ تازه شده باشد. پنل بعد در همین اتصال اجرا شود.

redis-cli --tls --cacert /etc/academy-client/ca.pem --cert /etc/academy-client/client.pem --key /etc/academy-client/client.key -h DISCOVERED_PRIMARY_IP -p 6379 --user app --askpass

از کجا بدانم درست انجام شد؟

کلاینت مجاز از طریق TLS دوطرفه به مقصد کشف‌شده وصل است.

27

قدم بعدی

دادهٔ قبلی و نوشتن پس از جابه‌جایی

GET باید همان before-failover باشد. SET باید OK و WAIT عدد۱ بدهد؛ در غیر این صورت ادامه ندهید. مقدار تازه با ورود APP محلی روی نسخهٔ دریافت‌کنندهٔ باقی‌مانده هم خوانده شود. بررسی فقط روی نویسنده کافی نیست. گم‌شدن نشانگر نتیجهٔ ناموفق بازیابی است، نه مجوز بازنویسی داده.

ROLE
GET academy:probe
SET academy:probe after-failover
WAIT 1 5000
GET academy:probe
QUIT

از کجا بدانم درست انجام شد؟

نقش، مقدار دقیق و پاسخ مشخص‌شده در توضیح همین مرحله بررسی شود؛ نتیجهٔ غیرمنتظره ادامهٔ کار را متوقف می‌کند.

28

قدم بعدی

بازگشت سرور قبلی بدون برگرداندن توپولوژی قدیمی

فقط در A و در حالی که مسیر اپلیکیشن به آن بسته است اجرا شود. داده و تنظیمات فعلی حفظ شوند؛ Sentinel باید آن را دریافت‌کنندهٔ نویسندهٔ منتخب کند. ارتقای دستی، کپی فایل اولیه و بازکردن مسیر نوشتن هنگام همگرایی درست نیست. بازهمگام‌سازی می‌تواند دادهٔ متفاوت نویسندهٔ قبلی را جایگزین کند؛ در این تمرین A حصارگذاری شده و نوشتن مستقل ندارد. در حادثهٔ واقعی، ابتدا شواهد و دادهٔ آفلاین سرور متفاوت حفظ و تصمیم بازیابی گرفته شود.

sudo systemctl start redis-server
sudo systemctl status redis-server --no-pager
sudo tail -n 50 /var/log/redis/redis-sentinel.log

از کجا بدانم درست انجام شد؟

A روشن شده و دریافت‌کننده می‌شود؛ تا پایان بررسی نقش و داده، مسیر کلاینت بسته می‌ماند.

29

قدم بعدی

تأیید دریافت داده پس از بازگشت

در A با حساب ADMIN نقش دریافت‌کننده، نشانی نویسندهٔ تازه، اتصال up، پایان همگام‌سازی کامل و سلامت ذخیره‌سازی بررسی شود. GET با APP باید after-failover برگرداند و SET خطای READONLY بدهد. بررسی حد نصاب و توپولوژی روی همهٔ رأی‌دهنده‌ها تکرار شود. بازگشت اجباری فوری به نویسندهٔ قبلی لازم نیست. پس از این تأییدها، مسیریابی کلاینت و دسترسی خصوصی مصوب برقرار شود.

ROLE
INFO replication
INFO persistence
QUIT

از کجا بدانم درست انجام شد؟

نقش، مقدار دقیق و پاسخ مشخص‌شده در توضیح همین مرحله بررسی شود؛ نتیجهٔ غیرمنتظره ادامهٔ کار را متوقف می‌کند.

30

قدم بعدی

بازگشت امن با حفظ دادهٔ آزمایش

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

sudo systemctl disable --now redis-sentinel
sudo systemctl disable --now redis-server
sudo systemctl is-enabled redis-sentinel redis-server
sudo ss -lntp

از کجا بدانم درست انجام شد؟

دو سرویس اختصاصی خاموش و غیرفعال‌اند؛ خروج غیرصفر is-enabled انتظار می‌رود و داده و تنظیمات برای بازیابی باقی است.

عیب‌یابی با توجه به پیامد خطا

هر بررسی در میزبان و نشست مشخص خودش انجام شود. لاگ‌ها ممکن است توپولوژی خصوصی داشته باشند؛ فقط بخش بازبینی و پوشانده‌شده به اشتراک گذاشته شود. رد دسترسی مورد انتظار با شکست رأی‌دهی یا گم‌شدن داده تفاوت دارد.

سرویس روشن نمی‌شود

خطای واقعی واحد و فایل لاگ را بخوانید. مقدار نامعتبر ACL، IP محلی اشتباه، کلید غایب یا مجوز نادرست باید با پنل ویرایش قبلی اصلاح شود. پردازش دوم روی همان داده روشن نکنید و TLS را برای عبور از خطا خاموش نکنید.

sudo systemctl status redis-server redis-sentinel --no-pager
sudo journalctl -u redis-server -u redis-sentinel -n 60 --no-pager
sudo tail -n 60 /var/log/redis/redis-server.log /var/log/redis/redis-sentinel.log
ip -br address
sudo -u redis test -r /etc/redis/tls/node.key
sudo -u redis test -w /etc/redis/sentinel.conf

حد نصاب کامل نیست یا نسخه‌ها قطع‌اند

در نشست احراز هویت‌شدهٔ Sentinel، پنل وضعیت قبلی را اجرا کنید. نبود همتا می‌تواند از announce اشتباه، پورت۲۶۳۷۹ یا رمز PEER باشد. نبود دریافت‌کننده به پورت۶۳۷۹، ACL نقش REPL یا CONTROL و TLS مربوط می‌شود. هم فایل و هم پوشهٔ تنظیمات باید قابل بازنویسی باشند. دسترسی کانال داخلی فقط برای CONTROL بماند.

sudo ss -lntp
sudo tail -n 80 /var/log/redis/redis-sentinel.log
sudo -u redis test -w /etc/redis
sudo -u redis test -w /etc/redis/sentinel.conf

خطای NOREPLICAS یا READONLY و نشانگر گم‌شده

NOREPLICAS یعنی سیاست حداقل نسخه، نوشتن را رد کرده است؛ ابتدا وضعیت تکثیر نویسندهٔ فعلی را ببینید، نه اینکه حد را صفر کنید. READONLY در IP اولیه اغلب از تغییر موفق نقش و مقصد قدیمی کلاینت می‌آید. نبودن نشانگر یعنی بررسی داده شکست خورده؛ ترافیک را قطع و نمونه‌ها را برای بازیابی حفظ کنید. پس از ورود ADMIN، نشست زیر اجرا شود.

ROLE
INFO replication
INFO persistence
QUIT

خطای TLS یا تمدید گواهی

روی میزبان درگیر، اعتبار زمانی، زنجیره و خوانایی کلید با پنل PKI قبلی بررسی شود. IP پنل زیر با نشانی واقعی همان گواهی جایگزین شود. اعتبار CA به‌تنهایی تطبیق نام مقصد نیست. تمدید با هم‌پوشانی اعتماد و بررسی همهٔ مسیرهای TLS انجام شود؛ دورزدن اعتبارسنجی راه‌حل نیست. کلید خصوصی یا تنظیمات رمزدار در تیکت فرستاده نشود.

sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslserver -verify_ip 10.20.0.10 /etc/redis/tls/node.pem
sudo openssl x509 -in /etc/redis/tls/node.pem -checkend 604800 -noout
sudo -u redis test -r /etc/redis/tls/node.key

خطای دیسک یا AOF

فضای دیسک، inode و وضعیت واقعی ذخیره‌سازی را با نشست ADMIN قبلی بررسی کنید. بازنویسی AOF به فضای موقت دیسک و رم نیاز دارد. هنگام شکست ذخیره‌سازی ترافیک بیشتر وارد نکنید. حذف قطعه‌های AOF یا تعمیر تنها نسخهٔ موجود مجاز نیست. فایل‌ها حفظ و بکاپ در محیط جدا بازیابی شود تا تصمیم تعمیر بر شواهد تکیه کند.

df -h /var/lib/redis /var/log/redis
df -i /var/lib/redis
sudo tail -n 80 /var/log/redis/redis-server.log

پس از نصب، مسیر بازیابی را هم نگهداری کنید

تأخیر و offset تکثیر، تعداد نسخه‌ها، حد نصاب، جابه‌جایی‌ها، خطای ذخیره‌سازی، فضای آزاد، انقضای گواهی و خطای اتصال اپلیکیشن پایش شوند. هشدار باید پیش از رد نوشتن به‌علت کمبود نسخه برسد. گام بعد آزمون کتابخانهٔ واقعی، خرابی یک دامنهٔ مستقل و بازیابی بکاپ با دادهٔ نماینده است. اگر اتلاف نوشتن تأییدشده پذیرفتنی نیست، معماری اجماع یا پایگاه دادهٔ دیگری ارزیابی شود؛ Sentinel تضمین RPO صفر ندارد.

پشتوانهٔ این آموزش

منابع رسمی

وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.

ادامهٔ مسیر

قدم بعدی تو

همهٔ آموزش‌های آکادمی ↗