← شروع آموزش

WIUNIX ACADEMY

آموزش نصب و راه‌اندازی رپلیکیشن MariaDB در اوبونتو و دبیان

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

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

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

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

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

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

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

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

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من3 مقدار قابل‌تغییر
17

قدم بعدی

انتقال فایل و هش از مسیر SSH

در پوستهٔ سرور اصلی با همان حساب مدیریتی dbadmin اجرا کنید. نوشتن از راه دور فایل قبلی را بازنویسی نمی‌کند. شکست خواندن یا SSH باعث توقف می‌شود. مجوز sudo خواندن فایل‌ها باید از قبل برقرار یا احراز هویت محلی آن انجام شده باشد. اثرانگشت میزبان SSH باید پیش‌تر از مسیر مطمئن بررسی شده باشد.

Bash

پوستهٔ اصلی با dbadmin

(
set -euo pipefail
sudo -v
sudo cat /root/academy-seed/seed.sql | ssh -l dbadmin 10.20.0.11 'umask 077; set -C; cat > "$HOME/academy-seed/seed.sql"'
sudo cat /root/academy-seed/SHA256SUMS | ssh -l dbadmin 10.20.0.11 'umask 077; set -C; cat > "$HOME/academy-seed/SHA256SUMS"'
)
از کجا بدانم درست انجام شد؟

هر دو انتقال SSH موفق و نسخهٔ اصلی محافظت‌شده حفظ شود.

18

قدم بعدی

تأیید هش و بازیابی روی رپلیکای تازه

در پوستهٔ رپلیکا با dbadmin اجرا کنید. وجود دیتابیس مقصد، جدول کاربر دیگر، کانال تکثیر یا GTID اعمال‌شده باعث توقف می‌شود و چیزی پاک نمی‌شود. ابتدا هش بررسی می‌شود. ثبت باینری‌لاگ فقط در نشست بازیابی غیرفعال است تا ورود اولیه یک تاریخچهٔ رقیب نسازد؛ وضعیت فقط‌خواندنی سراسری روشن می‌ماند. خطای ورود داده را با force یا اجرای دوباره روی دادهٔ نیمه‌کاره دور نزنید.

Bash

رپلیکا

(
set -euo pipefail
cd "$HOME/academy-seed"
sha256sum -c SHA256SUMS
test "$(sudo mariadb -NBe "SELECT COUNT(*) FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='academy_lab';")" = 0
test "$(sudo mariadb -NBe "SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys');")" = 0
channels=$(sudo mariadb -NBe 'SHOW SLAVE STATUS;')
test -z "$channels"
applied=$(sudo mariadb -NBe 'SELECT @@GLOBAL.gtid_slave_pos;')
test -z "$applied"
{ printf 'SET SESSION sql_log_bin=0;\n'; cat seed.sql; } | sudo mariadb
sudo mariadb -e 'SELECT @@read_only; SELECT * FROM academy_lab.replication_probe;'
)
از کجا بدانم درست انجام شد؟

هش و کنترل خالی‌بودن موفق؛ ردیف1 با متن consistent-seed و read_only برابر1 دیده شود.

19

قدم بعدی

تنظیم GTID ثبت‌شده در همان نسخهٔ داده

روی رپلیکا اجرا کنید. تنها خط GTID همان خروجی استخراج می‌شود و اگر تعداد یا قالب آن درست نباشد، کار متوقف خواهد شد. دامنه باید صفر، شناسهٔ مبدأ101 و شمارهٔ توالی مثبت باشد. از current_pos، موقعیت حدسی یا GTID جدیدتر سرور اصلی استفاده نکنید. این کنترل برای جریان تک‌دامنهٔ همین آزمایش است؛ تاریخچهٔ چندمبدأ به برنامهٔ جدا نیاز دارد.

Bash

رپلیکا

(
set -euo pipefail
cd "$HOME/academy-seed"
sha256sum -c SHA256SUMS
position=$(sed -n "s/^-- SET GLOBAL gtid_slave_pos='\(0-101-[1-9][0-9]*\)';$/\1/p" seed.sql)
if [[ ! "$position" =~ ^0-101-[1-9][0-9]*$ ]]; then
  echo 'Missing, multiple or unexpected snapshot GTID; STOP' >&2; exit 1
fi
printf "SET GLOBAL gtid_slave_pos='%s';\n" "$position" | sudo mariadb
sudo mariadb -NBe 'SELECT @@GLOBAL.gtid_slave_pos;'
)
از کجا بدانم درست انجام شد؟

موقعیت gtid_slave_pos رپلیکا دقیقاً با تنها GTID داخل نسخهٔ تأییدشده یکسان باشد.

20

قدم بعدی

ورود به نشست امن SQL رپلیکا

در ترمینال رپلیکا نشست بدون تاریخچه باز کنید. همان رمز یکتایی که برای حساب اصلی ساخته شد لازم است. عبارت اتصال حاوی رمز نباید به آرگومان پوسته، فایل عمومی یا خروجی منتشرشده تبدیل شود.

Bash

ترمینال رپلیکا

sudo env MYSQL_HISTFILE=/dev/null mariadb
از کجا بدانم درست انجام شد؟

نشست مدیریتی محلی رپلیکا بدون ثبت تاریخچه باز شود.

21

قدم بعدی

اتصال تکثیر با GTID و TLS تأییدشده

داخل نشست SQL رپلیکا اجرا کنید. MariaDB برای سازگاری هنوز نام‌های MASTER و SLAVE را در این دستورها دارد. نام میزبان باید با SAN گواهی و DNS خصوصی تطابق داشته باشد. رمز را پیش از اجرا در نشست امن جایگزین کنید. حالت slave_pos ادامهٔ رویدادها پس از نسخهٔ بازیابی‌شده را می‌گیرد. اگر TLS خطا داد، علت را رفع کنید؛ تأیید گواهی نباید خاموش شود.

SQL

نشست SQL رپلیکا

CHANGE MASTER TO
  MASTER_HOST='db-primary.example.internal',
  MASTER_PORT=3306,
  MASTER_USER='academy_repl',
  MASTER_PASSWORD='REPLACE_WITH_THE_SAME_UNIQUE_SECRET',
  MASTER_USE_GTID=slave_pos,
  MASTER_SSL=1,
  MASTER_SSL_CA='/etc/mysql/tls/ca.pem',
  MASTER_SSL_VERIFY_SERVER_CERT=1,
  MASTER_CONNECT_RETRY=10;
START SLAVE;
SHOW SLAVE STATUS\G
EXIT;
از کجا بدانم درست انجام شد؟

دریافت و اجرا فعال؛ حالت Slave_Pos و TLS همراه با بررسی گواهی فعال باشد.

22

قدم بعدی

کنترل جداگانهٔ دریافت و اجرای رویداد

در رپلیکا هم دریافت‌کننده و هم اجراکننده باید Yes باشند؛ شمارهٔ خطای هر دو صفر و پیام خطا خالی باشد. شناسهٔ مبدأ101، حالت Slave_Pos و هر دو پرچم TLS را هم ببینید. صفرشدن تأخیر به‌تنهایی سلامت را ثابت نمی‌کند؛ NULL ممکن است از توقف رشته بیاید و یک منبع بیکار هم تصویر کاملی از عقب‌ماندگی نمی‌دهد. خروجی وضعیت شامل اطلاعات داخلی شبکه است.

Bash

رپلیکا

sudo mariadb -e "SHOW SLAVE STATUS\G"
sudo mariadb -e "SELECT @@server_id,@@read_only,@@GLOBAL.gtid_slave_pos;"
از کجا بدانم درست انجام شد؟

هر دو رشته Yes، خطاها صفر و خالی، مبدأ و GTID درست، تأیید TLS فعال و read_only برابر1 باشد.

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