WIUNIX ACADEMY
آموزش نصب Redis Sentinel در اوبونتو و دبیان
صفحهٔ 7 از 7؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من5 مقدار قابل‌تغییر
قدم بعدی
دادهٔ قبلی و نوشتن پس از جابه‌جایی
GET باید همان before-failover باشد. SET باید OK و WAIT عدد۱ بدهد؛ در غیر این صورت ادامه ندهید. مقدار تازه با ورود APP محلی روی نسخهٔ دریافت‌کنندهٔ باقی‌مانده هم خوانده شود. بررسی فقط روی نویسنده کافی نیست. گم‌شدن نشانگر نتیجهٔ ناموفق بازیابی است، نه مجوز بازنویسی داده.
ROLE
GET academy:probe
SET academy:probe after-failover
WAIT 1 5000
GET academy:probe
QUIT
نقش، مقدار دقیق و پاسخ مشخص‌شده در توضیح همین مرحله بررسی شود؛ نتیجهٔ غیرمنتظره ادامهٔ کار را متوقف می‌کند.
قدم بعدی
بازگشت سرور قبلی بدون برگرداندن توپولوژی قدیمی
فقط در 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 روشن شده و دریافت‌کننده می‌شود؛ تا پایان بررسی نقش و داده، مسیر کلاینت بسته می‌ماند.
قدم بعدی
تأیید دریافت داده پس از بازگشت
در A با حساب ADMIN نقش دریافت‌کننده، نشانی نویسندهٔ تازه، اتصال up، پایان همگام‌سازی کامل و سلامت ذخیره‌سازی بررسی شود. GET با APP باید after-failover برگرداند و SET خطای READONLY بدهد. بررسی حد نصاب و توپولوژی روی همهٔ رأی‌دهنده‌ها تکرار شود. بازگشت اجباری فوری به نویسندهٔ قبلی لازم نیست. پس از این تأییدها، مسیریابی کلاینت و دسترسی خصوصی مصوب برقرار شود.
ROLE
INFO replication
INFO persistence
QUIT
نقش، مقدار دقیق و پاسخ مشخص‌شده در توضیح همین مرحله بررسی شود؛ نتیجهٔ غیرمنتظره ادامهٔ کار را متوقف می‌کند.
قدم بعدی
بازگشت امن با حفظ دادهٔ آزمایش
برای کنارگذاشتن آزمایش، ابتدا ترافیک اپلیکیشن از مسیر مدیریتی خودش قطع و همهٔ مقصدهای داده حصارگذاری شوند. بکاپ بررسی‌شده و شواهد بازیابی موفق جدا نگهداری شوند. سپس در سه میزبان سرویس‌ها با پنل زیر غیرفعال شوند. این توقف نگهداری است، نه روشی برای حفظ 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 صفر ندارد.
پشتوانهٔ این آموزش
منابع رسمی
وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.
- سیاست پشتیبانی امنیتی Redis
- یادداشت انتشار Redis متنباز
- مجوزهای Redis
- معماری و احراز هویت Sentinel
- تکثیر و محدودیت ناهمزمانی
- TLS کلاینت، تکثیر و Sentinel
- مرجع ACL در Redis
- ذخیره‌سازی و بکاپ Redis
- الزامات کلاینت Sentinel
- مرجع فرمان WAIT
- بستهٔ Redis اوبونتو۲۶٫۱۰
- بستهٔ Redis اوبونتو۲۶٫۰۴
- بستهٔ Redis اوبونتو۲۴٫۰۴
- بستهٔ Redis دبیان۱۳
- بستهٔ Redis دبیان۱۲
- وضعیت امنیتی Redis در دبیان
- پوشش امنیتی بستههای اوبونتو
ادامهٔ مسیر