نحوه راه‌اندازی همتاسازی (Replication) در MySQL

کیانا3 ساعت پیش

0 1 خواندن این مطلب 25 دقیقه زمان میبرد

مقدمه

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

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

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

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

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

نکات کلیدی

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

پیش‌نیازها

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

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

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

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

دستور سرور منبع

به‌طور مشابه، هر دستوری که باید روی سرورِ instance ریپلیکای MySQL اجرا شود، پس‌زمینه قرمز دارد:

دستور سرور ریپلیکا

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

درک همتاسازی در MySQL

در MySQL، همتاسازی شامل این است که دیتابیس منبع هر تغییری که روی داده‌های درون یک یا چند دیتابیس اعمال می‌شود را در فایل خاصی به نام لاگ باینری می‌نویسد. وقتی instance ریپلیکا مقداردهی اولیه شد، دو فرایند تردی (Thread) می‌سازد. اولی، ترد IO نامیده می‌شود؛ به instance منبع MySQL وصل می‌شود، رویدادهای لاگ باینری را خط به خط می‌خواند و آن‌ها را به فایل محلی‌ای روی سرور ریپلیکا به نام Relay Log کپی می‌کند. ترد دوم، ترد SQL نامیده می‌شود؛ رویدادها را از Relay Log می‌خواند و سپس آن‌ها را تا جای ممکن سریع روی instance ریپلیکا اعمال می‌کند.

نسخه‌های اخیر MySQL دو روش برای همتاسازی داده‌ها را پشتیبانی می‌کنند. تفاوت بین این روش‌های همتاسازی به نحوه ردیابی ریپلیکاها برمی‌گردد؛ اینکه کدام رویدادهای دیتابیس از منبع را قبلاً پردازش کرده‌اند.

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

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

همتاسازی مبتنی بر موقعیت فایل لاگ باینری برای بسیاری از موارد استفاده عملی است؛ اما این روش در راه‌اندازی‌های پیچیده‌تر می‌تواند نحیف/زشت شود. این به توسعه روش همتاسازی نیتیو جدیدتر MySQL منجر شد؛ که گاهی همتاسازی مبتنی بر تراکنش نامیده می‌شود. این روش شامل ساخت شناسه تراکنش سراسری (GTID) به ازای هر تراکنش—یا قطعه ایزوله‌ای از کار که توسط دیتابیس انجام می‌شود—است که instance منبع MySQL اجرا می‌کند.

سازوکار همتاسازی مبتنی بر تراکنش شبیه همتاسازی مبتنی بر فایل لاگ باینری است: هر وقت تراکنش دیتابیسی روی منبع رخ می‌دهد، MySQL یک GTID برای تراکنش اختصاص و ثبت می‌کند—در فایل لاگ باینری همراه خود تراکنش. سپس GTID و تراکنش به ریپلیکاهای منبع منتقل می‌شوند تا پردازش‌شان کنند.

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

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

گام ۱ — تنظیم فایروال سرور منبع

با فرض اینکه راهنمای راه‌اندازی اولیه سرور را دنبال کرده‌اید، فایروالی با UFW روی هر دو سرورتان پیکربندی کرده‌اید. این کمک می‌کند هر دو سرور امن بمانند؛ اما فایروال سرور منبع، تلاش‌های اتصال از instance ریپلیکای شما را بلاک خواهد کرد.

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

این دستور خاص، هر اتصالی که از آدرس IP سرور ریپلیکا—نمایش‌داده‌شده با replica_server_ip—منشأ بگیرد به شماره پورت پیش‌فرض MySQL یعنی ۳۳۰۶ را مجاز می‌داند:

sudo ufw allow from replica_server_ip to any port 3306

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

Output
Rule added

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

گام ۲ — پیکربندی دیتابیس منبع

برای اینکه دیتابیس منبع MySQL شروع به همتاسازی داده‌ها کند، باید چند تغییری در پیکربندی‌اش بدهید.

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

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

درون فایل، دایرکتیو 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 گوش بدهد. به بیان دیگر، این instance MySQL فقط قادر به پذیرش اتصالاتی خواهد بود که از سروری که رویش نصب شده منشأ می‌گیرند.

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

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
bind-address            = source_server_ip
. . .

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
# server-id             = 1
. . .

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
server-id               = 1
. . .

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

وقتی کامنت شده—مثل پیش‌فرض این دایرکتیو—لاگینگ باینری غیرفعال است. سرور ریپلیکای شما باید فایل لاگ باینری منبع را بخواند تا بداند کِی و چگونه داده‌های منبع را همتاسازی کند؛ پس این خط را برای فعال کردن لاگینگ باینری روی منبع از کامنت دربیاورید. بعد از این کار، این‌طور خواهد بود:

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
log_bin                       = /var/log/mysql/mysql-bin.log
. . .

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
# binlog_do_db          = include_database_name

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
binlog_do_db          = db

نکته: اگر می‌خواهید بیش از یک دیتابیس را همتاسازی کنید، می‌توانید دایرکتیو binlog_do_db به ازای هر دیتابیسی که می‌خواهید همتاسازی کنید اضافه کنید. این آموزش با همتاسازی فقط یک دیتابیس منفرد ادامه می‌یابد؛ اما اگر می‌خواستید بیش از یکی را همتاسازی کنید، ممکن بود این‌طور باشد:
. . .
binlog_do_db          = db
binlog_do_db          = db_1
binlog_do_db          = db_2
به‌عنوان جایگزین، می‌توانید تعیین کنید MySQL کدام دیتابیس‌ها را نباید همتاسازی کند با افزودن دایرکتیو binlog_ignore_db به ازای هر کدام:
. . .
binlog_ignore_db          = db_to_ignore

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

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

sudo systemctl restart mysql

با این، این instance MySQL آماده عمل کردن به‌عنوان دیتابیس منبعی است که سرور MySQL دیگرتان از آن همتاسازی خواهد کرد. قبل از اینکه بتوانید ریپلیکایتان را پیکربندی کنید اما، هنوز چند قدم دیگر هست که باید روی منبع انجام دهید تا تضمین کنید توپولوژی همتاسازی‌تان درست کار خواهد کرد. اولین این‌ها، ساخت کاربر اختصاصی MySQL است که هر اقدام مرتبط با فرایند همتاسازی را انجام می‌دهد.

گام ۳ — ساخت کاربر همتاسازی

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

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

sudo mysql

نکته: اگر کاربر اختصاصی MySQLای پیکربندی کرده‌اید که با رمز عبور احراز هویت می‌شود، می‌توانید با دستوری مثل این به MySQL وصل شوید:
mysql -u sammy -p
sammy را با نام کاربر اختصاصی‌تان جایگزین و رمز عبور این کاربر را هنگام درخواست وارد کنید.

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

از پرامپت، کاربر جدید MySQL بسازید. مثال زیر کاربری به نام replica_user می‌سازد؛ اما می‌توانید هر چه دوست دارید نامش را بگذارید. حتماً replica_server_ip را با آدرس IP عمومی سرور ریپلیکایتان و password را با رمز عبور قوی به انتخاب خودتان تغییر دهید:

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

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

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

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

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

FLUSH PRIVILEGES;

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

گام ۴ — بازیابی مختصات لاگ باینری از منبع

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

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

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

FLUSH TABLES WITH READ LOCK;

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

SHOW BINARY LOG STATUS;

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

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

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

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

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

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

UNLOCK TABLES;

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

CREATE DATABASE db;

Output
Query OK, 1 row affected (0.01 sec)

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

exit

بعد از این، می‌توانید به گام ۵ بروید.

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

اگر داده‌ای روی instance منبع MySQL دارید که می‌خواهید به ریپلیکاها مهاجرت دهید، می‌توانید با ساخت اسنپ‌شات دیتابیس با ابزار mysqldump این کار را بکنید. اما دیتابیس‌تان باید هنوز قفل باشد. اگر هر تغییری در همان پنجره بدهید، دیتابیس خودکار باز می‌شود. به‌طور مشابه، جداول اگر از کلاینت خارج شوید خودکار باز می‌شوند.

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

به همین دلیل، باید پنجره یا تب ترمینال جدیدی روی ماشین محلی‌تان باز کنید تا بتوانید اسنپ‌شات دیتابیس را بدون باز کردن MySQL بسازید.

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

ssh sammy@source_server_ip

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

sudo mysqldump -u root db > db.sql

بعد از این، می‌توانید این پنجره یا تب ترمینال را ببندید و به اولی برگردید؛ که باید هنوز شل MySQL باز داشته باشد. از پرامپت MySQL، جداول را باز کنید تا دوباره قابل نوشتن شوند:

UNLOCK TABLES;

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

exit

حالا می‌توانید فایل اسنپ‌شات‌تان را به سرور ریپلیکا بفرستید. با فرض اینکه کلیدهای SSH را روی سرور منبع پیکربندی کرده و کلید عمومی منبع را به فایل authorized_keys ریپلیکا اضافه کرده‌اید، می‌توانید این کار را امن با دستور scpای مثل این بکنید:

scp db.sql sammy@replica_server_ip:/tmp/

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

بعد از ارسال اسنپ‌شات به سرور ریپلیکا، به آن SSH بزنید:

ssh sammy@replica_server_ip

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

sudo mysql

از پرامپت، دیتابیس جدیدی را که از منبع همتاسازی خواهید کرد بسازید:

CREATE DATABASE db;

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

exit

سپس اسنپ‌شات دیتابیس را ایمپورت کنید:

sudo mysql db < /tmp/db.sql

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

گام ۵ — پیکربندی دیتابیس ریپلیکا

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

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

همان‌طور که قبلاً اشاره شد، هر instance MySQL در راه‌اندازی همتاسازی باید مقدار server-id یکتا داشته باشد. دایرکتیو server-id ریپلیکا را پیدا، از کامنت دربیاورید و مقدارش را به هر عدد صحیح مثبتی تغییر دهید؛ تا وقتی که با مقدار منبع متفاوت باشد:

/etc/mysql/mysql.conf.d/mysqld.cnf
server-id               = 2

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
log_bin                 = /var/log/mysql/mysql-bin.log
. . .
binlog_do_db            = db
. . .

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

/etc/mysql/mysql.conf.d/mysqld.cnf
. . .
relay-log               = /var/log/mysql/mysql-relay-bin.log

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

sudo systemctl restart mysql

بعد از ری‌استارت سرویس mysql، بالاخره آماده شروع همتاسازی داده‌ها از دیتابیس منبع‌تان هستید.

گام ۶ — شروع و تست همتاسازی

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

sudo mysql

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

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

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

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;

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

START REPLICA;

اگر همه جزئیات را درست وارد کرده باشید، این instance شروع به همتاسازی هر تغییری که روی دیتابیس db در منبع اعمال می‌شود خواهد کرد.

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

SHOW REPLICA STATUS\G;

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

Output
*************************** 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
. . .

نکته: اگر ریپلیکایتان در اتصال مشکل دارد یا همتاسازی به‌طور غیرمنتظره متوقف می‌شود، ممکن است رویدادی در فایل لاگ باینری منبع جلوی همتاسازی را گرفته باشد. در چنین مواردی، می‌توانستید دستور SET GLOBAL SQL_REPLICA_SKIP_COUNTER را برای رد کردن تعداد مشخصی از رویدادها بعد از موقعیت فایل لاگ باینری‌ای که در دستور قبلی تعریف کردید، اجرا کنید. این مثال فقط اولین رویداد را رد می‌کند:
SET GLOBAL SQL_REPLICA_SKIP_COUNTER = 1;
بعد از آن، باید ریپلیکا را دوباره شروع کنید:
START REPLICA;

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

STOP REPLICA;

ریپلیکای شما حالا در حال همتاسازی داده‌ها از منبع است. هر تغییری که روی دیتابیس منبع بدهید، روی instance ریپلیکای MySQL منعکس خواهد شد. می‌توانید این را با ساخت جدول نمونه روی دیتابیس منبع و چک کردن اینکه با موفقیت همتاسازی می‌شود، تست کنید.

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

sudo mysql

دیتابیسی را که انتخاب کردید همتاسازی کنید، انتخاب کنید:

USE db;

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

CREATE TABLE example_table (
  example_column VARCHAR(30)
);

Output
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');

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

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

USE db;

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

SHOW TABLES;

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

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

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

SELECT * FROM example_table;

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

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

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

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

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

ریپلیکا نمی‌تواند به سرور منبع وصل شود

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

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

اول، تأیید کنید که سرور منبع اتصالات از آدرس IP ریپلیکا را مجاز می‌داند. اگر فایروالی مثل UFW فعال است، تأیید کنید پورت ۳۳۰۶ برای سرور ریپلیکا باز است. مثلاً:

sudo ufw allow from replica_server_ip to any port 3306

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

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

تردهای همتاسازی در حال اجرا نیستند

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

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

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

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

SHOW REPLICA STATUS\G;

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

Replica_IO_Running
Replica_SQL_Running

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

برای شروع مجدد همتاسازی بعد از اصلاح مشکل، اجرا کنید:

START REPLICA;

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

مختصات لاگ باینری نادرست

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

مختصات درست لاگ باینری را می‌توانید روی سرور منبع با این تأیید کنید:

SHOW BINARY LOG STATUS;

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

File
Position

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

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

STOP REPLICA;

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

START REPLICA;

همتاسازی به‌دلیل عدم سازگاری داده متوقف شده

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

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

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

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

SET GLOBAL SQL_REPLICA_SKIP_COUNTER = 1;
START REPLICA;

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

تأخیر همتاسازی (Replication Lag)

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

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

SHOW REPLICA STATUS\G;

علل رایج تأخیر شامل:

بارهای کاری نوشتنِ سنگین روی منبع
کارایی کند دیسک روی ریپلیکا
تأخیر شبکه
محدودیت‌های منابع مثل CPU یا حافظه

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

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

لاگینگ باینری روی منبع فعال نیست

همتاسازی به لاگینگ باینری برای ثبت تغییرات دیتابیس متکی است. اگر دایرکتیو log_bin روی سرور منبع غیرفعال باشد، ریپلیکاها هیچ به‌روزرسانی دریافت نمی‌کنند.

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

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

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

sudo systemctl restart mysql

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

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

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

SELECT user, host, plugin FROM mysql.user;

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

تشخیص مسائل همتاسازی

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

فیلدهای مهم برای بررسی شامل:

Replica_IO_Running
Replica_SQL_Running
Last_IO_Error
Last_SQL_Error
Seconds_Behind_Source

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

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

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

۱. همتاسازی MySQL چیست؟

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

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

۲. تفاوت سرورهای منبع و ریپلیکا چیست؟

سرور منبع، instanceای MySQL است که عملیات‌های نوشتن رویش رخ می‌دهند. همه تغییرات داده—مثل دستورات INSERT، UPDATE و DELETE—روی منبع اجرا و در لاگ باینری ثبت می‌شوند.

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

۳. آیا همتاسازی MySQL کارایی را بهبود می‌بخشد؟

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

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

۴. تأخیر همتاسازی در MySQL چیست؟

تأخیر همتاسازی به فاصله زمانی بین وقتی که تغییری روی سرور منبع داده می‌شود و وقتی که آن تغییر روی سرور ریپلیکا اعمال می‌شود، اشاره دارد. این به این دلیل رخ می‌دهد که همتاسازی به‌طور پیش‌فرض asynchronous است؛ یعنی ریپلیکاها رویدادها را کمی بعد از وقوع پردازش می‌کنند.

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

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

وضعیت همتاسازی را می‌توانید روی سرور ریپلیکا با دستور زیر چک کنید:

SHOW REPLICA STATUS\G;

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

۶. آیا همتاسازی MySQL را می‌توان با SSL امن کرد؟

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

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

۷. همتاسازی مبتنی بر GTID در MySQL چیست؟

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

این روش مدیریت همتاسازی را ساده می‌کند؛ چون ریپلیکاها دیگر لازم نیست نام‌ها و موقعیت‌های فایل لاگ باینری را ردیابی کنند. GTIDها هم وظایفی مثل Failover، ارتقای ریپلیکا (Promotion) و همگام‌سازی مجدد را آسان‌تر و کم‌خطاتر می‌کنند؛ که دلیل رایج بودن همتاسازی GTID در دیپلوی‌های مدرن MySQL است.

۸. آیا ریپلیکای MySQL می‌تواند منبع شود؟

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

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

نتیجه‌گیری

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

اگر سوالات بیشتری درباره قابلیت‌های خاص همتاسازی در MySQL دارید، تشویق می‌شوید مستندات رسمی MySQL در این موضوع را ببینید.