آموزش راه‌اندازی Replication در MySQL

مقدمه

وقتی با پایگاه‌های داده کار می‌کنید، داشتن چند نسخه از داده‌هایتان می‌تواند مفید باشد. این کار در صورت خرابی یکی از سرورهای پایگاه داده، افزونگی (Redundancy) فراهم کرده و می‌تواند دسترس‌پذیری، مقیاس‌پذیری و کارایی کلی پایگاه داده را بهبود بدهد. روشِ همگام‌سازی داده در چندین پایگاه داده، Replication نامیده می‌شود.

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

این آموزش نحوه پیکربندی یک اینستنس MySQL روی یک سرور به‌عنوان پایگاه داده Source (منبع) و سپس پیکربندی یک اینستنس MySQL روی سروری دیگر را به‌عنوان Replica آن، تشریح می‌کند. همچنین شامل یک دید کلی از نحوه هندلِ Replication توسط MySQL است.

توجه: از نظر تاریخی، به این نوع Replication پایگاه داده، «master-slave» گفته می‌شد. در یک پست وبلاگی که در ژوئیه ۲۰۲۰ منتشر شد، تیم MySQL خاستگاه منفی این اصطلاحات را پذیرفت و تلاش‌های خود برای به‌روزرسانی برنامه پایگاه داده و مستنداتش برای استفاده از زبان فراگیرتر را اعلام کرد.

با این حال، این فرایندی در جریان است. اگرچه مستندات MySQL و بسیاری از دستورات نسخه ۸ این برنامه به‌روزرسانی شده‌اند تا به سرورهای موجود در یک توپولوژیِ Replication با عنوان Source و Replicaهای آن اشاره کنند، هنوز جاهایی هست که اصطلاحات قدیمی ظاهر می‌شوند. این راهنما تا جای ممکن از اصطلاحات فراگیرترِ Source-Replica استفاده می‌کند؛ اما چند مورد وجود دارد که اصطلاحات قدیمی به‌ناچار مطرح می‌شوند.

نکات کلیدی

• Replication در MySQL، داده‌ها را در چندین سرور پایگاه داده همگام می‌کند. این قابلیت به یک سرور MySQL (‏Source یا Primary) اجازه می‌دهد تغییرات داده را به‌طور خودکار به یک یا چند Replica بفرستد و افزونگی، دسترس‌پذیری و مقیاس‌پذیری را بهبود بدهد.
• Replication با استفاده از Binary Logها روی سرور Source کار می‌کند. هر تغییری که روی پایگاه داده Source ایجاد شود در Binary Log ثبت می‌شود؛ فایلی که سرورهای Replica آن را می‌خوانند و به‌صورت محلی اعمال می‌کنند تا داده‌هایشان با Source همگام بماند.
• سرورهای Replica پردازشِ Replication را با دو نخ (Thread) انجام می‌دهند. Replication از یک نخ IO برای واکشی رویدادهای Binary Log از Source و ذخیره آن‌ها در Relay Log استفاده می‌کند؛ و از یک نخ SQL برای اعمال آن رویدادها روی پایگاه داده Replica.
• هر سرور در یک راه‌اندازیِ Replication باید یک server-id یکتا داشته باشد. MySQL از پارامتر پیکربندی server-id برای تشخیص سرورهای شرکت‌کننده در Replication استفاده می‌کند و هر Source و Replica باید مقدار متفاوتی داشته باشد.
• Binary Logging باید روی سرور Source فعال باشد. Replication نیازمند فعال‌بودن Directive مربوط به log_bin است تا Source تغییرات پایگاه داده‌ای را که Replicaها می‌توانند بخوانند و دوباره اجرا کنند، ثبت کند.
• باید روی سرور Source یک کاربر اختصاصیِ Replication ساخته شود. سرورهای Replica با یک حساب کاربری MySQL مشخص — با دسترسی‌هایی مانند REPLICATION SLAVE — به Source متصل می‌شوند تا بتوانند داده‌های Replication را به‌صورت امن بخوانند.
• Replication می‌تواند با مختصات Binary Log راه‌اندازی اولیه شود. در Replication مبتنی بر موقعیت (Position)، ‏Replicaها باید نام فایل Binary Log و موقعیتی که Replication باید از آن شروع شود را بدانند؛ که با دستور SHOW BINARY LOG STATUS از Source به دست می‌آید.
• Replication بعد از پیکربندی همیشه باید تست و مانیتور شود. مدیران می‌توانند Replication را با SHOW REPLICA STATUS\G بررسی کنند؛ که جزئیات اتصال، وضعیت نخ‌های Replication و اطلاعات تأخیر (Lag) را نمایش می‌دهد تا تأیید شود Replica به‌درستی به‌روزرسانی‌ها را دریافت می‌کند.

پیش‌نیازها

برای تکمیل این راهنما به موارد زیر نیاز دارید:

• دو سرور در حال اجرای اوبونتو. هر دو باید یک کاربر مدیریتی غیر root با دسترسی sudo و فایروال پیکربندی‌شده با UFW داشته باشند. برای راه‌اندازی هر دو سرور، راهنمای «راه‌اندازی اولیه سرور با اوبونتو» ما را دنبال کنید.
• MySQL نصب‌شده روی هر سرور. این راهنما فرض می‌کند از آخرین نسخه MySQL موجود در مخازن پیش‌فرض اوبونتو استفاده می‌کنید. برای نصب روی هر دو سرور، راهنمای «نصب MySQL روی اوبونتو» ما را دنبال کنید.

توجه: این آموزش با اوبونتو 24.04 و MySQL نسخه 8.4.8 تست شده است.

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

به‌طور مشابه، هر دستوری که باید روی سرور اینستنس Replica اجرا شود، پس‌زمینه قرمز خواهد داشت.

در نهایت، این آموزش شامل دستورالعمل‌های اختیاری درباره نحوه مهاجرت داده‌های یک پایگاه داده موجود از Source به Replica است. این فرایند شامل ساخت Snapshot از پایگاه داده Source و کپی کردن فایل حاصل به Replica است. برای این کار، توصیه می‌کنیم کلیدهای SSH را روی سرور Source راه‌اندازی کرده و سپس مطمئن شوید کلید عمومی Source به Replica کپی شده است.

درک Replication در MySQL

در MySQL، ‏Replication شامل این است که پایگاه داده Source هر تغییری را که در داده‌های داخل یک یا چند پایگاه داده ایجاد می‌شود، در فایل خاصی به نام Binary Log ثبت می‌کند. به‌محض راه‌اندازی اولیه شدنِ اینستنس Replica، دو پروسه نخ‌دار (Threaded) می‌سازد. اولی که نخ IO نام دارد، به اینستنس MySQL مربوط به Source متصل شده، رویدادهای Binary Log را خط‌به‌خط می‌خواند و آن‌ها را در فایل محلی روی سرور Replica به نام Relay Log کپی می‌کند. نخ دوم که نخ SQL نام دارد، رویدادها را از Relay Log خوانده و سپس آن‌ها را در سریع‌ترین حالت ممکن روی اینستنس Replica اعمال می‌کند.

نسخه‌های جدید MySQL از دو روش برای Replicate کردن داده پشتیبانی می‌کنند. تفاوت این روش‌های Replication به نحوه ردیابیِ Replicaها برمی‌گردد؛ اینکه کدام رویدادهای پایگاه داده از Source را قبلاً پردازش کرده‌اند.

MySQL روش سنتی خود را «Replication مبتنی بر موقعیت فایل Binary Log» (Binary Log File Position-Based) می‌نامد. وقتی با این روش یک اینستنس MySQL را به Replica تبدیل می‌کنید، باید مجموعه‌ای از مختصات Binary Log به آن بدهید. این مختصات شامل نام فایل Binary Log روی Source است که Replica باید بخواند و موقعیت خاصی داخل آن فایل که اولین رویداد پایگاه داده‌ای را که Replica باید به اینستنس MySQL خودش کپی کند، مشخص می‌کند.

این مختصات مهم‌اند؛ چون Replicaها نسخه‌ای از کل Binary Log مربوط به Source خود را دریافت می‌کنند و بدون مختصات درست، شروع به Replicate کردن هر رویداد پایگاه داده‌ایِ ثبت‌شده در آن خواهند کرد. این موضوع می‌تواند اگر فقط بخواهید داده‌ها را بعد از یک لحظه زمانی مشخص Replicate کنید یا فقط زیرمجموعه‌ای از داده‌های Source را بخواهید، مشکل‌ساز شود.

Replication مبتنی بر موقعیتِ فایل Binary Log برای بسیاری از موارد کاربردی قابل‌اجرا است؛ اما این روش در راه‌اندازی‌های پیچیده‌تر می‌تواند دست‌وپاگیر شود. این موضوع به توسعه روش جدیدترِ بومی MySQL منجر شد که گاهی «Replication مبتنی بر تراکنش» (Transaction-Based) نامیده می‌شود. این روش شامل ساخت یک شناسه تراکنش سراسری (GTID) برای هر تراکنش — یعنی یک قطعه کار ایزوله‌شده انجام‌شده توسط پایگاه داده — است که اینستنس MySQL مربوط به Source اجرا می‌کند.

مکانیکِ Replication مبتنی بر تراکنش شبیه Replication مبتنی بر فایل Binary Log است: هر وقت یک تراکنش پایگاه داده‌ای روی Source رخ بدهد، MySQL یک GTID به آن تراکنش تخصیص داده و همراه خودِ تراکنش در فایل Binary Log ثبت می‌کند. سپس GTID و تراکنش برای پردازش به Replicaهای Source منتقل می‌شوند.

Replication مبتنی بر تراکنشِ MySQL نسبت به روش سنتی‌اش مزایای متعددی دارد. مثلاً، چون هم Source و هم Replicaهایش GTIDها را حفظ می‌کنند، اگر Source یا Replicaای با تراکنشی با GTIDای که قبلاً پردازش کرده روبرو شود، آن تراکنش را رد می‌کند. این به تضمین سازگاری بین Source و Replicaهایش کمک می‌کند. علاوه بر این، با Replication مبتنی بر تراکنش، ‏Replicaها لازم نیست مختصات Binary Log رویداد بعدیِ پایگاه داده برای پردازش را بدانند. این یعنی شروع Replicaهای جدید یا تغییر ترتیب Replicaها در یک زنجیره Replication، بسیار کم‌پیچیده‌تر است.

در نظر داشته باشید که این فقط توضیح عمومیِ نحوه هندلِ Replication توسط MySQL است؛ MySQL گزینه‌های زیادی فراهم می‌کند که می‌توانید برای بهینه‌سازی راه‌اندازی Replication خودتان تنظیمشان کنید. این راهنما نحوه راه‌اندازی Replication مبتنی بر موقعیت فایل Binary Log را تشریح می‌کند. اگرچه اگر به پیکربندی نوع متفاوتی از محیط Replication علاقه‌مند هستید، تشویق می‌شوید مستندات رسمی MySQL را بررسی کنید.

مرحله ۱ — تنظیم فایروال سرور Source

با فرض اینکه راهنمای پیش‌نیازیِ «راه‌اندازی اولیه سرور» را دنبال کرده باشید، روی هر دو سرور خود فایروالی با UFW پیکربندی کرده‌اید. این کار به امن ماندن هر دو سرور کمک می‌کند؛ اما فایروال سرور Source، تلاش‌های اتصالِ اینستنس Replica شما را مسدود خواهد کرد.

برای تغییر این موضوع، باید قانونی از UFW بگنجانید که اتصالات Replica را از طریق فایروال Source مجاز بداند. می‌توانید این کار را با اجرای دستوری مثل دستور زیر روی سرور Source انجام دهید.

این دستور خاص، هر اتصالی را که از آدرس IP سرور Replica originate شود — که با replica_server_ip نمایش داده شده — به شماره پورت پیش‌فرض MySQL یعنی 3306 مجاز می‌کند:

sudo ufw allow from replica_server_ip to any port 3306

حتماً replica_server_ip را با IP واقعی سرور Replica خود جایگزین کنید. اگر قانون با موفقیت اضافه شد، خروجی زیر را می‌بینید:

خروجی:

Rule added

پس از آن، نیازی به هیچ تغییری در قوانین فایروال Replica ندارید؛ چون سرور Replica هیچ اتصال ورودی دریافت نمی‌کند و اتصالات خروجیِ به سرور MySQL مربوط به Source توسط UFW مسدود نمی‌شوند. می‌توانید به به‌روزرسانی پیکربندی اینستنس MySQL مربوط به Source برای فعال‌سازی Replication بپردازید.

مرحله ۲ — پیکربندی پایگاه داده Source

برای اینکه پایگاه داده MySQL مربوط به Source شما شروع به Replicate کردن داده‌ها کند، باید چند تغییر در پیکربندی آن ایجاد کنید.

روی اوبونتو 24.04، فایل پیکربندی پیش‌فرض سرور MySQL با نام mysqld.cnf در دایرکتوری /etc/mysql/mysql.conf.d/ قرار دارد. این فایل را روی سرور Source با ویرایشگر متن دلخواه خود باز کنید. اینجا از nano استفاده می‌کنیم:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

درون فایل، Directive مربوط به bind-address را پیدا کنید. به‌صورت پیش‌فرض به این شکل است:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
bind-address            = 127.0.0.1
. . .

مقدار 127.0.0.1 یک آدرس Loopback مربوط به IPv4 است که localhost را نشان می‌دهد و تنظیم آن به‌عنوان مقدار bind-address به MySQL دستور می‌دهد فقط به اتصالات روی آدرس localhost گوش دهد. به بیان دیگر، این اینستنس MySQL فقط قادر خواهد بود اتصالاتی را بپذیرد که از خودِ سروری که روی آن نصب شده originate شوند.

به یاد داشته باشید که در حال تبدیل اینستنس MySQL دیگر خود به Replica این سرور هستید؛ پس Replica باید بتواند هر داده جدیدی را که در نصب Source نوشته می‌شود بخواند. برای مجاز کردن این کار، باید اینستنس MySQL مربوط به Source را طوری پیکربندی کنید که روی آدرس IPای که Replica می‌تواند به آن برسد گوش دهد؛ مانند IP عمومی سرور Source.

مقدار 127.0.0.1 را با آدرس IP سرور Source جایگزین کنید. پس از انجام این کار، Directive مربوط به bind-address به این شکل خواهد بود؛ با آدرس IP سرور خودتان به‌جای source_server_ip:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
bind-address            = source_server_ip
. . .

سپس، Directive مربوط به server-id را پیدا کنید؛ که شناسه‌ای را تعریف می‌کند که MySQL به‌صورت داخلی برای تشخیص سرورها در یک راه‌اندازیِ Replication استفاده می‌کند. هر سرور در محیط Replication — شامل Source و همه Replicaهایش — باید مقدار server-id یکتای خودش را داشته باشد. این Directive به‌صورت پیش‌فرض کامنت شده و به این شکل است:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
# server-id             = 1
. . .

این خط را با حذف علامت # از کامنت خارج کنید. می‌توانید هر عددی را به‌عنوان مقدار این Directive انتخاب کنید؛ اما به یاد داشته باشید که عدد باید یکتا بوده و با هیچ server-id دیگری در گروه Replication شما مطابقت نکند. برای ساده نگه‌داشتن کارها، مثال زیر این مقدار را روی پیش‌فرض یعنی ۱ باقی می‌گذارد:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
server-id               = 1
. . .

زیر خط server-id، ‏Directive مربوط به log_bin را پیدا کنید. این Directive نام پایه و مکان فایل Binary Log مربوط به MySQL را تعریف می‌کند.

وقتی کامنت شده باشد — که این Directive به‌صورت پیش‌فرض همین‌طور است — ‏Binary Logging غیرفعال است. سرور Replica شما باید فایل Binary Log مربوط به Source را بخواند تا بداند چه زمانی و چطور داده‌های Source را Replicate کند؛ پس این خط را برای فعال‌کردن Binary Logging روی Source از کامنت خارج کنید. پس از انجام این کار، به این شکل خواهد بود:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
log_bin                       = /var/log/mysql/mysql-bin.log
. . .

در نهایت، به انتهای فایل اسکرول کنید تا Directive کامنت‌شده binlog_do_db را پیدا کنید:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
# binlog_do_db          = include_database_name

علامت # را حذف کنید تا این خط از کامنت خارج شده و include_database_name را با نام پایگاه داده‌ای که می‌خواهید Replicate شود جایگزین کنید. این مثال، Directive مربوط به binlog_do_db را نشان می‌دهد که به پایگاه داده‌ای با نام db اشاره می‌کند؛ اما اگر پایگاه داده موجودی روی Source دارید که می‌خواهید Replicate کنید، نام آن را به‌جای db قرار دهید:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
binlog_do_db          = db

توجه: اگر می‌خواهید بیش از یک پایگاه داده Replicate کنید، می‌توانید برای هر پایگاه داده‌ای که می‌خواهید Replicate شود، یک Directive مربوط به binlog_do_db اضافه کنید. این آموزش با Replicate کردن فقط یک پایگاه داده ادامه می‌یابد؛ اما اگر می‌خواستید بیش از یکی را Replicate کنید، به این شکل می‌توانست باشد:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
binlog_do_db          = db
binlog_do_db          = db_1
binlog_do_db          = db_2

به‌طور جایگزین، می‌توانید مشخص کنید MySQL کدام پایگاه‌های داده را Replicate نکند؛ با افزودن یک Directive مربوط به binlog_ignore_db برای هر کدام:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
binlog_ignore_db          = db_to_ignore

پس از اعمال این تغییرات، فایل را ذخیره کرده و ببندید. اگر از nano برای ویرایش فایل استفاده کرده‌اید، با فشردن CTRL+X و سپس Y و بعد ENTER این کار را انجام دهید.

سپس سرویس MySQL را با اجرای دستور زیر ری‌استارت کنید:

sudo systemctl restart mysql

با این کار، این اینستنس MySQL آماده است تا به‌عنوان پایگاه داده Sourceای عمل کند که سرور MySQL دیگر شما از آن Replicate می‌کند. با این حال، قبل از اینکه بتوانید Replica خود را پیکربندی کنید، هنوز چند مرحله دیگر روی Source باید انجام دهید تا مطمئن شوید توپولوژی Replication شما به‌درستی کار خواهد کرد. اولین این مراحل، ساخت یک کاربر اختصاصی MySQL است که هر اقدام مرتبط با فرایند Replication را انجام می‌دهد.

مرحله ۳ — ساخت یک کاربر Replication

هر Replica در یک محیط Replication مربوط به MySQL، با یک نام کاربری و رمز عبور به پایگاه داده Source متصل می‌شود. Replicaها می‌توانند با هر پروفایل کاربری MySQLای که روی پایگاه داده Source وجود دارد و دسترسی‌های مناسب را دارد متصل شوند؛ اما این آموزش نحوه ساخت یک کاربر اختصاصی برای این منظور را تشریح می‌کند.

با باز کردن شل MySQL شروع کنید:

sudo mysql

توجه: اگر کاربر اختصاصی MySQLای پیکربندی کرده‌اید که با رمز عبور احراز هویت می‌شود، می‌توانید به‌جای آن با دستوری مثل این به MySQL متصل شوید:

mysql -u sammy -p

به‌جای sammy، نام کاربر اختصاصی خود را قرار داده و هنگام درخواست، رمز عبور این کاربر را وارد کنید.

آگاه باشید که برخی عملیات در سراسر این راهنما — از جمله چند مورد که باید روی سرور Replica انجام شوند — نیازمند دسترسی‌های پیشرفته‌اند. به همین دلیل، ممکن است راحت‌تر باشد مثل دستور sudo mysql قبلی، به‌عنوان کاربر مدیریتی متصل شوید. اگرچه اگر می‌خواهید در سراسر این راهنما از کاربر MySQL با دسترسی کمتر استفاده کنید، آن کاربر حداقل باید دسترسی‌های CREATE USER و RELOAD و REPLICATION CLIENT و REPLICATION SLAVE و REPLICATION_SLAVE_ADMIN را گرفته باشد.

از خط فرمان، یک کاربر MySQL جدید بسازید. مثال زیر کاربری با نام replica_user می‌سازد؛ اما می‌توانید نام دلخواهی انتخاب کنید. حتماً replica_server_ip را با IP عمومی سرور Replica خود و password را با یک رمز عبور قوی به انتخاب خودتان تغییر دهید:

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

توجه کنید که این دستور تعیین می‌کند replica_user از پلاگین احراز هویت mysql_native_password استفاده کند. امکان استفاده از مکانیزم احراز هویت پیش‌فرض MySQL یعنی caching_sha2_password هست؛ اما این کار راه‌اندازی یک اتصال رمزنگاری‌شده بین Source و Replica را الزام می‌کند. چنین راه‌اندازی‌ای برای محیط‌های production بهینه است؛ اما پیکربندی اتصالات رمزنگاری‌شده فراتر از محدوده این آموزش است. مستندات MySQL اگر بخواهید چنین چیزی راه‌اندازی کنید، دستورالعمل‌هایی برای پیکربندی محیط Replicationای که از اتصالات رمزنگاری‌شده استفاده می‌کند در بر دارد.

پس از ساخت کاربر جدید، دسترسی‌های مناسب را به او بدهید. حداقلِ یک کاربر Replication مربوط به MySQL باید دسترسی REPLICATION SLAVE را داشته باشد:

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

پس از این، اجرای دستور FLUSH PRIVILEGES عمل خوبی است. این کار هر حافظه‌ای را که سرور به‌عنوان نتیجه دستورات CREATE USER و GRANT قبلی کش کرده، آزاد می‌کند:

FLUSH PRIVILEGES;

با این کار، راه‌اندازی کاربر Replication روی اینستنس MySQL مربوط به Source را تمام کرده‌اید. با این حال، از شل MySQL خارج نشوید. فعلاً آن را باز نگه دارید؛ چون در مرحله بعد از آن برای به‌دست‌آوردن چند اطلاعات مهم درباره فایل Binary Log مربوط به پایگاه داده Source استفاده خواهید کرد.

مرحله ۴ — بازیابی مختصات Binary Log از Source

به یاد بیاورید از بخش «درک Replication در MySQL» که MySQL پیاده‌سازی Replication را با کپی کردن رویدادهای پایگاه داده از فایل Binary Log مربوط به Source، خط‌به‌خط و اعمال هر رویداد روی Replica انجام می‌دهد. وقتی از Replication مبتنی بر موقعیت فایل Binary Log استفاده می‌کنید، باید به Replica مجموعه‌ای از مختصات بدهید که نام فایل Binary Log مربوط به Source و موقعیت خاصی درون آن فایل را تشریح می‌کنند. سپس Replica از این مختصات برای تعیین نقطه‌ای در فایل لاگ که باید از آن کپی کردن رویدادهای پایگاه داده را شروع کند و ردیابی اینکه کدام رویدادها را قبلاً پردازش کرده، استفاده می‌کند.

این مرحله نحوه به‌دست‌آوردن مختصات فعلیِ Binary Log اینستنس Source را تشریح می‌کند تا بتوانید Replicaهای خود را طوری پیکربندی کنید که از آخرین نقطه فایل لاگ، Replicate کردن داده را شروع کنند. برای اطمینان از اینکه هیچ کاربری هنگام بازیابی مختصات، داده‌ای را تغییر ندهد، باید پایگاه داده را قفل کنید تا هیچ کلاینتی نتواند داده بخواند یا بنویسد. به‌زودی همه‌چیز را باز می‌کنید؛ اما این رویه مقداری Downtime ایجاد می‌کند.

باید هنوز شل MySQL سرور Source خود را از انتهای مرحله قبل باز داشته باشید. از خط فرمان، دستور زیر را اجرا کنید که همه جدول‌های باز را در هر پایگاه داده‌ای روی اینستنس Source می‌بندد و آن‌ها را قفل می‌کند:

FLUSH TABLES WITH READ LOCK;

سپس عملیات زیر را اجرا کنید که اطلاعات وضعیت فعلی فایل‌های Binary Log مربوط به Source را برمی‌گرداند:

SHOW BINARY LOG STATUS;

جدولی مشابه این مثال را در خروجی خود می‌بینید:

خروجی:

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      899 | db          |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

این موقعیتی است که Replica از آن، کپی کردن رویدادهای پایگاه داده را شروع خواهد کرد. نام File و مقدار Position را یادداشت کنید؛ چون بعداً وقتی Replication را راه‌اندازی اولیه می‌کنید به آن‌ها نیاز خواهید داشت.

کاری که بلافاصله بعد از به‌دست‌آوردن این اطلاعات انجام می‌دهید، به اینکه آیا پایگاه داده Source شما داده موجودی برای مهاجرت به Replicaهایتان دارد یا نه بستگی دارد. به هر کدام از دو زیربخش بعدی که بیشترین تناسب را با وضعیت شما دارد بروید.

اگر Source شما هیچ داده موجودی برای مهاجرت ندارد

اگر اینستنس MySQL مربوط به Source شما یک نصب جدید است یا هیچ داده موجودی که بخواهید به Replicaهایتان مهاجرت دهید ندارد، در این نقطه می‌توانید جدول‌ها را باز کنید:

UNLOCK TABLES;

اگر هنوز این کار را نکرده‌اید، می‌توانید درحالی‌که هنوز شل MySQL باز است، پایگاه داده‌ای را که برای Replicate کردن انتخاب کرده‌اید بسازید. هم‌راستا با مثالِ داده‌شده در مرحله ۲، عملیات زیر پایگاه داده‌ای با نام db می‌سازد:

CREATE DATABASE db;

خروجی:

Query OK, 1 row affected (0.01 sec)

پس از آن، شل MySQL را ببندید:

exit

با این کار، می‌توانید به مرحله ۵ بروید.

اگر Source شما داده موجودی برای مهاجرت دارد

اگر روی اینستنس MySQL مربوط به Source خود داده‌ای دارید که می‌خواهید به Replicaهایتان مهاجرت دهید، می‌توانید این کار را با ساخت Snapshot از پایگاه داده با ابزار mysqldump انجام دهید. با این حال، پایگاه داده شما باید همچنان قفل باشد. اگر هر تغییری در همان پنجره ایجاد کنید، پایگاه داده به‌طور خودکار باز (Unlock) می‌شود. به‌طور مشابه، اگر از کلاینت خارج شوید، جدول‌ها به‌طور خودکار باز می‌شوند.

باز شدن جدول‌ها می‌تواند به مشکلاتی منجر شود؛ چون یعنی کلاینت‌ها دوباره می‌توانستند داده‌های پایگاه داده را تغییر دهند. این موضوع می‌تواند بالقوه به عدم تطابق بین Snapshot داده شما و مختصات Binary Logای که همین الان بازیابی کردید منجر شود.

به همین دلیل، باید روی ماشین محلی خود یک پنجره یا تب ترمینال جدید باز کنید تا بتوانید Snapshot پایگاه داده را بدون باز کردن قفل MySQL بسازید.

از پنجره یا تب ترمینال جدید، یک نشست SSH دیگر به سروری که اینستنس MySQL مربوط به Source را میزبانی می‌کند باز کنید:

ssh sammy@source_server_ip

سپس، از تب یا پنجره جدید، پایگاه داده خود را با mysqldump خارج‌سازی (Export) کنید. مثال زیر فایل Dumpای با نام db.sql از پایگاه داده‌ای با نام db می‌سازد؛ اما مطمئن شوید نام پایگاه داده خودتان را به‌جای آن قرار می‌دهید. همچنین حتماً این دستور را در شل bash اجرا کنید، نه شل MySQL:

sudo mysqldump -u root db > db.sql

پس از آن، می‌توانید این پنجره یا تب ترمینال را بسته و به اولی برگردید؛ که باید همچنان شل MySQL باز داشته باشد. از خط فرمان MySQL، جدول‌ها را باز کنید تا دوباره قابل نوشتن شوند:

UNLOCK TABLES;

سپس می‌توانید از شل MySQL خارج شوید:

exit

اکنون می‌توانید فایل Snapshot خود را به سرور Replica بفرستید. با فرض اینکه کلیدهای SSH را روی سرور Source پیکربندی کرده و کلید عمومی Source را به فایل authorized_keys مربوط به Replica اضافه کرده‌اید، می‌توانید این کار را به‌طور امن با دستوری مثل این scp انجام دهید:

scp db.sql sammy@replica_server_ip:/tmp/

حتماً sammy را با نام پروفایل کاربر مدیریتی اوبونتویی که روی سرور Replica ساختید جایگزین کرده و replica_server_ip را با IP سرور Replica جایگزین کنید. همچنین توجه کنید که این دستور Snapshot را در دایرکتوری ‎/tmp/ سرور Replica قرار می‌دهد.

پس از فرستادن Snapshot به سرور Replica، با SSH وارد آن شوید:

ssh sammy@replica_server_ip

سپس شل MySQL را باز کنید:

sudo mysql

از خط فرمان، پایگاه داده جدیدی را که قرار است از Source Replicate شود بسازید:

CREATE DATABASE db;

لازم نیست جدولی بسازید یا این پایگاه داده را با داده نمونه‌ای بارگذاری کنید. همه آن کارها هنگام Import کردن پایگاه داده با Snapshotای که همین الان ساختید انجام خواهند شد. به‌جای آن، از شل MySQL خارج شوید:

exit

سپس Snapshot پایگاه داده را Import کنید:

sudo mysql db < /tmp/db.sql

Replica شما اکنون همه داده‌های موجود از پایگاه داده Source را دارد. می‌توانید مرحله نهایی این راهنما را کامل کنید تا سرور Replica خود را برای شروع Replicate کردنِ تغییرات جدید ایجادشده روی پایگاه داده Source پیکربندی کنید.

مرحله ۵ — پیکربندی پایگاه داده Replica

تنها کار باقی‌مانده، تغییر پیکربندی Replica به شکلی مشابه نحوه تغییر Source است. فایل پیکربندی MySQL یعنی mysqld.cnf را این بار روی سرور Replica باز کنید:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

همان‌طور که قبلاً ذکر شد، هر اینستنس MySQL در یک راه‌اندازیِ Replication باید مقدار server-id یکتایی داشته باشد. Directive مربوط به server-id رِ Replica را پیدا کرده، از کامنت خارج کرده و مقدارش را به هر عدد صحیح مثبتی تغییر دهید؛ تا زمانی که با مقدار Source متفاوت باشد:

/etc/mysql/mysql.conf.d/mysqld.cnf

server-id               = 2

پس از آن، مقادیر log_bin و binlog_do_db را به‌روزرسانی کنید تا با مقادیری که در فایل پیکربندی ماشین Source تنظیم کردید هم‌راستا شوند:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
log_bin                 = /var/log/mysql/mysql-bin.log
. . .
binlog_do_db            = db
. . .

در نهایت، یک Directive مربوط به relay-log اضافه کنید که مکان فایل Relay Log مربوط به Replica را تعریف می‌کند. خط زیر را به انتهای فایل پیکربندی اضافه کنید:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
relay-log               = /var/log/mysql/mysql-relay-bin.log

پس از اعمال این تغییرات، فایل را ذخیره کرده و ببندید. سپس MySQL را روی Replica ری‌استارت کنید تا پیکربندی جدید اعمال شود:

sudo systemctl restart mysql

پس از ری‌استارت سرویس mysql، در نهایت آماده شروع Replicate کردن داده از پایگاه داده Source هستید.

مرحله ۶ — شروع و تست Replication

در این نقطه، هر دو اینستنس MySQL شما کاملاً برای مجاز کردن Replication پیکربندی شده‌اند. برای شروع Replicate کردن داده از Source، شل MySQL را روی سرور Replica خود باز کنید:

sudo mysql

از خط فرمان، عملیات زیر را اجرا کنید که چند تنظیم Replication مربوط به MySQL را هم‌زمان پیکربندی می‌کند. پس از اجرای این دستور، به‌محض فعال‌سازی Replication روی این اینستنس، سعی می‌کند به آدرس IP بعد از SOURCE_HOST با نام کاربری و رمز عبورِ به ترتیب بعد از SOURCE_USER و SOURCE_PASSWORD متصل شود. همچنین به‌دنبال فایل Binary Logی با نام بعد از SOURCE_LOG_FILE خواهد گشت و آن را از موقعیت بعد از SOURCE_LOG_POS شروع به خواندن می‌کند.

حتماً source_server_ip را با IP سرور Source خود جایگزین کنید. به‌طور مشابه، replica_user و password باید با کاربر Replicationای که در مرحله ۳ ساختید هم‌راستا باشند؛ و mysql-bin.000001 و 899 باید مختصات Binary Logای که در مرحله ۴ به دست آوردید را بازتاب بدهند.

شاید بخواهید این دستور را قبل از اجرا روی سرور Replica در یک ویرایشگر متن تایپ کنید تا بتوانید راحت‌تر همه اطلاعات مربوطه را جایگزین کنید:

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='source_server_ip',
SOURCE_USER='replica_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

پس از آن، سرور Replica را فعال کنید:

START REPLICA;

اگر همه جزئیات را درست وارد کرده باشید، این اینستنس شروع به Replicate کردن هر تغییری خواهد کرد که روی پایگاه داده db در Source ایجاد شود.

می‌توانید جزئیات وضعیت فعلی Replica را با اجرای عملیات زیر ببینید. اصلاح‌گر \G در این دستور، متن را بازآرایی می‌کند تا خواناتر باشد:

SHOW REPLICA STATUS\G;

این دستور اطلاعات زیادی را برمی‌گرداند که هنگام عیب‌یابی می‌تواند مفید باشد:

خروجی:

*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 138.197.3.190
                  Source_User: replica_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000001
          Read_Source_Log_Pos: 1273
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 729
        Relay_Source_Log_File: mysql-bin.000001
. . .

توجه: اگر Replica شما در اتصال مشکل دارد یا Replication به‌طور غیرمنتظره متوقف می‌شود، ممکن است رویدادی در فایل Binary Log مربوط به Source مانع Replication باشد. در چنین مواردی، می‌توانید دستور SET GLOBAL SQL_REPLICA_SKIP_COUNTER را برای رد کردن تعداد مشخصی از رویدادها بعد از موقعیت فایل Binary Logای که در دستور قبلی تعریف کردید اجرا کنید. این مثال فقط اولین رویداد را رد می‌کند:

SET GLOBAL SQL_REPLICA_SKIP_COUNTER = 1;

پس از آن، باید Replica را دوباره شروع کنید:

START REPLICA;

همچنین، اگر هر وقت لازم شد Replication را متوقف کنید، توجه داشته باشید که می‌توانید این کار را با اجرای عملیات زیر روی اینستنس Replica انجام دهید:

STOP REPLICA;

Replica شما اکنون در حال Replicate کردن داده از Source است. هر تغییری که در پایگاه داده Source ایجاد کنید، روی اینستنس Replica منعکس خواهد شد. می‌توانید این را با ساخت یک جدول نمونه روی پایگاه داده Source و بررسی اینکه با موفقیت Replicate می‌شود یا نه، تست کنید.

با باز کردن شل MySQL روی ماشین Source شروع کنید:

sudo mysql

پایگاه داده‌ای را که برای Replicate کردن انتخاب کردید، انتخاب کنید:

USE db;

سپس جدولی درون آن پایگاه داده بسازید. عملیات SQL زیر جدولی با نام example_table و یک ستون با نام example_column می‌سازد:

CREATE TABLE example_table (
  example_column VARCHAR(30)
);

خروجی:

Query OK, 0 rows affected (0.03 sec)

اگر بخواهید، می‌توانید چند داده نمونه هم به این جدول اضافه کنید:

INSERT INTO example_table VALUES
('This is the first row'),
('This is the second row'),
('This is the third row');

خروجی:

Query OK, 3 rows affected (0.03 sec)
Records: 3  Duplicates: 0  Warnings: 0

پس از ساخت جدول و افزودن اختیاریِ چند داده نمونه به آن، به شل MySQL سرور Replica خود برگردید و پایگاه داده Replicate شده را انتخاب کنید:

USE db;

سپس دستور SHOW TABLES را برای فهرست کردن همه جدول‌های داخل پایگاه داده انتخاب‌شده اجرا کنید:

SHOW TABLES;

اگر Replication به‌درستی کار کند، جدولی را که همین الان به Source اضافه کردید در خروجی این دستور فهرست‌شده می‌بینید:

خروجی:

+---------------+
| Tables_in_db  |
+---------------+
| example_table |
+---------------+
1 row in set (0.00 sec)

همچنین، اگر چند داده نمونه به جدول روی Source اضافه کرده بودید، می‌توانید با کوئری‌ای مثل زیر بررسی کنید که آن داده‌ها هم Replicate شده‌اند یا نه:

SELECT * FROM example_table;

در SQL، علامت ستاره (*) میان‌بری برای «همه ستون‌ها» است. پس این کوئری عملاً به MySQL می‌گوید همه ستون‌های example_table را برگرداند. اگر Replication طبق انتظار کار کند، این عملیات آن داده‌ها را در خروجی‌اش برمی‌گرداند:

خروجی:

+------------------------+
| example_column         |
+------------------------+
| This is the first row  |
| This is the second row |
| This is the third row  |
+------------------------+
3 rows in set (0.00 sec)

اگر هر کدام از این عملیات نتوانستند جدول نمونه یا داده‌ای را که به Source اضافه کردید برگردانند، ممکن است جایی در پیکربندی Replication خود خطا داشته باشید. در چنین مواردی، می‌توانید عملیات SHOW REPLICA STATUS\G را برای یافتن علت مشکل اجرا کنید. علاوه بر این، می‌توانید برای پیشنهادهایی درباره نحوه رفع مشکلات Replication به مستندات MySQL درباره عیب‌یابیِ Replication مراجعه کنید.

خطاهای رایج و عیب‌یابی

هنگام راه‌اندازی Replication در MySQL، مدیران ممکن است با مشکلات متنوعی از پیکربندی، شبکه یا همگام‌سازی داده روبرو شوند. چون Replication به ارتباط بین چندین سرور و موقعیت‌های دقیق لاگ متکی است، حتی خطاهای کوچک پیکربندی می‌توانند باعث توقف Replication یا شروع‌نشدن آن شوند. بخش‌های زیر برخی از رایج‌ترین مشکلات و مراحل عملیِ عیب‌یابی که می‌توانید برای تشخیص و رفع آن‌ها انجام دهید را تشریح می‌کنند.

ناتوانی Replica در اتصال به سرور Source

یکی از رایج‌ترین مشکلات وقتی رخ می‌دهد که Replica نتواند اتصالی به سرور Source برقرار کند. در چنین مواردی، دستور SHOW REPLICA STATUS\G ممکن است خطاهایی مانند شکست‌های اتصال یا مشکلات احراز هویت را نمایش دهد.

این مشکل اغلب توسط محدودیت‌های شبکه، قوانین فایروال یا جزئیات اتصال نادرست در پیکربندی Replication ایجاد می‌شود.

ابتدا تأیید کنید که سرور Source، اتصالات از IP مربوط به Replica را مجاز می‌کند. اگر فایروالی مانند UFW فعال است، مطمئن شوید پورت 3306 برای سرور Replica باز است. مثلاً:

sudo ufw allow from replica_server_ip to any port 3306

سپس، تأیید کنید که Directive مربوط به bind-address در پیکربندی MySQL سرور Source روی 127.0.0.1 تنظیم نشده باشد. اگر MySQL فقط روی آدرس Loopback گوش دهد، هاست‌های خارجی — شامل Replicaها — قادر به اتصال نخواهند بود. به‌جای آن، باید با IP در دسترسِ سرور Source پیکربندی شود.

همچنین باید تأیید کنید که مقادیر SOURCE_HOST و SOURCE_USER و SOURCE_PASSWORD تعیین‌شده در دستور CHANGE REPLICATION SOURCE TO درست هستند.

در حال اجرا نبودن نخ‌های Replication

Replication به دو نخ روی سرور Replica متکی است:

• نخ Replica_IO رویدادها را از سرور Source بازیابی می‌کند
• نخ Replica_SQL آن رویدادها را به‌صورت محلی اجرا می‌کند

اگر هر کدام از این نخ‌ها متوقف شود، Replication از کار می‌ایستد.

می‌توانید وضعیت این نخ‌ها را با اجرای این دستور بررسی کنید:

SHOW REPLICA STATUS\G;

به‌دنبال این فیلدها بگردید:

• Replica_IO_Running
• Replica_SQL_Running

اگر هر کدام No باشد، ‏Replication به دلیل خطایی متوقف شده است.

برای شروع مجددِ Replication پس از رفع مشکل، اجرا کنید:

START REPLICA;

اگر نخ‌ها بعد از شروع مجدد بارها متوقف می‌شوند، فیلدهای Last_IO_Error و Last_SQL_Error را در خروجی وضعیت بررسی کنید تا علت ریشه‌ای شناسایی شود.

مختصات نادرست Binary Log

در راه‌اندازی‌های Replication مبتنی بر موقعیت، ‏Replicaها باید رویدادها را از فایل و موقعیت درستِ Binary Log شروع به خواندن کنند. اگر مختصات نادرست استفاده شوند، ‏Replication ممکن است شروع نشود یا داده نادرستی را Replicate کند.

می‌توانید مختصات درست Binary Log را روی سرور Source با این دستور تأیید کنید:

SHOW BINARY LOG STATUS;

خروجی شامل مقادیر این موارد خواهد بود:

• File
• Position

مطمئن شوید این مقادیر با پارامترهای SOURCE_LOG_FILE و SOURCE_LOG_POSِ پیکربندی‌شده روی Replica مطابقت دارند.

در صورت لزوم، Replication را متوقف کرده، پیکربندی را به‌روزرسانی کرده و Replication را دوباره شروع کنید:

STOP REPLICA;

CHANGE REPLICATION SOURCE TO
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

START REPLICA;

توقف Replication به دلیل ناسازگاری داده

Replication می‌تواند متوقف شود اگر Replica هنگام اعمال یک رویداد پایگاه داده با خطا روبرو شود. این ممکن است وقتی رخ بدهد که:

• جدولی از قبل روی Replica وجود داشته باشد
• سطری که در حال درج است از قبل وجود داشته باشد
• تفاوت Schema بین سرورها وجود داشته باشد

وقتی این اتفاق بیفتد، فیلد Replica_SQL_Running مقدار No را نشان داده و Last_SQL_Error جزئیاتی درباره کوئری شکست‌خورده ارائه می‌دهد.

اگر ناسازگاری جزئی و رد کردنش امن باشد، می‌توانید به Replica دستور بدهید رویداد مشکل‌ساز را رد کند:

SET GLOBAL SQL_REPLICA_SKIP_COUNTER = 1;
START REPLICA;

با این حال، رد کردن رویدادها باید با احتیاط انجام شود؛ چون ممکن است ناسازگاری داده بین Source و Replica ایجاد کند. برای مشکلات مداوم، بازسازی Replica با یک Snapshot تازه از پایگاه داده ممکن است امن‌تر باشد.

تأخیر Replication (Lag)

تأخیر Replication وقتی رخ می‌دهد که Replica در پردازش رویدادها از سرور Source عقب بماند. این موضوع می‌تواند باعث شود Replicaها داده قدیمی سرو کنند.

می‌توانید تأخیر را با فیلد Seconds_Behind_Source در خروجی این دستور مانیتور کنید:

SHOW REPLICA STATUS\G;

علت‌های رایج تأخیر شامل این موارد است:

• بارهای کاری نوشتنِ سنگین روی Source
• کارایی کند دیسک روی Replica
• تأخیر شبکه (Latency)
• محدودیت‌های منابع مانند CPU یا حافظه

برای کاهش تأخیر Replication، این موارد را در نظر بگیرید:

• افزایش منابع سخت‌افزاری روی Replica
• بهینه‌سازی کوئری‌های کند
• استفاده از ذخیره‌سازی سریع‌تر
• توزیع ترافیک خواندن بین چند Replica

فعال نبودن Binary Logging روی Source

Replication به Binary Logging برای ثبت تغییرات پایگاه داده متکی است. اگر Directive مربوط به log_bin روی سرور Source غیرفعال باشد، ‏Replicaها هیچ به‌روزرسانی دریافت نخواهند کرد.

برای تأیید این تنظیم، فایل پیکربندی MySQL (معمولاً mysqld.cnf) را بررسی کرده و مطمئن شوید خط زیر موجود و کامنت‌نشده است:

log_bin = /var/log/mysql/mysql-bin.log

پس از تغییر فایل پیکربندی، سرویس MySQL را ری‌استارت کنید:

sudo systemctl restart mysql

مشکلات سازگاری پلاگین احراز هویت

در برخی راه‌اندازی‌ها، احراز هویتِ Replication می‌تواند به دلیل عدم تطابق پلاگین‌های احراز هویت شکست بخورد. مثلاً، ممکن است Replicaها نتوانند به‌درستی احراز هویت شوند اگر کاربر Source از روش احراز هویتِ پشتیبانینشده‌ای استفاده کند.

می‌توانید پلاگین احراز هویتِ استفاده‌شده توسط کاربر Replication را با این دستور تأیید کنید:

SELECT user, host, plugin FROM mysql.user;

در صورت لزوم، کاربر Replication را با یک پلاگین احراز هویت سازگار مثل mysql_native_password دوباره بسازید.

تشخیص مشکلات Replication

هنگام عیب‌یابیِ Replication، دستور SHOW REPLICA STATUS\G مهم‌ترین ابزار تشخیصی است. این دستور اطلاعات دقیقی درباره فرایند Replication فراهم می‌کند؛ شامل جزئیات اتصال، موقعیت‌های لاگ، وضعیت نخ‌ها و پیام‌های خطا.

فیلدهای مهم برای بررسی عبارت‌اند از:

• Replica_IO_Running
• Replica_SQL_Running
• Last_IO_Error
• Last_SQL_Error
• Seconds_Behind_Source

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

با بازبینی سیستماتیکِ تنظیمات پیکربندی، بررسی وضعیت Replication و تأیید اتصال شبکه، بیشتر مشکلات Replication می‌توانند سریع تشخیص و رفع شوند. مانیتورینگ مناسب و تست منظم وضعیت Replication، شیوه‌های ضروری برای نگهداری یک محیط Replication مربوط به MySQLِ قابل‌اتکا و سازگار هستند.

سوالات متداول

۱. Replication در MySQL چیست؟

Replication در MySQL قابلیتی است که اجازه می‌دهد داده‌های یک سرور MySQL به‌طور خودکار به یک یا چند سرور دیگر کپی شوند. سروری که در ابتدا تغییرات داده را پردازش می‌کند، Source (که گاهی Primary هم نامیده می‌شود) نام دارد؛ درحالی‌که سرورهایی که آن تغییرات را دریافت و اعمال می‌کنند، Replica نامیده می‌شوند.

Replication با ثبت تغییرات پایگاه داده در Binary Log روی سرور Source کار می‌کند. سرورهای Replica این رویدادها را خوانده و به‌صورت محلی اعمال می‌کنند تا مطمئن شوند داده‌ها همگام باقی می‌مانند. Replication معمولاً برای دسترس‌پذیری بالا، بکاپ‌گیری، افزونگی داده، مقیاس‌دهی خواندن و بازیابی از فاجعه استفاده می‌شود.

۲. تفاوت سرورهای Source و Replica چیست؟

سرور Source اینستنس MySQLای است که عملیات‌های نوشتن روی آن رخ می‌دهند. همه تغییرات داده — مانند دستورات INSERT و UPDATE و DELETE — روی Source اجرا شده و در Binary Log ثبت می‌شوند.

سرور Replica این رویدادهای ثبت‌شده را از Source دریافت کرده و به‌صورت محلی دوباره اجرا می‌کند تا نسخه یکسانی از داده را نگه دارد. Replicaها معمولاً بارهای کاری فقط-خواندنی را هندل می‌کنند — مانند گزارش‌گیری، تحلیل یا کوئری‌های خواندنِ اپلیکیشن — درحالی‌که Source عملیات‌های نوشتن را هندل می‌کند.

۳. آیا Replication در MySQL کارایی را بهبود می‌دهد؟

Replication می‌تواند کارایی کلی سیستم را بهبود بدهد؛ اما نه با سریع‌تر کردنِ تک‌تک کوئری‌ها. به‌جای آن، با توزیع بارهای کاری، مقیاس‌پذیری را بهبود می‌دهد.

مثلاً، عملیات‌های نوشتن همچنان روی سرور Source رخ می‌دهند؛ درحالی‌که کوئری‌های خواندن می‌توانند به سرورهای Replica مسیریابی شوند. این کار بارِ Source را کاهش داده و به اپلیکیشن‌ها اجازه می‌دهد ترافیک بیشتری را هندل کنند. Replication همچنین Replicaهای اختصاصی برای تحلیل یا بکاپ‌گیری را ممکن می‌سازد تا این عملیات‌ها روی کارایی پایگاه داده Source تأثیر نگذارند.

۴. تأخیر Replication در MySQL چیست؟

تأخیر Replication به فاصله زمانی بین ایجاد یک تغییر روی سرور Source و اعمال آن تغییر روی سرور Replica اشاره دارد. این موضوع به این دلیل رخ می‌دهد که Replication به‌صورت پیش‌فرض Asynchronous است؛ یعنی Replicaها رویدادها را کمی بعد از وقوع پردازش می‌کنند.

تأخیر می‌تواند به دلیل حجم‌های بالای نوشتن، تأخیر شبکه، کارایی کند دیسک یا بارهای کاری سنگین روی Replica رخ بدهد. اگر تأخیر چشمگیر شود، ‏Replicaها ممکن است موقتاً داده کهنه سرو کنند؛ که می‌تواند روی اپلیکیشن‌هایی که به سازگاری داده در زمان واقعی متکی‌اند تأثیر بگذارد.

۵. چطور وضعیت Replication را در MySQL بررسی کنیم؟

می‌توانید وضعیت Replication را روی سرور Replica با دستور زیر بررسی کنید:

SHOW REPLICA STATUS\G;

این دستور اطلاعات دقیقی درباره فرایند Replication نمایش می‌دهد؛ شامل وضعیت اتصال به سرور Source، موقعیت در Binary Log و اینکه نخ‌های Replication در حال اجرا هستند یا نه. فیلدهای مهم برای مانیتور شامل Replica_IO_Running و Replica_SQL_Running و Seconds_Behind_Source — که تأخیر فعلی Replication را نشان می‌دهد — هستند.

۶. آیا Replication در MySQL با SSL قابل امن‌سازی است؟

بله، Replication در MySQL را می‌توان با رمزنگاری SSL/TLS امن کرد. وقتی SSL فعال باشد، داده منتقل‌شده بین سرورهای Source و Replica رمزنگاری شده و از intercept یا دستکاری محافظت می‌شود.

برای پیکربندی Replication امن، هر دو سرور باید با گواهی‌های SSL پیکربندی شده و کاربر Replication باید با گزینه‌های SSL مانند SOURCE_SSL=1 در پیکربندی Replication متصل شود. این رویکرد وقتی Replication روی شبکه‌های غیرقابل‌اعتماد انجام می‌شود، توصیه می‌شود.

۷. Replication مبتنی بر GTID در MySQL چیست؟

Replication مبتنی بر GTID از شناسه‌های تراکنش سراسری (GTID) برای ردیابی تراکنش‌ها بین سرورها استفاده می‌کند. هر تراکنشِ اجراشده روی سرور Source یک GTID یکتا دریافت می‌کند؛ که به Replicaها اجازه می‌دهد دقیقاً تشخیص بدهند کدام تراکنش‌ها را قبلاً پردازش کرده‌اند.

این روش مدیریت Replication را ساده می‌کند؛ چون Replicaها دیگر لازم نیست نام فایل‌ها و موقعیت‌های Binary Log را ردیابی کنند. GTIDها همچنین کارهایی مثل Failover، ارتقای Replica و همگام‌سازی مجدد را راحت‌تر و کم‌خطاتر می‌کنند؛ که دلیل محبوبیت Replication مبتنی بر GTID در استقرارهای مدرن MySQL است.

۸. آیا یک Replica در MySQL می‌تواند Source شود؟

بله، یک Replica در MySQL می‌تواند برای تبدیل شدن به سرور Source ارتقا یابد. این فرایند معمولاً در طول Failover رخ می‌دهد؛ وقتی Source اصلی در دسترس نیست یا نیازمند نگهداری است.

برای ارتقای یک Replica، ‏Replication متوقف شده و Replica شروع به پذیرش عملیات‌های نوشتن می‌کند. سپس Replicaهای دیگر می‌توانند طوری بازپیکربندی شوند که از Source جدید Replicate کنند. بسیاری از سیستم‌های دسترس‌پذیری بالا و ابزارهای ارکستراسیون این فرایند را خودکار می‌کنند تا Downtime کمینه و دسترس‌پذیری پیوسته پایگاه داده تضمین شود.

جمع‌بندی

با تکمیل این آموزش، یک محیط Replication در MySQL راه‌اندازی کرده‌اید که از روش Replication مبتنی بر موقعیت فایل Binary Log مربوط به MySQL با یک Source و یک Replica استفاده می‌کند. در نظر داشته باشید که رویه تشریح‌شده در این راهنما فقط یکی از راه‌های پیکربندی Replication در MySQL است. MySQL گزینه‌های مختلفی از Replication فراهم می‌کند که می‌توانید از آن‌ها برای تولید محیطی بهینه برای نیازهای خود استفاده کنید. همچنین تعدادی ابزار شخص ثالث — مانند Galera Cluster — وجود دارند که می‌توانید از آن‌ها برای گسترش قابلیت‌های داخلی Replication مربوط به MySQL استفاده کنید.