← شروع آموزش

WIUNIX ACADEMY

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

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

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

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

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

Debian 13بررسی‌شده با مستندات رسمی ·

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

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

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

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

قدم بعدی

اتصال آزمایشی با نقش محدود اپلیکیشن

روی A، رمز APP در ورودی مخفی وارد شود. این نقش محدود فقط کلیدهای academy:*، فرمان WAIT و بررسی سلامت و نقش را پوشش می‌دهد و الگوی عمومی همهٔ اپلیکیشن‌ها نیست. SET و WAIT باید در همین اتصال اجرا شوند.

Bash
sudo redis-cli --tls --cacert /etc/redis/tls/ca.pem --cert /etc/redis/tls/node.pem --key /etc/redis/tls/node.key -h 127.0.0.1 -p 6379 --user app --askpass
از کجا بدانم درست انجام شد؟

حساب اپلیکیشن بدون اختیار مدیریتی متصل است.

14

قدم بعدی

نوشتن نشانگر و بررسی دو نسخهٔ دریافت‌کننده

در همان نشست APP اجرا شود. پاسخ SET باید OK باشد و WAIT در پنج ثانیه عدد۲ بدهد. صفر یا یک یعنی بررسی تکثیر کامل نشده؛ در این حالت تمرین ادامه پیدا نکند. حتی عدد۲ هم تضمین اجماع یا ثبت پایدار نیست. این کلید فقط متعلق به آزمایش اختصاصی است.

Redis CLI
SET academy:probe before-failover
WAIT 2 5000
GET academy:probe
QUIT
خروجی نمونه
Illustrative successful output / نمونهٔ خروجی موفق:
OK
(integer) 2
"before-failover"
از کجا بدانم درست انجام شد؟

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

15

قدم بعدی

خواندن داده در مقصد و اثبات رد نوشتن

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

Redis CLI
GET academy:probe
SET academy:probe forbidden-write
QUIT
از کجا بدانم درست انجام شد؟

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

16

قدم بعدی

روشن‌کردن رأی‌دهنده‌ها به‌ترتیب

ابتدا A، سپس B و بعد C اجرا شوند. بین افزودن هر رأی‌دهنده۳۰ ثانیه فاصله و بررسی لاگ باشد تا کشف همتاها انجام شود. این فاصله وعدهٔ زمان بازیابی نیست و به واحد سرویس تازه نیاز ندارد.

Bash
sudo systemctl enable --now redis-sentinel
sudo systemctl status redis-sentinel --no-pager
sleep 30
sudo tail -n 40 /var/log/redis/redis-sentinel.log
از کجا بدانم درست انجام شد؟

سه رأی‌دهنده همدیگر را بدون خطای احراز هویت یا بازنویسی پیدا می‌کنند.

17

قدم بعدی

ورود محلی برای بررسی Sentinel

روی هر سرور با رمز ADMIN وارد شوید. پنل بعد فقط بررسی وضعیت است. نقش محدود کشف سرویس در بخش جدا امتحان می‌شود.

Bash
sudo redis-cli --tls --cacert /etc/redis/tls/ca.pem --cert /etc/redis/tls/node.pem --key /etc/redis/tls/node.key -h 127.0.0.1 -p 26379 --user admin --askpass
از کجا بدانم درست انجام شد؟

Sentinel محلی نشست نگهداری TLS را می‌پذیرد.

18

قدم بعدی

پیش از تمرین خرابی، توپولوژی کامل باشد

روی هر سه Sentinel اجرا شود. CKQUORUM باید OK بدهد. در MASTER حد نصاب۲، دو همتای دیگر، دو نسخهٔ دریافت‌کننده و نبود پرچم خرابی یا قطع اتصال لازم است. REPLICAS باید B و C را با اتصال سالم و اولویت قابل انتخاب نشان دهد. MYID سه رأی‌دهنده متفاوت باشد. کم‌کردن حد نصاب برای عبور از بررسی راه‌حل نیست.

Sentinel CLI
SENTINEL MYID
SENTINEL CKQUORUM academy
SENTINEL MASTER academy
SENTINEL REPLICAS academy
SENTINEL SENTINELS academy
QUIT
از کجا بدانم درست انجام شد؟

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

19

قدم بعدی

پیداکردن نویسنده با حساب کشف سرویس

روی میزبان مجاز کلاینت، گواهی مستقل همان کلاینت و CA در مسیرهای زیر قرار داشته باشد. رمز DISCOVERY با APP متفاوت است. کتابخانهٔ واقعی اپلیکیشن باید هر سه نشانی اولیه را بشناسد، مقصد برگشتی را با ROLE بررسی کند و پس از تغییر نقش دوباره مقصد را پیدا کند. IP ثابت اولیه، توزیع سادهٔ TCP یا یک رکورد DNS به‌تنهایی پشتیبانی Sentinel نیست.

Bash
redis-cli --tls --cacert /etc/academy-client/ca.pem --cert /etc/academy-client/client.pem --key /etc/academy-client/client.key -h 10.20.0.11 -p 26379 --user discovery --askpass
از کجا بدانم درست انجام شد؟

نشست محدود کشف سرویس از شبکهٔ مجاز باز می‌شود.

20

قدم بعدی

دریافت نشانی و کنترل محدودیت حساب

در نشست DISCOVERY، پیش از جابه‌جایی نشانی A و پورت۶۳۷۹ برمی‌گردد. درخواست FAILOVER عمداً باید NOPERM بگیرد تا مشخص شود این حساب امکان ارتقا ندارد. برای حذف این خطای مورد انتظار، دسترسی اضافه نکنید.

Sentinel CLI
SENTINEL GET-MASTER-ADDR-BY-NAME academy
SENTINEL FAILOVER academy
QUIT
از کجا بدانم درست انجام شد؟

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

اتصال واقعی اپلیکیشن بخشی از دسترس‌پذیری است

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

21

قدم بعدی

تهیهٔ بکاپ بررسی‌شده از نویسندهٔ فعلی

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

Bash
sudo -i
از کجا بدانم درست انجام شد؟

شل محافظت‌شدهٔ ریشه روی نویسندهٔ فعلی باز است.

22

قدم بعدی

خروجی RDB و کنترل خوانایی بکاپ

در Bash ریشهٔ نویسندهٔ فعلی اجرا شود. رمز ADMIN فقط در ورودی مخفی داده شود. خطا زیرشل را متوقف می‌کند و پوشهٔ ناقصِ محافظت‌شده برای بررسی می‌ماند؛ در این حالت بازنشستگی یا بازیابی ادامه نیابد. هنگام تمام مراحل نوشتن متوقف باشد. ساختار مسیرها در آرشیو حفظ می‌شود.

Bash
(
set -euo pipefail
umask 077
install -d -m 0700 /root/academy-backups
backup=$(mktemp -d /root/academy-backups/redis-data-XXXXXXXX)
redis-cli --tls --cacert /etc/redis/tls/ca.pem --cert /etc/redis/tls/node.pem --key /etc/redis/tls/node.key -h 127.0.0.1 --user admin --askpass --raw GET academy:probe > "$backup/probe.txt"
case "$(cat "$backup/probe.txt")" in
  before-failover|after-failover) ;;
  *) echo "Unexpected lab marker: STOP" >&2; exit 1 ;;
esac
redis-cli --tls --cacert /etc/redis/tls/ca.pem --cert /etc/redis/tls/node.pem --key /etc/redis/tls/node.key -h 127.0.0.1 --user admin --askpass --rdb "$backup/dump.rdb"
test -s "$backup/dump.rdb"
redis-check-rdb "$backup/dump.rdb"
tar -C / -cpf "$backup/config.tar" etc/redis
tar -tf "$backup/config.tar" >/dev/null
tar -C / -df "$backup/config.tar"
cd "$backup"
sha256sum dump.rdb probe.txt config.tar > SHA256SUMS
sha256sum -c SHA256SUMS
printf 'Protected backup: %s\n' "$backup"
)
exit
از کجا بدانم درست انجام شد؟

RDB از بررسی ساختار و checksum می‌گذرد، آرشیو با منبع برابر است و هش فایل‌ها کنترل شده است.

23

قدم بعدی

بازیابی جداشده پیش از اتکا به بکاپ

پیش از تمرین جابه‌جایی، روی میزبان بازیابی جدا با همان نسخهٔ Redis و نسخهٔ محافظت‌شدهٔ بکاپ اجرا شود. مقدار backup باید مسیر واقعی باشد. پوشهٔ تازه و فضای نام شبکهٔ بدون پورت TCP به کار می‌رود و مسیر دادهٔ اصلی هرگز مقصد نیست. unshare به دسترسی ریشه نیاز دارد. تنظیمات قدیمی و اسرار را روی سامانهٔ روشن استخراج نکنید. برابری نشانگر فقط یک کنترل آزمایش است؛ بازیابی واقعی به بررسی کلیدهای نماینده، انقضا و قواعد اپلیکیشن نیاز دارد. AOF عمداً خاموش است تا RDB بازیابی‌شده بار شود.

Bash
sudo unshare --net --fork bash -eu <<'RESTORE'
umask 077
backup=/root/academy-backups/REPLACE_WITH_VERIFIED_BACKUP_DIRECTORY
cd "$backup"
sha256sum -c SHA256SUMS
redis-check-rdb dump.rdb
restore=$(mktemp -d /root/redis-restore-XXXXXXXX)
install -m 0600 dump.rdb "$restore/dump.rdb"
redis-server --bind 127.0.0.1 --port 0 --unixsocket "$restore/redis.sock" --unixsocketperm 600 --dir "$restore" --dbfilename dump.rdb --appendonly no --save '' --daemonize yes --pidfile "$restore/redis.pid" --logfile "$restore/redis.log"
trap 'redis-cli -s "$restore/redis.sock" SHUTDOWN NOSAVE >/dev/null || true' EXIT
for attempt in $(seq 1 30); do
  if test -S "$restore/redis.sock"; then break; fi
  sleep 1
done
actual=$(redis-cli -s "$restore/redis.sock" --raw GET academy:probe)
expected=$(cat "$backup/probe.txt")
test -n "$expected"
test "$actual" = "$expected"
redis-cli -s "$restore/redis.sock" DBSIZE
redis-cli -s "$restore/redis.sock" INFO persistence
printf 'Isolated marker restore passed; retained at %s\n' "$restore"
RESTORE
از کجا بدانم درست انجام شد؟

هش، بارگذاری RDB و برابری دقیق نشانگر موفق است؛ پردازش موقت خاموش و داده حفظ می‌شود. هر خطا اتکا به بکاپ را متوقف می‌کند.

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