Replication در MySQL چیست؟ راه اندازی replication master-slave در MySQL راه اندازی Replication پایگاه داده Mysql به روش سنتی

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

یک مقدمه کوتاه

• عملکرد و مقیاس پذیری. ممکن است یک سرور نتواند بار ناشی از عملیات خواندن و نوشتن همزمان در پایگاه داده را مدیریت کند. مزایای ایجاد کپی بیشتر خواهد بود هر چه تعداد خواندن در هر نوشتن در سیستم شما بیشتر باشد.
• تحمل خطا. در صورت خرابی replica، تمام درخواست های خواندن می توانند با خیال راحت به Master منتقل شوند. اگر Master ناموفق باشد، درخواست‌های نوشتن را می‌توان به replica منتقل کرد (پس از بازیابی Master، می‌تواند نقش Replica را بر عهده بگیرد).
• فایل پشتیبانی اطلاعات. Replica را می توان برای مدتی "آهسته" کرد تا mysqldump را انجام دهد، اما master نمی تواند.
• محاسبات معوق. پرس و جوهای سنگین و کند SQL را می توان بدون ترس از تداخل بر روی یک ماکت جداگانه اجرا کرد. عملکرد عادیکل سیستم

راه اندازی Replication

• آدرس IP اصلی 192.168.1.101، نسخه های مشابه 192.168.1.102 است.
• MySQL نصب و پیکربندی شد
• شما باید Replication پایگاه داده testdb را پیکربندی کنید
• ما می توانیم جادوگر را برای مدتی مکث کنیم
• ما البته روی هر دو دستگاه روت داریم

تنظیمات جادوگر

بیایید کاربر replication را اضافه کنیم که تحت حقوق آن Replication انجام خواهد شد. امتیاز "Replication Slave" کافی است:
mysql@master> GRANT Replication Slave ON "testdb".* TO "replication"@"192.168.1.102" شناسایی شده با "password";

برای اعمال تغییرات در پیکربندی، MySQL را ریبوت کنید:
سرویس root@master# راه اندازی مجدد mysqld

اگر همه چیز خوب پیش رفت، دستور "show master status" باید چیزی شبیه به این را نشان دهد:
mysql@master> SHOW MASTER STATUS\G
فایل: mysql-bin.000003
سمت: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
با ایجاد تغییرات در پایگاه داده روی master، مقدار موقعیت باید افزایش یابد.

تنظیمات کپی

سرویس Root@replica# راه اندازی مجدد mysqld

انتقال داده

بیایید وضعیت استاد را با دستور "show master status" ببینیم و مقادیر File و Position را به خاطر بسپاریم (پس از مسدود کردن موفقیت آمیز master، آنها نباید تغییر کنند):
فایل: mysql-bin.000003
سمت: 98

پایگاه داده را تخلیه می کنیم و پس از اتمام عملیات، قفل master را حذف می کنیم:
mysql@master> SET GLOBAL read_only = OFF;

Dump را به replica منتقل می کنیم و داده ها را از آن بازیابی می کنیم.
در نهایت، ما تکرار را با دستورات “change master to” و “start slave” شروع می کنیم و می بینیم که آیا همه چیز به خوبی پیش رفته است:
mysql@replica> CHANGE MASTER TO MASTER_HOST = "192.168.1.101"، MASTER_USER = "تکرار"، MASTER_PASSWORD = "گذرواژه"، MASTER_LOG_FILE = "mysql-bin.000003"، MASTER_9;
mysql@replica> start slave.
ما مقادیر MASTER_LOG_FILE و MASTER_LOG_POS را از master می گیریم.

بیایید ببینیم که تکرار با دستور "show Slave status" چگونه پیش می رود:
mysql@replica> نشان دادن وضعیت برده\G
Slave_IO_State: در انتظار استاد برای ارسال رویداد
Master_Host: 192.168.1.101
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: بله
Slave_SQL_Running: بله
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log Space: 235
Until_Condition: ندارد
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: خیر
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
ثانیه_پشت_استاد: 5

اکنون جالب ترین ارزش ها را برجسته کرده ام. اگر تکرار با موفقیت شروع شود، مقادیر آنها باید تقریباً مشابه فهرست باشد (توضیح دستور "show status slave" را در مستندات ببینید). مقدار Seconds_Behind_Master می تواند هر عدد صحیحی باشد.
اگر تکرار نرمال باشد، replica از master پیروی می کند (شماره گزارش در Master_Log_File و موقعیت Exec_Master_Log_Pos افزایش می یابد). زمان تاخیر ماکت از استاد (Seconds_Behind_Master)، در حالت ایده آل، باید برابر با صفر باشد. اگر کاهش پیدا نکند یا رشد نکند، ممکن است بار روی ماکت خیلی زیاد باشد - به سادگی زمان لازم برای تکرار تغییرات روی master را ندارد.
اگر Slave_IO_State خالی و Seconds_Behind_Master NULL باشد، تکرار شروع نشده است. برای پیدا کردن دلیل، حذف آن و شروع مجدد، به گزارش MySQL مراجعه کنید:
mysql@replica> start slave.

از طریق این مراحل ساده ما یک ماکت به دست می آوریم که داده های آن با داده های اصلی یکسان است.
به هر حال، زمانی که Master مسدود می شود، زمانی است که dump ایجاد می شود. اگر ایجاد زمان غیرقابل قبولی طول می کشد، می توانید این را امتحان کنید:

• با علامت read_only نوشتن به master را مسدود کنید، موقعیت را به خاطر بسپارید و MySQL را متوقف کنید.
• پس از آن، فایل های پایگاه داده را در replica کپی کنید و Master را فعال کنید.
• همانند سازی را به روش معمول شروع کنید.

اضافه کردن ماکت

حالا بیایید تکرار را روی ماکت اول متوقف کنیم:
mysql@replica-1> stop slave.

ماکت به طور معمول به کار خود ادامه می دهد، اما داده های موجود در آن دیگر جاری نخواهد بود. بیایید به وضعیت نگاه کنیم و موقعیت اصلی را که ماکت قبل از توقف تکرار به آن رسیده است، به خاطر بسپاریم:
mysql@replica-1> نشان دادن وضعیت برده\G

مقادیری که ما نیاز داریم Master_Log_File و Exec_Master_Log_Pos خواهند بود:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

بیایید یک Dump پایگاه داده ایجاد کنیم و همانند سازی را در اولین ماکت ادامه دهیم:
mysql@replica-1> START SLAVE.

بیایید داده ها را از Dump روی ماکت دوم بازیابی کنیم. سپس Replication را فعال کنید:
mysql@replica-2> CHANGE MASTER TO MASTER_HOST = "192.168.1.101"، MASTER_USER = "تکرار"، MASTER_PASSWORD = "گذرواژه"، MASTER_LOG_FILE = "mysql-bin.000004"، MASTER = "MASTER_BIN.000004"، MASTER_5.
mysql@replica-2> START SLAVE.

مقادیر MASTER_LOG_FILE و MASTER_LOG_POS به ترتیب مقادیر Master_Log_File و Exec_Master_Log_Pos هستند که از نتیجه دستور "show slave status" در اولین ماکت به دست می آیند.
همانند سازی باید از موقعیتی که اولین ماکت متوقف شده است شروع شود (و بر این اساس، یک روگرفت ایجاد می شود). بنابراین، ما دو کپی با داده های یکسان خواهیم داشت.

ادغام کپی ها

بیایید یک Dump از پایگاه داده testdb2 ایجاد کنیم و تکرار را از سر بگیریم (این کار دستکاری ها را با replica-2 کامل می کند). ما Dump را به replica-1 بازیابی می کنیم.

وضعیت روی replica-1 به این صورت است: پایگاه داده testdb1 در یک موقعیت اصلی قرار دارد و به تکرار ادامه می‌دهد، پایگاه داده testdb2 از یک تخلیه از یک موقعیت دیگر بازیابی شده است. بیایید آنها را همگام کنیم.

بیایید تکرار را متوقف کنیم و موقعیت استاد را به خاطر بسپاریم:
mysql@replica-1> STOP SLAVE.
mysql@replica-1> نشان دادن وضعیت برده\G
Exec_Master_Log_Pos: 501

بیایید مطمئن شویم که در پیکربندی برای replica-1 نام پایگاه داده دوم در بخش نشان داده شده است:
replicate-do-db = testdb2

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

حالا بیایید از موقعیتی که replica-2 متوقف شده بود به موقعیتی که فقط تکرار را متوقف کردیم، تکرار کنیم:
mysql@replica-1> CHANGE MASTER TO MASTER_HOST = "192.168.1.101"، MASTER_USER = "replication"، MASTER_PASSWORD = "password"، MASTER_LOG_FILE = "mysql-bin.000015"، MASTER =
mysql@replica-1> start slave تا MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;

به محض اینکه replica به موقعیت مشخص شده در بخش while برسد، Replication به پایان می رسد، پس از آن هر دو پایگاه داده ما با موقعیت اصلی یکسانی مطابقت خواهند داشت (که در آن تکرار را در replica-1 متوقف کردیم). بیایید از این مطمئن شویم:
mysql@replica-1> نشان دادن وضعیت برده\G
mysql@replica-1> START SLAVE.
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

بیایید نام هر دو پایگاه داده را به پیکربندی برای replica-1 در بخش اضافه کنیم:
replicate-do-db = testdb1
replicate-do-db = testdb2

مهم: هر پایگاه داده باید در یک خط جداگانه فهرست شود.
MySQL را مجدداً راه اندازی کنید و به تکرار ادامه دهید:
mysql@replica-1> CHANGE MASTER TO MASTER_HOST = "192.168.1.101"، MASTER_USER = "تکرار"، MASTER_PASSWORD = "گذرواژه"، MASTER_LOG_FILE = "mysql-bin.000016"، MASTER = MASTER
پس از اینکه replica-1 با Master آشنا شد، محتویات پایگاه داده آنها یکسان خواهد بود. شما می توانید پایگاه داده را به روشی مشابه یا با ایجاد یک تخلیه کامل از replica-1 در replica-2 ادغام کنید.

استاد قلعه سازی و ماکت

بیایید ثبت باینری (علاوه بر binlog های رله) را در پیکربندی در بخش فعال کنیم:
log-bin = /var/lib/mysql/mysql-bin

و یک کاربر برای تکرار اضافه کنید:
mysql@master> GRANT Replication Slave ON 'testdb'.* TO 'replication'@'192.168.1.101' شناسایی شده توسط "password";

مستر غیرفعال مانند یک ماکت معمولی همانندسازی را انجام می دهد، اما علاوه بر این، منطق های باینری ایجاد می کند - یعنی می توانیم از آن همانندسازی را شروع کنیم. بیایید این را با دستور "show master status" تأیید کنیم:
mysql@replica> SHOW MASTER STATUS\G
فایل: mysql-bin.000001
موقعیت: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

حال برای اینکه Master Passive را به حالت Active تغییر دهید، باید Replication را روی آن متوقف کنید و Replication را در Master Active سابق فعال کنید. برای اطمینان از اینکه داده ها در زمان سوئیچ از بین نمی روند، استاد فعالباید قفل نوشتن باشد.
mysql@master> FLASH TABLEها با قفل خواندن
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE.
mysql@replica> نشان دادن وضعیت استاد؛
فایل: mysql-bin.000001
موقعیت: 61
mysql@master> CHANGE MASTER TO MASTER_HOST = "192.168.1.102"، MASTER_USER = "Replication"، MASTER_PASSWORD = "password"، MASTER_LOG_FILE = "mysql-bin.000001"، MASTER_LOG1;
mysql@master> start slave.
تمام است، بنابراین ما استاد فعال را تغییر دادیم. می توانید بلوک را از استاد سابق حذف کنید.

نتیجه

ما کمی در مورد نحوه راه اندازی Replication در MySQL و انجام برخی از عملیات های اساسی یاد گرفته ایم. متأسفانه سؤالات مهم زیر از حوصله این مقاله خارج است:

• حذف نقاط شکست منفرد (SPF، Single Points of Failure). هنگام استفاده از یک سرور MySQL، شکست آن منجر به از کار افتادن کل سیستم شد. هنگام استفاده از چندین سرور، خرابی هر یک از آنها منجر به خرابی سیستم می شود، مگر اینکه ما به طور خاص به این موضوع رسیدگی کنیم. ما باید برای رسیدگی به وضعیت با شکست استاد و ماکت فراهم کنیم. یکی از ابزارهای موجود MMM است، اما نیاز به اصلاح با یک فایل دارد.
• متعادل سازی بار هنگام استفاده از چندین ماکت، مایلیم از مکانیزم متعادل کننده شفاف استفاده کنیم، به خصوص اگر عملکرد ماکت ها ناهموار باشد. قابل استفاده در لینوکس راه حل استاندارد- LVS.
• تغییر منطق برنامه در یک موقعیت ایده آل، درخواست های خواندن داده ها باید به نسخه های تکراری ارسال شوند و درخواست ها برای تغییر داده ها باید به Master ارسال شوند. با این حال، به دلیل تأخیر احتمالی نسخه‌ها، چنین طرحی اغلب ناکارآمد است و لازم است چنین درخواست‌های خواندنی که هنوز باید روی Master اجرا شوند، شناسایی شوند.

در اینجا توضیح مختصری در مورد نحوه تنظیم نسخه کامل سرور MySQL ارائه شده است. فرض بر این است که همه پایگاه‌های داده تکرار خواهند شد و تکرار قبلاً پیکربندی نشده است. برای تکمیل مراحل در اینجا، باید سرور هد را برای مدت کوتاهی متوقف کنید.

این ساده ترین راه برای نصب سرور برده است، اما تنها راه نیست. به عنوان مثال، اگر قبلاً تصویری از سرور اصلی وجود داشته باشد، سرور اصلی قبلاً دارای شناسه سرور و ثبت گزارش است، سرور برده می‌تواند بدون توقف سرور اصلی یا حتی تنظیم قفل‌های به‌روزرسانی نصب شود (برای اطلاعات بیشتر به بخش 4.10 مراجعه کنید. .7 سوالات متداول تکرار مکرر.

برای تبدیل شدن به یک مربی واقعی شبیه سازی MySQL، توصیه می کنیم ابتدا تمام دستورات ذکر شده در بخش 4.10.6 دستورات SQL مربوط به Replication را یاد بگیرید، درک کنید و امتحان کنید. همچنین باید گزینه‌های شروع تکثیر از فایل "my.cnf" را در بخش 4.10.5 گزینه‌های تکرار از فایل "my.cnf" مشاهده کنید.

1. مطمئن شوید که آخرین نسخه MySQL بر روی سرور(های) master و slave نصب شده باشد. از نسخه 3.23.29 یا بالاتر استفاده کنید. نسخه‌های قبلی از فرمت گزارش باینری متفاوت استفاده می‌کردند و حاوی اشکالاتی بودند که در نسخه‌های جدیدتر رفع شده‌اند. یک درخواست بزرگ: لطفاً گزارش‌های اشکال را بدون بررسی وجود اشکال در آخرین نسخه ارسال نکنید.
2. یک کاربر تکرار جداگانه روی سرور اصلی با امتیاز FILE (در نسخه‌های MySQL قبل از 4.0.2) یا REPLICATION SLAVE در نسخه‌های جدیدتر MySQL راه‌اندازی کنید. این کاربر همچنین باید مجوز اتصال از همه سرورهای برده را داشته باشد. اگر کاربر فقط تکرار (توصیه می شود) را انجام دهد، دیگر نیازی به اعطای امتیاز اضافی به او نیست. به عنوان مثال، برای ایجاد کاربری به نام repl که می تواند از هر میزبانی به سرور اصلی دسترسی داشته باشد، می توانید از دستور زیر استفاده کنید: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
3. کامل MySQL کار می کندروی سرور اصلی خاموش شدن mysqladmin -u root -p
4. یک تصویر از تمام داده ها در سرور اصلی ایجاد کنید. ساده ترین راه برای انجام این کار (در یونیکس) ایجاد کردن است تاربایگانی کل فهرست اطلاعات شما مکان دقیق دایرکتوری داده به نصب شما بستگی دارد. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir کاربران ویندوز می توانند از WinZIP یا برنامه مشابه دیگری برای ایجاد آرشیو دایرکتوری داده استفاده کنند.
5. در my.cnf روی سرور اصلی، ورودی‌هایی را به بخش ورودی log-bin و server-id=unique را به بخش اضافه کنید و سرور را مجددا راه‌اندازی کنید. بسیار مهم است که شناسه سرور برده با شناسه سرور اصلی متفاوت باشد. می‌توانیم در نظر بگیریم که شناسه سرور نقش یک آدرس IP را بازی می‌کند - سرور را به‌طور منحصربه‌فردی در بین شرکت‌کنندگان تکرار شناسایی می‌کند. log-bin server-id=1
6. MySQL را روی سرور اصلی راه اندازی مجدد کنید.
7. موارد زیر را به my.cnf در سرور(های) برده اضافه کنید: master-host= master-user= master-password= master-port= server-id= جایگزین کردن مقادیر با مقادیر مناسب برای سیستم شما . مقادیر شناسه سرور باید در هر سروری که در تکرار شرکت می کند متفاوت باشد. اگر مقدار server-id تعریف نشده باشد، روی 1 تنظیم می شود، اگر مقدار master-host نیز تعریف نشده باشد، روی 2 تنظیم می شود. توجه داشته باشید که اگر مقدار server-id حذف شود، سرور اصلی اتصال به همه سرورهای برده را رد می کند و سرور برده از اتصال به سرور اصلی خودداری می کند. بنابراین، تنها در صورتی می‌توانید تنظیم مقدار شناسه سرور را حذف کنید که با استفاده از یک گزارش باینری پشتیبان تهیه کنید.
8. داده های عکس فوری را در دایرکتوری داده در سرور(های) برده کپی کنید. مطمئن شوید که امتیازات فایل و دایرکتوری صحیح است. کاربری که MySQL را اجرا می کند باید بتواند داده ها را به همان روشی که در سرور اصلی وجود دارد بخواند و بنویسد.
9. سرور(های) برده را مجددا راه اندازی کنید.

پس از انجام این مراحل، سرور(های) برده باید به سرور اصلی متصل شوند و داده های خود را با تغییراتی که پس از پذیرش تصویر روی سرور اصلی رخ می دهد، تنظیم کنند.

اگر شناسه سرور برای سرور برده تنظیم نشده باشد، خطای زیر ثبت می شود:

هشدار: اگر master_host تنظیم شده باشد باید server_id را روی یک مقدار غیر 0 تنظیم کنید. سرور به عنوان یک برده عمل نمی کند. (هشدار: اگر master_host مشخص شده باشد، server_id باید روی یک مقدار غیر صفر تنظیم شود. سرور به عنوان یک سرور برده عمل نمی کند.)

اگر شناسه سرور اصلی تنظیم نشده باشد، سرورهای برده نمی توانند به سرور اصلی متصل شوند.

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

هنگامی که سرور برده شروع به تکثیر می کند، یک فایل «master.info» در همان فهرست خطا ظاهر می شود. فرآوری شده. این فایل را حذف یا ویرایش نکنید مگر اینکه مطمئن باشید ضروری است. حتی اگر چنین اطمینانی دارید، باز هم بهتر است از دستور CHANGE MASTER TO استفاده کنید.

گزارش من برای کسانی در نظر گرفته شده است که کلمه Replication را می دانند، حتی می دانند که MySQL آن را دارد و شاید یک بار آن را تنظیم کرده و 15 دقیقه وقت گذاشته و آن را فراموش کرده اند. آنها چیز دیگری در مورد او نمی دانند.

گزارش شامل موارد زیر نخواهد بود:

همه اینها در اینترنت است، درک نحو وجود ندارد.

ما کمی تئوری را مرور می‌کنیم، سعی می‌کنیم توضیح دهیم که چگونه همه چیز در داخل کار می‌کند، و بعد از آن می‌توانید خودتان با قدرت سه برابری به مستندات بروید.

در اصل تکثیر چیست؟ این کپی کردن تغییرات است. ما یک کپی از پایگاه داده داریم، ما یک نسخه دیگر را برای برخی اهداف می خواهیم.

تکرار اتفاق می افتد انواع متفاوت. محورهای مقایسه مختلف:

• درجه همگام سازی تغییرات (همگام، همگام، نیمه همگام)؛
• تعداد سرورهای ضبط (M/S، M/M)؛
• تغییر قالب (مبتنی بر بیانیه (SBR)، مبتنی بر ردیف (RBR)، ترکیبی)؛
• از لحاظ نظری، مدلی برای انتقال تغییرات (فشار، کشیدن).

واقعیت جالب - اگر کمی در مورد آن فکر کنید، تکرار از لحاظ نظری به ما کمک می کند تا فقط خواندن را به دلایل اساسی مقیاس کنیم. در اینجا یک نتیجه گیری تا حدودی غیر واضح است. این به این دلیل است که اگر ما نیاز به آپلود تعداد معینی از تغییرات در یک نسخه از داده ها داشته باشیم، و این نسخه خاص از داده ها توسط همان سرور ارائه می شود، آنگاه این سرور قادر به تحمل تعداد مشخصی از به روز رسانی ها در هر ثانیه است و هیچ موارد بیشتری در آنجا آپلود خواهد شد. سرور قادر به به روز رسانی 1000 رکورد در ثانیه است، اما نه 2000. چه تغییری می کند اگر یک ماکت در این سرور قرار دهید، مهم نیست در حالت master-slave یا master-master؟ آیا می توانید دومین هزار به روز رسانی را روی این ماکت بریزید؟ پاسخ صحیح خیر است.

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

آن ها تکرار بیشتر در مورد خواندن است.

درباره همگام سازی

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

هیچ "تعهد با موفقیت انجام شد، این به چه معنی است؟" commit همزمان به این معنی است که محلی و راه دور ما (حداقل در یک ماکت) به پایان رسیده است، یعنی. ما چیزی را به دستگاه متعهد کرده ایم، اگر حالت تکرار همزمان داشته باشیم، این تغییرات با موفقیت انجام شده است، آنها برای درخواست های بعدی قابل مشاهده هستند ماشین محلی، همچنین روی دستگاه راه دور قابل مشاهده هستند (حداقل یکی). این بدان معنی است که اگر یک وضعیت اضطراری استاندارد رخ دهد، به عنوان مثال. یک کلنگ به یکی از سرورها پرواز کرد و همه چیز را به درستی از طریق آن سوراخ کرد - از پردازنده گرفته تا خود پیچ، سپس، با وجود این، داده ها نه تنها در یک سرور از راه دور خاص کپی می شوند، بلکه علاوه بر این، می توانند فوراً و بدون هیچ موردی تاخیرهای اضافی، در معاملات بعدی شرکت کنید.

همه اینها اصطلاحات عمومی است و هیچ ربطی به MySQL ندارد. در هر سیستم توزیع شده به این صورت ترتیب داده می شود.

تعهد ناهمزمان - بدون ضمانت اضافی، بسته به شانس شما.

commit نیمه همزمان یک راه حل میانی خوب است، این زمانی است که commit محلی ما به پایان رسیده است، هیچ چیز در مورد commit از راه دور مشخص نیست - ممکن است Slave گیر بیاورد، یا شاید آن را نداشته است، اما حداقل ما تاییدی دریافت کردیم که این داده ها درست است. در جایی بعد پرواز کردند و آنجا پذیرفته شدند و احتمالاً ثبت نام کردند.

درباره سرورهای ضبط انواع تکثیر چیست؟

تغییرات کلاسیک Master-Slave همه بر روی یک سرور ریخته می شوند و پس از آن در بسیاری از کپی ها کپی می شوند.

Master-Master true - وقتی تغییرات روی دسته ای از استادان به طور همزمان و به نحوی از یکی به دیگری، از دیگری به سومی و بین همه آنها جاری می شود، که باعث ایجاد یک سری شادی و یک سری می شود. مشکلات خودکار. واضح است که وقتی یک "کپی طلایی" و چندین نسخه از آن دارید، که باید (در حالت ایده آل - فورا) این "کپی طلایی" را تکرار کنید، پس همه چیز از نظر نحوه هدایت داده ها به جلو و عقب نسبتاً ساده است. و در هر کپی خاص چه کاری انجام دهید. با master-master یک "سردرد" جالب شروع می شود، و تأکید می کنم، نه به طور خاص در مورد MySQL، بلکه کاملاً تئوری است. اگر روی دو گره همزمان بخواهند یک تراکنش را اجرا کنند، که داده های یکسانی را تغییر می دهد و برای سادگی مثال، آن را به روش های مختلف تغییر می دهد، چه باید کرد. واضح است که نمی توانیم این دو تغییر را همزمان اعمال کنیم. در لحظه ای که شروع به تغییر چیزی در یک گره می کنیم، هنوز چیزی در گره دوم وجود ندارد. تعارض. یکی از تراکنش ها باید به عقب برگردد. علاوه بر این، "رقص" های جداگانه با بررسی ساعت ها و غیره شروع می شود.

یک نکته جالب - حتی گزینه ای که در نهایت همه تغییرات از همه Master ها باید به تدریج در همه جا پخش شوند، باز هم به همان پهنای باند نوشتن کمک نمی کند. شرم آور است، اما این طور است.

یک گزینه خوب "Master-Slave + Routing requests" نام دارد. خوب است زیرا برنامه‌ریزی در داخل آن آسان است، شما یک نسخه اصلی دارید، آن را روی تعدادی ماشین کپی می‌کنید. این بسیار ساده‌تر از یک محیط Master-Master است، زمانی که همه از حقوق مساوی و غیره برخوردارند، اما از نقطه نظر کاربردی همچنان به نظر می‌رسد که شما نقاط نوشتن زیادی دارید. شما به هر گره‌ای می‌آیید، می‌داند کجا شما را مسیریابی کند، و شما را با موفقیت هدایت می‌کند. خوب، خوانش ها مقیاس بندی شده اند - این لذت تکرار است. همیشه می توانید همه چیز را از همه نقاط بخوانید.

اکنون به پایگاه‌های داده، فرمت‌های مبتنی بر بیانیه «جادویی»، مبتنی بر ردیف و غیره نزدیک‌تر می‌شویم. در مورد فرمت تغییرات

چه کاری می توانی انجام بدهی؟ شما می توانید درخواست ها را خود انتقال دهید یا فقط می توانید ردیف های اصلاح شده را انتقال دهید. من تاکید می کنم که در حالی که ما هنوز در جنگل MySQL فرو نرفتیم، این کار را می توان توسط هر DBMS که دارای پرس و جوهایی است که تعداد زیادی (یا نه خیلی زیاد) تغییرات ایجاد می کند، انجام داد. به روز رسانی بسیاری از داده ها این سوال مطرح می شود - دقیقاً چه چیزی را کپی خواهیم کرد؟ می‌توانید درخواست‌ها را بین گره‌ها به عقب و جلو ارسال کنید، یا فقط می‌توانید داده‌های تغییر یافته را ارسال کنید. جالب است که هر دو راه بسیار بد هستند! هنوز هم می توانید مخلوط کردن را امتحان کنید.

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

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

MySQL به خودی خود نوعی فریب است. یک لایه منطقی به نام MySQL وجود دارد که با انواع چیزهای کلی که از ذخیره سازی داده ها جدا شده اند - شبکه، بهینه ساز، کش و غیره سر و کار دارد. لایه فیزیکی خاص که وظیفه ذخیره سازی داده ها را بر عهده دارد، یک طبقه زیر آن قرار دارد. چندین مورد داخلی وجود دارد و برخی توسط افزونه ها نصب شده اند. اما حتی MyISAM، InnoDB و غیره داخلی. روی لایه فیزیکی زندگی می کنند. معماری پلاگین جالب است، شما می توانید یک موتور جدید انتخاب کنید، اما یک نیمه بهینه خاص بلافاصله ایجاد می شود. در اصل، گزارش ثبت پیش‌نویس تراکنشی" و (WAL)، که لایه ذخیره‌سازی فیزیکی به هر حال می‌نویسد، برای تکرار خوب است و اگر سیستم بداند که نوعی لایه فیزیکی وجود دارد یا به اندازه کافی با آن ارتباط برقرار کرده است. آی تی سطح فیزیکی، در این صورت نمی توان یک گزارش جداگانه در سطح منطقی نوشت، بلکه از همان WAL استفاده کرد. اما در MySQL این از نظر مفهومی غیرممکن است، یا اگر رابط را در PSE تغییر دهید تا از نظر مفهومی ممکن شود، کار زیادی وجود دارد.

Replication در سطح خود MySQL پیاده سازی می شود. در این مورد نیز خوبی وجود دارد - علاوه بر یک گزارش به شکل داده های عمیق داخلی موتور ذخیره سازی، یک گزارش کم و بیش منطقی، شاید در سطح بیانیه، وجود دارد که جدا از این موتور نگهداری می شود امنیت "اضافی" و غیره به علاوه، از آنجایی که هیچ محدودیت داخلی وجود ندارد، می توانید هر کار خلاقانه ای مانند تعویض موتور در حین پرواز انجام دهید.

در این شرایط، MySQL 4.1 پیاده سازی شده است: master-slave، pull-based، اکیدا همگام و کاملاً SBR. اگر در دوران باستان 4.x گیر کرده اید، احتمالاً همه چیز برای شما بد است. نسخه 5.x تقریباً 10 سال از عمر آن می گذرد - زمان به روز رسانی فرا رسیده است.

خنده‌دار است که نسخه‌هایی را دنبال کنیم که چگونه مردم روی انواع چنگک‌ها پا می‌گذارند و وقتی کاری نمی‌توانست انجام دهند، چنگک‌های جدیدی را روی این چنگک‌ها می‌کوبند تا زندگی آنقدر دردناک نباشد. بنابراین، در نسخه 5.1 آنها RBR را برای جبران مشکلات اجتناب ناپذیر SBR اضافه کردند و یک حالت ترکیبی اضافه کردند. در نسخه 5.6، ما چیزهای خوب دیگری را اضافه کردیم: نیمه همگام، برده تاخیری، GTID.

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

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

برده چه می کند؟ بهتر است تغییرات را برای برده ارسال نکنید، زیرا ممکن است وارد چیزی غیرقابل درک شوید. غلام کمی کار بیشتری دارد. علاوه بر نگه داشتن یک گزارش اضافی و ارسال آن در صورت درخواست، یک رشته نیز وجود دارد که به یک استاد راه دور، شاید بیش از یک، می رود و یک گزارش باینری را از آنجا دانلود می کند Remote Masters "دانلود گزارش های مختلف" مبهم است، از یک سو، بد نیست، اما از سوی دیگر، یک اختلاف فوری وجود دارد. این شامل موقعیت های خود شما است، ما آنها را به صورت محلی در امتداد شبکه می کشیم، آنها را در یک گزارش جداگانه قرار می دهیم، همچنین یک موضوع جداگانه در حال اجرا است و سعی در پخش این لاگ های محلی دارد 5.6، شناسایی یک تراکنش خاص در لاگ با نام فایل و موقعیت آن در استاد راه حل جالبی است.

در اینجا مسیر نوشتنی است که یک درج ساده بدون تکرار طی می کند:

برنامه متصل به سرور، آن را در جدول قرار داده و خارج می شود.

با تکرار چندین مرحله اضافی وجود دارد:

برنامه Writer به همان روش به استاد می رود، اما علاوه بر این، این داده ها به یک شکل یا دیگری در گزارش باینری ختم می شود، سپس از طریق شبکه به گزارش رله بارگیری می شود، سپس از گزارش رله به تدریج دوباره پخش می شود. (اگر خوش شانس باشیم و برده عقب نیفتد، فوراً دوباره پخش می شوند) به جدولی روی برده، که پس از آن همه چیز در خواننده موجود است.

اینکه دقیقاً چه چیزی در لاگ باینری به پایان می رسد به تنظیمات SBR/RBR/مخلوط بستگی دارد. این همه از کجا رشد می کند؟ بیایید خودمان را به عنوان یک پایگاه داده تصور کنیم. ما یک درخواست ساده دریافت کردیم "به روز رسانی یک رکورد خاص" - به روز رسانی کاربران x=123 SET WHERE id=456

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

یک وضعیت دیگر. بیایید تصور کنیم که ما همان درخواست را دریافت کرده ایم، که به خودی خود کوچک است، اما داده های زیادی را تغییر می دهد - به روز رسانی کاربران SET پاداش = پاداش + 100

فقط یک گزینه مؤثر وجود دارد - نوشتن خود درخواست، زیرا درخواست دقیقاً 32 بایت است و می تواند تعداد دلخواه رکورد را به روز کند - 1000، 100،000، 1،000،000، هر تعداد که دوست دارید... نوشتن کارآمد نیست. رکوردها را به گزارش تغییر داد.

چه اتفاقی می‌افتد اگر چنین درخواست ساده‌ای را در گزارش قرار دهیم: "بیایید همه کاربرانی را که برای مدت طولانی وارد سیستم نشده‌اند غیرفعال کنیم" - UPDATE users SET disabled=1 WHERE last_login

ناگهان وحشت رخ می دهد. مشکل این است که اگر خود درخواست را کاملاً تکرار کنید، اولاً، زمان هرگز بین دو گره همزمان نیست، علاوه بر این، به دلیل طولانی بودن مسیر ضبط، در لحظه پخش مجدد این "NOW" واگرا خواهد شد. ماکت به طور ناگهانی از استاد جدا می شود و همه تغییرات بعدی، به طور رسمی، دیگر امن نیستند و می توانند به هر چیزی منجر شوند.

به طور کلی، برای چنین پرسش هایی، صرف نظر از میزان داده های تغییر یافته، در حالت ایده آل لازم است که خود خطوط کپی شوند. در این مورد خاص، شما نمی توانید خود خطوط را کپی کنید، اما ثابت را ثابت کنید و نه "NOW" را در گزارش بنویسید، بلکه مهر زمانی خاصی را که توسط master در زمان تکرار استفاده شده است، بنویسید.

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

• استاد چند نخی است، اما برده نه. واضح است که اگر استاد باری را در چهار هسته بریزد، برده وقت ندارد این بار را در یک هسته بریزد. همه چیز خیلی بد است.
• وضعیت Slave با نام موقعیت موجود در فایل اصلی تعیین می شود. در مورد آن فکر کنید - وضعیت یک گره در خوشه با نام فایل و موقعیت این فایل بر روی گره دیگری در خوشه تعیین می شود، که با آن هر چیزی ممکن است به هر دلیلی اتفاق بیفتد!
• "صرفه جویی" RBR. معلوم می‌شود که به‌طور پیش‌فرض، تصاویر کامل ردیف قبل/بعد در آنجا نوشته می‌شوند، یعنی. ما یک ستون را در یک رشته پنج کیلوبایتی تغییر دادیم، اوه! – 10 کیلوبایت ترافیک و 20-40 بایت سربار برای این خط، پس اوه! - چنین خط جسورانه ای می رود نسخه پیشین، اوه! – پس از این یک نسخه با مقادیر جدید وجود دارد. مدیران یکپارچه زوزه می کشند! با این حال، از نظر برخی از برنامه‌های کاربردی منحرف، این بسیار عالی است، به عنوان مثال، خواننده‌های خارجی که سعی می‌کنند به سرور MySQL متصل شوند، داده‌ها را از آن بیرون بکشند و کاری با آن انجام دهند، برای مثال، آن‌ها را به صورت کامل بچسبانند. فهرست متن به همان اندازه که این از نظر مدیریت پایگاه داده بد است، که در آن یک تغییر در هر سه بایت، 10 کیلوبایت ترافیک روی پیچ ایجاد می کند، و سپس 10 کیلوبایت ترافیک شبکه برای هر برده، برای هر سیستمی به همان اندازه خوب است. به عنوان جستجوی تمام متن، مانند Sphinx، که هیچ کپی محلی از داده ها وجود ندارد، و هیچ تمایلی برای پیاده سازی MySQL از ابتدا وجود ندارد. در MySQL 5.6 آن ها متوجه شدند و binlog_row_image را ساختند (اما به طور پیش فرض کامل، نه حداقل یا noblob).

به طور خلاصه، همه چیز هوشمندانه چیده نشده است - یک چوب، یک طناب، یک کنده، یک کنده دیگر. و حتی در این گزارش، بیماری های "کودکی" بسیار خنده دار هستند:

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

• اول از همه، ما به پیش فرض ها اعتقاد نداریم.
• ما با دقت به تنظیمات نگاه می کنیم، به آنچه می خواهیم فکر می کنیم - SBR، RBR و غیره.

و بهتر است فوراً آن را تنظیم کنید تا مجبور نباشید بعداً قیمه های عجیب و غریب را مرتب کنید.

در شرایطی که "لوگ خراب است، موقعیت از هم جدا شده است، معلوم نیست چه اتفاقی می افتد"، یک جعبه ابزار خاص وجود دارد - ما به رویدادها نگاه می کنیم، سعی می کنیم بفهمیم کدام تراکنش قبلاً عبور کرده است، کدام تراکنش انجام نشده است، آیا این کل چیز را می توان ذخیره یا بازیابی کرد، و غیره.

نکته دیگر در رعایت همانندسازی. جالب است ببینید که چگونه ساختار کج داخلی نه تنها رقابت، بلکه ایجاد محصولات اضافی را تحریک می کند. آنها می گویند که Replicator تنگستن "جادویی" مشکلی به نام "برد تک رشته ای بد است" را به خوبی حل می کند و اگر مشکلات ذاتی نبود، هیچ محصول اضافی وجود نداشت که به شما امکان می دهد از این مکانیسم استفاده کنید و داده ها را به سیستم های دیگر، از یک سو، و در همان زمان حل تعدادی از مشکلات ساخته شده در سیستم موجود، از طرف دیگر.

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

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

بعد عنصر دیگری از خلاقیت است. تصور موقعیتی که استاد کل 10 PB را ثبت کرده باشد، سخت نیست درایو ابرییا با ارسال این لاگ ها کل شبکه را سیل کردیم، در حالی که ما به 90 درصد این به روز رسانی ها نیاز نداریم، زیرا ما علاقه مندیم که مثلاً یک جدول در یک زمان یا یک پایگاه داده را در یک زمان تکرار کنیم، اما به طور پیش فرض همه چیز ریخته می شود. در یک گزارش باینری - همه تغییرات در همه پایگاه‌های داده، در همه جداول، در همه چیز. راه حل دوباره با خلاقیت خود شگفت زده می شود. از یک طرف، چهار تنظیمات وجود دارد - (binlog|replicate)_(do|ignore)_db، که به شما امکان می دهد آنچه را که در گزارش نوشته می شود و آنچه نادیده گرفته می شود را بر روی master فیلتر کنید. بر این اساس، بر روی برده، به شما امکان می دهد همین کار را انجام دهید. آن ها در master می‌توانیم آنچه را که وارد لاگ باینری می‌شود فیلتر کنیم - در این قیف، که سپس در شبکه ادغام می‌شود، و بر این اساس در Slave، می‌توانیم فیلتر ورودی را روی آنچه از شبکه می‌آید قرار دهیم. یا فقط بخشی از داده ها را روی دیسک بنویسید و سپس فقط بخشی از داده ها را در Slave دوباره پخش کنید. ناگهان، حتی در این داستان ساده، وحشت رخ می دهد، زیرا ترکیب - ما از یک پایگاه داده استفاده می کنیم و جدول را در پایگاه داده دیگری با استفاده از یک نحو جالب به روز می کنیم - به نوعی رفتار می کند ... و دقیقاً چگونه رفتار خواهد کرد، مشخص نیست، زیرا فیلترهای مختلف در زمان های مختلف فعال می شوند.

هیچ چیز خوبی به نام "انتخاب مجدد استاد در صورت مرگ ناگهانی" وجود ندارد، شما باید آن را با دستان خود بلند کنید. فقدان ابزار برای مدیریت خوشه - این به نظر من خوب است - باعث رقابت می شود و باعث ایجاد محصولات اضافی می شود. در واقع، اگر نسخه بسیار جالب Master-Master در MySQL معمولی یا حداقل بازیابی خودکار پس از خرابی کاملاً کار می کرد، پس چرا به همه Galera، Percona/MariaDB Cluster و غیره نیاز است؟

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

پیکربندی شماره 1. یک Master-Master "روی زانو" در سبک MySQL به این صورت انجام می شود:

ترسناک این است که چقدر احمق در دنیا وجود دارد! Google "Master-master MySQL Replication" - هر پیوند دوم مانند این است. جهنم و هولوکاست.

فوکوس شماره 2 – catch-all slave – خوشایندتر است. هیچ بررسی غیرضروری وجود ندارد - چه چیزی از چه کسی پرواز می کند، چه کسی آن را دریافت می کند و با آن چه باید کرد. به همین دلیل، می‌توانید چیزهای خنده‌داری مانند یک برده بسازید که یا بخشی از داده‌های دسته‌ای از سرورها دقیقاً در آن ادغام می‌شوند، یا تمام داده‌های همه سرورها دقیقاً ادغام می‌شوند - سروری با تمام نسخه‌های پشتیبان. اما، تکرار می کنم، تکرار وجود دارد، یعنی. یک ابزار اساسی وجود دارد که جدول A را به جای B کپی می کند و تمام.

و در نهایت، ترفند شماره 3 - ما همه چیز را جایگزین می کنیم. به یاد داشته باشیم که تکرار در سطح منطقی زندگی می کند، که به هیچ وجه با سطح ذخیره سازی فیزیکی مرتبط نیست. با توجه به این، شما می توانید چیزهای عجیب و غریب بسیار جالب ایجاد کنید. می‌توانید موتور را «در حال پرواز» برای اهداف نامشخص تغییر دهید - در اینجا یک داستان واقعی وجود دارد که به گفته آنها، تکرار از پایگاه‌های داده InnoDB به جداول MyISAM صرفاً به این دلیل است که جستجوی متن کامل حداقل به نحوی کار کند. یک ترفند خلاقانه به نام "اصلاح طرحواره از طریق تکرار" وجود دارد. من از درک این که چربی چیست امتناع می کنم، اما چنین ترفندهایی وجود دارد. خوب، یک حالت عملکرد واضح و جالب به نام "ارتقا نسخه پارانوئید از طریق تکرار" وجود دارد.

در طول گزارش متوجه شدیم:

با این وجود، اگر حداقل به طور تقریبی نحوه عملکرد آن را درک کنید، می توانید با این جهنم زندگی کنید.

پیام اصلی این است که:

در سال 2015، در کنفرانس HighLoad++ Junior، آندری آکسنوف نسخه جدیدی از گزارش خود را در مورد دستگاه تکرار در MySQL خواند. ما هم در وبلاگمان رمزگشایی کردیم.

همانند سازی- تکنیکی که در معماری سیستم هایی که تحت بار کار می کنند استفاده می شود که نتیجه آن توزیع بار هنگام کار با یک پایگاه داده در چندین سرور است. تکرار MySQL MASTER SLAVE بیشتر مورد استفاده قرار می گیرد، اما نوع دوم از تکرار نیز استفاده می شود - Master-Master.

MySQL MASTER SLAVE replication چیست و چه کاربردی دارد؟

همانند سازی ارباب-بردهشامل کپی کردن داده ها به سرور MySQL است. اگر سرور اصلی از کار بیفتد، عملکرد آن به Slave تغییر می کند.

Replication همچنین می تواند برای بهبود عملکرد سیستم انجام شود، اما عملکرد تقریباً همیشه در اینجا درجه دوم است.
هنگامی که یک برنامه کاربردی با پایگاه داده کار می کند، متداول ترین عملیات ها هستند انتخاب کنید- درخواست برای خواندن داده ها، تغییر داده ها - درخواست ها حذف, درج کنید, به روز رسانی, تغییر دهیداز نظر آماری خیلی کمتر اتفاق می افتد.

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

راه حل محبوب است، اما همیشه قابل اجرا نیست، زیرا ممکن است در طول تکرار تاخیر وجود داشته باشد - اگر این اتفاق بیفتد، اطلاعات نیز باید از سرور Master خوانده شوند.

هدایت درخواست های نوع خاصی به سرور پایگاه داده خاص در هر صورت در سطح برنامه اجرا می شود.

اگر پرس و جوهای SELECT و همه موارد دیگر را از هم جدا کنید سطح برنامهبا ارسال آنها به سرور مورد نیاز هنگامی که یکی از آنها از کار بیفتد، برنامه ای که زیرساخت ارائه می دهد غیر قابل اجرا خواهد بود. برای انجام این کار، باید یک طرح پیچیده تری ارائه دهید و هر یک از سرورها را رزرو کنید.

تکرار برای تحمل خطا است، نه برای مقیاس بندی.

تکرار MySQL MASTER SLAVE - راه اندازی در Debian

ما از دو سرور با آدرس استفاده خواهیم کرد:

• سرور اصلی 192.168.0.1
• سرور برده 192.168.0.2

برای نمایش از VDS متصل به یک شبکه محلی استفاده می شود.
برای اینکه همیشه مطمئن باشیم که در کدام سرور این یا آن دستور را اجرا می کنیم، فایل های /etc/hosts را در هر دو سرور ویرایش می کنیم.

192.168.0.1 استاد

192.168.0.2 برده

بیایید مقادیر موجود در /etc/hostname را به ترتیب با master و slave جایگزین کنیم تا تغییرات اعمال شود و سرور راه اندازی مجدد شود.

1. تنظیمات را روی سرور اصلی انجام می دهیم.

root@master:/#

ویرایش فایل پیکربندی اصلی سرور پایگاه داده

mcedit /etc/mysql/my.cnf

شناسه سرور را انتخاب کنید - می توانید هر عددی را مشخص کنید، پیش فرض 1 است - فقط خط را از نظر خارج کنید

شناسه سرور = 1

مسیر را برای ورود به سیستم باینری تنظیم کنید - همچنین به طور پیش فرض مشخص شده است، آن را لغو نظر کنید

نام پایگاه داده ای را که در سرور دیگری کپی می کنیم تنظیم کنید

binlog_do_db = db1

Mysql را مجدداً راه اندازی کنید تا فایل پیکربندی دوباره خوانده شود و تغییرات اعمال شوند:

/etc/init.d/mysql راه اندازی مجدد

2. حقوق ضروری کاربر را تنظیم کنید

به کنسول سرور پایگاه داده بروید:

ما به کاربر در سرور برده حقوق لازم را می دهیم:

اعطای تکرار SLAVE در *.* به "slave_user"@"%" شناسایی شده توسط "123";

قفل کردن تمام جداول در پایگاه داده

میزهای فلاش با قفل خواندن.

بررسی وضعیت سرور اصلی:

+——————+———-+—————+——————+
| فایل | موقعیت | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 ردیف در مجموعه (0.00 ثانیه)

3. یک پایگاه داده dump روی سرور ایجاد کنید

ایجاد یک پایگاه داده dump:

mysqldump -u root -p db1 > db1.sql

باز کردن قفل جداول در کنسول mysql:

4. دامپ پایگاه داده را به سرور Slave منتقل کنید

scp db1.sql [ایمیل محافظت شده]:/خانه

ما اقدامات بعدی را در سرور Slave انجام می دهیم

root@slave:/#

5. ایجاد پایگاه داده

بارگیری زباله:

mysql -u root -p db1< db1.sql

6. تغییراتی را در my.cnf ایجاد کنید

mcedit /etc/mysql/my.cnf

ما با افزایش مقدار تنظیم شده در سرور Master یک شناسه اختصاص می دهیم

شناسه سرور = 2

مسیر ثبت رله را تنظیم کنید

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

و مسیر ورود به bin log در سرور Master

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

پایه را مشخص کنید

binlog_do_db = db1

راه اندازی مجدد سرویس

/etc/init.d/mysql راه اندازی مجدد

7. یک اتصال به سرور Master تنظیم کنید

CHANGE MASTER TO MASTER_HOST="192.168.0.1"، MASTER_USER="slave_user"، MASTER_PASSWORD="123"، MASTER_LOG_FILE = "mysql-bin.000001"، MASTER_LOG_POS = 327;

ما شروع به تکرار در سرور برده می کنیم:

با درخواست زیر می توانید عملکرد Replication را در Slave بررسی کنید:

************************** 1. ردیف ******************** *******
Slave_IO_State: در انتظار استاد برای ارسال رویداد
Master_Host: 192.168.0.1
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: بله
Slave_SQL_Running: بله
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log Space: 555
Until_Condition: ندارد
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: خیر
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
ثانیه_پشت_استاد: 0
Master_SSL_Verify_Server_Cert: خیر
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_IDs:
شناسه_سرور_مستر: 1
1 ردیف در مجموعه (0.00 ثانیه)

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

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

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

هر کس روز خوب! امروز در مقاله ما به نمونه هایی از راه اندازی تکرار از نوع "master-slave" نگاه خواهیم کرد.

کمی تئوری

چرا تکرار مورد نیاز است؟ اول از همه، این یک شبکه ایمنی است در صورتی که سرور اصلی mysql از کار بیفتد، سپس می توانید به سرور برده تغییر دهید و به کار خود ادامه دهید. ثانیاً، این فرصتی است برای کاهش بار روی سرور اصلی Mysql با استفاده از سرور اصلی فقط برای نوشتن و انجام عملیات خواندن در سرور برده. تکثیر چگونه اتفاق می افتد؟ سرور اصلی، binlog می نویسد، که در آن عملیات انجام شده بر روی پایگاه داده (پایگاه های داده) را نشان می دهد و افست موجود در گزارش را از ابتدا تا رکورد فعلی (موقعیت) به خاطر می آورد. سرور برده به Master متصل می شود، مقادیر موقعیت را مقایسه می کند و تغییرات در گزارش را می خواند که از مقدار موقعیت خود شروع می شود و به مقدار موقعیت master ختم می شود. این تغییرات (دستورات) را در پایگاه داده در سرور برده اعمال می کند.

نصب و پیکربندی Master

ما my.cnf را در سرور اصلی تغییر می دهیم:

Server-id = 1 - شناسه سرور را نشان می دهد log_bin = /var/log/mysql/mysql-bin.log - نام ورود و مسیر

یک توضیح کوچک: به طور پیش فرض، جادوگر برای همه پایگاه های داده binlog می نویسد، این را می توان با استفاده از "binlog-do-db" تغییر داد. هنگامی که از پایگاه داده خاصی استفاده می شود، مقادیر در گزارش ها ثبت می شوند.در اینجا همچنین می توانید تعیین کنید که چند روز لاگ ها ذخیره شوند، چه نوع لاگ هایی هستند حداکثر اندازه(پارامترهای expire_logs_days و max_binlog_size). کاربری را به MySQL اضافه کنید که تحت حقوق او Replication انجام خواهد شد:

GRANT Replication Slave ON *.* TO user_name@ip_slave_server IDENTIFED by "password";

Replication Slave امتیازی است که به کاربر این امکان را می‌دهد که بیلوگ‌ها را بخواند. ip_slave_server - ip سروری که کاربر از آن متصل می شود. راه اندازی مجدد سرور mysql:

/etc/init.d/mysql راه اندازی مجدد

بیایید کار استاد را بررسی کنیم:

نمایش وضعیت استاد؛

شما باید نام binlog و موقعیت آن را ببینید. هنگام اجرای دستورات در پایگاه داده، موقعیت تغییر خواهد کرد.

راه اندازی برده

ما تغییراتی را در فایل my.cnf ایجاد می کنیم:

Server-id = 2 - شناسه سرور برده باید با شناسه اصلی متفاوت باشد. relay-log = /var/lib/mysql/mysql-relay-bin - مانند یک گزارش باینری، از مجموعه‌ای از فایل‌های شماره‌دار حاوی رویدادهایی تشکیل شده است که تغییرات پایگاه داده را توصیف می‌کنند. relay-log-index = /var/lib/mysql/mysql-relay-bin.index - یک فایل فهرست که شامل نام همه فایل‌های گزارش رله در حال استفاده است. replicate-do-db = پایگاه داده ای که تکرار خواهد شد.

یادداشت مهم! هنگام سازماندهی یک cross db (زمانی که یک پایگاه داده استفاده می شود و داده ها در پایگاه داده دیگری به روز می شوند)، binlog-do-db نیازی به مشخص شدن در تنظیمات سرور اصلی ندارد، binlog-و باید برای همه پایگاه های داده نوشته شود، و در در تنظیمات برده لازم است به جای آن از replicate-do استفاده شود -db specify replicate-wild-do-table=db_name.%, که در آن db_name نام پایگاه داده تکرار شده است.راه اندازی مجدد سرور mysql:

/etc/init.d/mysql راه اندازی مجدد

فعال کردن تکثیر

تنظیم GLOBAL فقط خواندنی = روشن.

بیایید به وضعیت استاد نگاه کنیم:

نمایش وضعیت استاد؛

ما مقادیر File و Position را به خاطر می آوریم (یا بهتر است آنها را یادداشت کنیم). مقدار Position نباید اکنون تغییر کند. با استفاده از دستور mysqldump، Master را حذف می کنیم:

Mysqldump -uname -ppassword db_master_name > dump_db،

جایی که name نام کاربری است، رمز عبور رمز عبور، db_master_name نام پایگاه داده، dump_db نام تخلیه است. پس از تکمیل Dump، اجازه نوشتن در پایگاه داده را می دهیم:

SET GLOBAL read_only = OFF.

دامپ را به Slave منتقل می کنیم و آن را گسترش می دهیم

Mysql -uname -ppassword db_slave_name< dump_db

راه اندازی Replication

CHANGE MASTER TO MASTER_HOST = "Master ip"، MASTER_USER = "user_name"، MASTER_PASSWORD = "password"، MASTER_LOG_FILE = "log name"، MASTER_LOG_POS = موقعیت.

master ip - ip سروری که Master در آن قرار دارد، نام کاربری - نام کاربری که در master ایجاد کردیم، نام log - مقدار File در master هنگام ایجاد تخلیه پایگاه داده، موقعیت - مقدار موقعیت در استاد زمانی که تخلیه پایگاه داده ساخته شد. بیایید برده را شروع کنیم:

شروع برده؛

بیایید ببینیم که تکرار چگونه پیش می‌رود: در Master: SHOW MASTER STATUS\G در Slave: SHOW SLAVE STATUS\G

تنظیمات امنیتی در سرور اصلی

پارامتر bind-address در /etc/mysql/my.cnf مشخص می کند که سرور mysql در زمان انتظار برای اتصال به چه آدرس IP گوش دهد. به طور معمول دارای مقدار bind-address = 127.0.0.1 است. اما پس از راه اندازی سرور برده، باید به اتصالات از سرور برده اجازه دهیم و اتصالات محلی باید کار کنند. Bind-address می تواند فقط از یک IP یا از همه اتصالات اجازه دهد. زیرا باید بیش از یک ip برای اتصال مشخص کنیم، خط را با bind-address = 127.0.0.1 کامنت می کنیم. اکنون سرور mysql اتصالات را از تمام آدرس های IP می پذیرد که بسیار خطرناک است. iptables به ما در حل این مشکل کمک می کند:

Iptables -I INPUT -p tcp -s ip_slave_server-a --dport 3306 -j ACCEPT -ابتدا اجازه اتصال از آدرس IP سرور برده iptables -I INPUT -p tcp --dport 3306 -j DROP -سپس اتصال را از تمام آدرس های IP دیگر

اکنون 2 سرور MySQL در حال اجرا در حالت master-slave خواهیم داشت که به طور قابل توجهی قابلیت اطمینان سایت را افزایش می دهد و برای برخی از سایت های دروپال به افزایش سرعت کار کمک می کند. در مقاله بعدی به تغییر حالت های master و slave در صورت خرابی سرور اصلی خواهیم پرداخت.