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

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

sudo env MYSQL_HISTFILE=/dev/null mariadb

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

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/mariadb/tls/ca.pem',
  MASTER_SSL_VERIFY_SERVER_CERT=1,
  MASTER_CONNECT_RETRY=10;
START SLAVE;
SHOW SLAVE STATUS\G
EXIT;

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

sudo mariadb -e "SHOW SLAVE STATUS\G"
sudo mariadb -e "SELECT @@server_id,@@read_only,@@GLOBAL.gtid_slave_pos;"

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

sudo mariadb -e "SET GLOBAL read_only=OFF; INSERT INTO academy_lab.replication_probe VALUES (2,'after-seed'); SELECT @@GLOBAL.gtid_binlog_pos AS target_gtid; SELECT * FROM academy_lab.replication_probe ORDER BY id;"

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

SELECT MASTER_GTID_WAIT('REPLACE_WITH_ACTUAL_TARGET_GTID',30) AS wait_result;
SELECT id,note FROM academy_lab.replication_probe ORDER BY id;
SHOW SLAVE STATUS\G
EXIT;

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

sudo systemctl restart mariadb
systemctl is-active mariadb
sudo mariadb -e "SHOW SLAVE STATUS\G; SELECT @@read_only,@@GLOBAL.gtid_slave_pos; SELECT * FROM academy_lab.replication_probe ORDER BY id;"

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

sudo bash -eu <<'BACKUP'
umask 077
install -d -m 0700 /root/academy-backups
backup=$(mktemp -d /root/academy-backups/mariadb-XXXXXXXX)
mariadb-dump --single-transaction --quick --routines --events --triggers --databases academy_lab > "$backup/academy_lab.sql"
test -s "$backup/academy_lab.sql"
tar -C / -cpf "$backup/config-tls.tar" etc/mariadb/mariadb.conf.d/90-academy-replication.cnf etc/mariadb/tls
cd "$backup"
sha256sum academy_lab.sql config-tls.tar > SHA256SUMS
sha256sum -c SHA256SUMS
tar -tf config-tls.tar >/dev/null
tar -C / -df config-tls.tar
printf 'Retained backup: %s\n' "$backup"
BACKUP

برای توقف یا برگشت، خواندن برنامه را از رپلیکا جدا کنید و نویسندهٔ سالم را همان سرور اصلی نگه دارید. هیچ‌کدام را ارتقا ندهید. در فایل رپلیکا، گزینهٔ پنل بعدی را داخل گروه موجود اضافه کنید و read_only را روشن نگه دارید. توقف رشته به‌تنهایی پس از راه‌اندازی مجدد پایدار نیست.

sudo nano /etc/mariadb/mariadb.conf.d/90-academy-replication.cnf

فقط همین گزینه را داخل گروه موجود mariadb در فایل رپلیکا اضافه کنید؛ باقی فایل را جایگزین نکنید.

skip_slave_start=ON

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

(
set -euo pipefail
sudo mariadbd --verbose --help >/dev/null
sudo mariadb -e "SHOW SLAVE STATUS\G; STOP SLAVE; SHOW SLAVE STATUS\G; SELECT * FROM academy_lab.replication_probe ORDER BY id;"
)

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

sudo nano /etc/mariadb/mariadb.conf.d/90-academy-replication.cnf