مرورگرها

مبانی تکرار در MySQL. راه اندازی تکرار پایگاه داده mysql تکرار پایگاه داده Mysql

22.04.2023

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

یک مقدمه کوچک

Replication (از لاتین replico - تکرار می کنم) تکرار تغییرات داده ها از سرور اصلی پایگاه داده به یک یا چند سرور وابسته است. سرور اصلی فراخوانی خواهد شد استاد، و وابسته ماکت ها.
تغییرات داده‌ای که روی Master اتفاق می‌افتد روی Replica‌ها تکرار می‌شوند (اما نه برعکس). بنابراین، پرس و جوهایی برای تغییر داده ها (INSERT، UPDATE، DELETE، و غیره) فقط بر روی Master اجرا می شوند، در حالی که پرس و جو برای خواندن داده ها (به عبارت دیگر، SELECT) می توانند هم بر روی replica ها و هم بر روی Master اجرا شوند. فرآیند تکثیر روی یکی از ماکت‌ها بر عملکرد سایر ماکت‌ها تأثیر نمی‌گذارد و عملاً بر عملکرد Master تأثیر نمی‌گذارد.
همانندسازی با استفاده از لاگ های باینری که روی master نگهداری می شوند انجام می شود. آنها تمام پرس و جوهایی را که منجر به تغییرات در پایگاه داده می شوند (یا به طور بالقوه منجر می شوند) ذخیره می کنند (پرس و جوها به طور صریح ذخیره نمی شوند، بنابراین اگر می خواهید آنها را ببینید، باید از ابزار mysqlbinlog استفاده کنید). binlog ها به replica ها منتقل می شوند (binlog بارگیری شده از Master "Relay binlog" نامیده می شود) و پرس و جوهای ذخیره شده از یک موقعیت خاص اجرا می شوند. درک این نکته مهم است که Replication خود داده های تغییر یافته را منتقل نمی کند، بلکه فقط درخواست هایی را که باعث تغییرات می شوند منتقل می کند.
در حین تکرار، محتویات پایگاه داده در چندین سرور کپی می شوند. چرا استفاده از تکثیر ضروری است؟ چند دلیل وجود دارد:
  • عملکرد و مقیاس پذیری. ممکن است یک سرور نتواند بار ناشی از خواندن و نوشتن همزمان پایگاه داده را مدیریت کند. مزیت ایجاد کپی هر چه تعداد خواندن در هر نوشتن در سیستم شما بیشتر باشد، بیشتر خواهد بود.
  • تحمل خطا. در صورت خرابی replica، تمام درخواست های خواندن می توانند با خیال راحت به Master منتقل شوند. اگر Master ناموفق باشد، درخواست‌های نوشتن را می‌توان به replica منتقل کرد (پس از بازیابی Master، می‌تواند نقش Replica را بر عهده بگیرد).
  • فایل پشتیبانی اطلاعات. Replica را می توان برای مدتی "آهسته" کرد تا mysqldump را انجام دهد، اما master نمی تواند.
  • ارزیابی تنبل. پرس و جوهای سنگین و آهسته SQL را می توان بر روی یک ماکت جداگانه بدون ترس از تداخل در عملکرد عادی کل سیستم اجرا کرد.
علاوه بر این، ویژگی های جالب دیگری نیز وجود دارد. از آنجایی که نه خود داده‌ها به replica‌ها منتقل می‌شوند، بلکه کوئری‌هایی که باعث تغییر آن‌ها می‌شوند، می‌توانیم از ساختار جدول متفاوتی روی Master و Replica استفاده کنیم. به ویژه، نوع جدول (موتور) یا مجموعه شاخص ها ممکن است متفاوت باشد. به عنوان مثال، برای انجام جستجوی متن کامل، می‌توانیم از نوع جدول MyISAM روی ماکت استفاده کنیم، علیرغم اینکه Master از InnoDB استفاده خواهد کرد.

راه اندازی Replication

فرض کنید ما یک پایگاه داده MySQL در حال کار داریم که قبلاً با داده ها پر شده است و کار می کند. و به یکی از دلایلی که در بالا توضیح داده شد، ما قصد داریم Replication را در سرور خود فعال کنیم. داده های اولیه ما:
  • آدرس IP استاد 192.168.1.101 و ماکت آن 192.168.1.102 است.
  • MySQL نصب و پیکربندی شد
  • شما باید Replication پایگاه داده testdb را راه اندازی کنید
  • ما می توانیم جادوگر را برای مدتی مکث کنیم
  • البته ما روی هر دو دستگاه روت داریم
تنظیمات جادوگر
حتما شناسه سرور منحصر به فرد، مسیر لاگ های باینری و نام پایگاه داده برای تکرار را در قسمت مشخص کنید:
شناسه سرور = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db=testdb
مطمئن شوید که فضای دیسک کافی برای لاگ های باینری دارید.

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

MySQL را مجدداً راه اندازی کنید تا تغییرات پیکربندی اعمال شود:
[ایمیل محافظت شده]# سرویس mysqld راه اندازی مجدد

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

تنظیمات Replica
شناسه سرور، نام پایگاه داده برای تکثیر و مسیر Relay binlogs را در قسمت config مشخص کنید، سپس MySQL را مجددا راه اندازی کنید:
شناسه سرور = 2
relay-log=/var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db=testdb

[ایمیل محافظت شده]# سرویس mysqld راه اندازی مجدد

انتقال داده
در اینجا باید پایگاه داده را برای نوشتن قفل کنیم. برای انجام این کار، می‌توانید اجرای برنامه‌ها را متوقف کنید، یا از پرچم read_only در Master استفاده کنید (توجه: این پرچم روی کاربران دارای امتیاز SUPER تأثیر نمی‌گذارد). اگر جداول MyISAM داشته باشیم، "جدول های flush" را نیز انجام خواهیم داد:
[ایمیل محافظت شده]> FLASH TABLES با قفل خواندن.
[ایمیل محافظت شده]> SET GLOBAL read_only = روشن.

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

ما یک Dump پایگاه داده ایجاد می کنیم و پس از اتمام عملیات، قفل اصلی را حذف می کنیم:
[ایمیل محافظت شده]> SET GLOBAL read_only = OFF.

ما Dump را به Replica منتقل می کنیم و داده ها را از آن بازیابی می کنیم.
در نهایت، با دستورهای "change master to" و "start slave" همانندسازی را شروع می کنیم و می بینیم که آیا همه چیز به خوبی پیش رفته است یا خیر:
[ایمیل محافظت شده]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101"، MASTER_USER = "تکرار"، MASTER_PASSWORD = "رمز عبور"، MASTER_LOG_FILE = "mysql-bin.000003"، MASTER_LOG_POS = 98;
[ایمیل محافظت شده]> start Slave;
ما مقادیر MASTER_LOG_FILE و MASTER_LOG_POS را از master می گیریم.

بیایید ببینیم که تکرار با دستور "show Slave status" چگونه پیش می رود:
[ایمیل محافظت شده]> نشان دادن وضعیت برده\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 Slave status" را در مستندات ببینید). مقدار Seconds_Behind_Master می تواند هر عدد صحیحی باشد.
اگر تکثیر به خوبی پیش برود، replica از master پیروی می کند (شماره گزارش در Master_Log_File و موقعیت Exec_Master_Log_Pos افزایش می یابد). زمان پشت ماکت از استاد (Seconds_Behind_Master)، در حالت ایده آل، باید برابر با صفر باشد. اگر کاهش یا رشد نکند، ممکن است بار روی ماکت خیلی زیاد باشد - به سادگی زمان لازم برای تکرار تغییراتی که روی master رخ می دهد را ندارد.
اگر Slave_IO_State خالی و Seconds_Behind_Master NULL باشد، تکرار شروع نشده است. به گزارش MySQL نگاه کنید تا علت را پیدا کنید، آن را برطرف کنید و دوباره تکرار کنید:
[ایمیل محافظت شده]> start Slave;

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

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

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

فرض کنید ما قبلاً یک Master و Replica در حال کار داریم و باید یکی دیگر را به آنها اضافه کنیم. این حتی ساده تر از اضافه کردن اولین نسخه به Master است. و خیلی خوشایندتر است که برای این کار نیازی به توقف استاد نیست.
ابتدا اجازه دهید MySQL را روی نسخه دوم تنظیم کنیم و مطمئن شویم که پارامترهای لازم را در پیکربندی وارد کرده ایم:
شناسه سرور = 3
replicate-do-db=testdb

حالا تکرار را روی ماکت اول متوقف کنید:
[ایمیل محافظت شده]> Slave را متوقف کنید.

ماکت به طور معمول به کار خود ادامه می دهد، اما داده های موجود در آن دیگر به روز نخواهند بود. بیایید به وضعیت نگاه کنیم و موقعیت استاد را به یاد بیاوریم که ماکت قبل از توقف تکرار به آن رسیده است:
[ایمیل محافظت شده]> نشان دادن وضعیت برده\G

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

یک پایگاه داده dump ایجاد کنید و همانند سازی را در اولین ماکت ادامه دهید:
[ایمیل محافظت شده]> START SLAVE.

بیایید داده ها را از Dump روی ماکت دوم بازیابی کنیم. سپس Replication را فعال کنید:
[ایمیل محافظت شده]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101"، MASTER_USER = "تکرار"، MASTER_PASSWORD = "رمز عبور"، MASTER_LOG_FILE = "mysql-bin.000004"، MASTER_LOG_POS = 15;
[ایمیل محافظت شده]> START SLAVE.

مقادیر MASTER_LOG_FILE و MASTER_LOG_POS به ترتیب مقادیر Master_Log_File و Exec_Master_Log_Pos حاصل از فرمان نمایش وضعیت برده در اولین ماکت هستند.
تکثیر باید از موقعیتی که اولین ماکت متوقف شد (و بر این اساس، تخلیه ایجاد شد) شروع شود. بنابراین، ما دو کپی با داده های یکسان خواهیم داشت.

ترکیب کپی ها

گاهی اوقات این وضعیت به وجود می آید: دو پایگاه داده روی Master وجود دارد که یکی از آنها روی یک ماکت و دیگری روی دیگری تکرار می شود. چگونه می توان تکرار دو پایگاه داده را روی هر دو ماکت بدون ریختن آنها روی Master و بدون خاموش کردن آن تنظیم کرد؟ به اندازه کافی ساده، با استفاده از دستور "start slave heta".
بنابراین، ما یک استاد با پایگاه داده testdb1 و testdb2 داریم که به ترتیب روی replica-1 و replica-2 تکرار می شوند. بیایید تکرار هر دو پایگاه داده را در replica-1 بدون توقف Master تنظیم کنیم.
با دستور Replica-2 را متوقف کنید و موقعیت Master را به خاطر بسپارید:
[ایمیل محافظت شده]> STOP SLAVE.
[ایمیل محافظت شده]> نشان دادن وضعیت برده\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

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

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

تکرار را متوقف کنید و موقعیت استاد را به خاطر بسپارید:
[ایمیل محافظت شده]> STOP SLAVE.
[ایمیل محافظت شده]> نشان دادن وضعیت برده\G
Exec_Master_Log_Pos: 501

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

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

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

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

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

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

Castling Master و Replica

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

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

و یک کاربر برای تکرار اضافه کنید:
[ایمیل محافظت شده]> GRANT Replication Slave ON ‘testdb’.* TO ‘replication’@’192.168.1.101′ شناسایی شده با «رمز عبور»؛

مستر غیرفعال مانند یک ماکت معمولی تکثیر می‌شود، اما لاگ‌های باینری نیز ایجاد می‌کند - یعنی می‌توانیم از آن شروع به تکثیر کنیم. بیایید با دستور "show master status" از این موضوع مطمئن شویم:
[ایمیل محافظت شده]> نشان دادن وضعیت کارشناسی ارشد\G
فایل: mysql-bin.000001
موقعیت: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

حال برای اینکه مستر غیرفعال را به حالت فعال بیاورید، باید تکثیر روی آن را متوقف کنید و تکرار را روی استاد فعال قبلی فعال کنید. برای اطمینان از اینکه داده ها در زمان سوئیچ از بین نمی روند، استاد فعالباید قفل نوشتن باشد.
[ایمیل محافظت شده]> میزها را با قفل خواندن
[ایمیل محافظت شده]> SET GLOBAL read_only = روشن.
[ایمیل محافظت شده]> STOP SLAVE.
[ایمیل محافظت شده]> نشان دادن وضعیت استاد؛
فایل: mysql-bin.000001
موقعیت: 61
[ایمیل محافظت شده]> CHANGE MASTER TO MASTER_HOST = "192.168.1.102"، MASTER_USER = "تکرار"، MASTER_PASSWORD = "رمز عبور"، MASTER_LOG_FILE = "mysql-bin.000001"، MASTER_LOG_POS = 61;
[ایمیل محافظت شده]> start Slave;
تمام است، بنابراین ما استاد فعال را تغییر دادیم. می توانید قفل را از استاد سابق بردارید.

نتیجه

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

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

برچسب ها: اضافه کردن برچسب

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

تکثیر MySQL Master-Slave

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

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

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

راه اندازی Replication به هیچ وجه دشوار نیست، زیرا مکانیزم از همان ابتدا در MySQL تعبیه شده است.

راه اندازی روی سرور Master

بیایید با ویرایش فایل پیکربندی my.cnf شروع کنیم، که اغلب در /etc/mysql/my.cnf قرار دارد. یافتن و برداشتن نظر (حذف #)، یا نوشتن چنین خطوطی ضروری است.

bind-address = 0.0.0.0 server-id = 1 log_bin = /var/log/mysql/mysql-bin.log

مهم! اگر bind-address قبلا ثبت شده باشد، باید تغییر داده شود، در غیر این صورت امکان برقراری ارتباط بین سرورها وجود نخواهد داشت.

بلافاصله پس از آن، پایگاه داده را روی سرور راه اندازی مجدد می کنیم.

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

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

اعطای تکرار SLAVE در *.* به "slave_user"@"%" شناسایی شده توسط "slave_password"; امتیازات فلاش؛

جایی که به جای "slave_user" و "slave_password" باید لاگین و رمز عبور را برای Slave بنویسید.

حالا بیایید داده های مربوط به master را ببینیم

نشان دادن وضعیت کارشناسی ارشد؛

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

تنظیم در سرور Slave

اولین قدم این است که یک پایگاه داده با همان نامی که قرار است تکرار کنیم ایجاد کنیم. این گام مهمی است و نباید از آن غفلت کرد. سپس به فایل پیکربندی آشنا بروید my.cnf و تنظیمات را بنویسید.

server-id = 2 relay-log = /var/log/mysql/mysql-relay-bin.log bin-log = /var/log/mysql/mysql-bin.log

مهم! مسیر ورود به bin log در bin-log نوشته می شود در سرور میزبان . شناسه سرور باید با شناسه اصلی متفاوت باشد، تنظیم آن بر روی ۱ بیشتر راحت است.

CHANGE MASTER TO MASTER_HOST="1.1.1.1", MASTER_USER="slave_user", MASTER_PASSWORD="slave_password", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 107; START SLAVE;

در جایی که هاست آدرس IP master است، لاگین و رمز عبور مطابق با آنچه در master ایجاد کردیم، master_log_file و master_log_pos با اطلاعات از آخرین مورد از پیکربندی سرور اصلی .

از این پس تمامی تغییرات پایگاه داده از master به slave منتقل می شود.

بررسی وضعیت تکرار

به جز دستور SHOW MASTER STATUS؛ مشابهی برای Slave SLAVE STATUS\G وجود دارد که جدولی را با اطلاعات نمایش می دهد. نشانه اصلی اتصال و کارکرد صحیح سرورها وجود چنین خطوطی است

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

نامگذاری ها:

  • master - سرور اصلی که داده های آن باید کپی شوند.
  • replica - یک سرور تعمیر شده که یک کپی از داده های استاد را ذخیره می کند

برای تنظیم Replication در MySQL، باید دنباله ای از اقدامات توضیح داده شده در زیر را دنبال کنید، اما این یک جزم نیست و بسته به شرایط ممکن است پارامترها تغییر کنند.

در سرور اصلی، فایل my.cnf را ویرایش کنید، خطوط زیر را به بخش mysqld اضافه کنید:

server-id=log-bin=mysql-bin log-bin-index=mysql-bin.index log-error=mysql-bin.err relay-log=relay-bin relay-log-info-file=relay-bin. اطلاعات relay-log-index = relay-bin.index expire_logs_days=7 binlog-do-db =

  • - شناسه منحصر به فرد سرور MySQL، یک عدد در محدوده 2 (0-31)
  • - نام پایگاه داده، اطلاعاتی که در مورد آن در گزارش باینری نوشته می شود، اگر چندین پایگاه داده وجود داشته باشد، هر کدام به یک خط جداگانه با پارامتر binlog_do_db نیاز دارند.

در Slave، فایل my.cnf را ویرایش کنید، خطوط زیر را به بخش mysqld اضافه کنید:

server-id=master-host=master master-user=replication master-password=password master-port=3306 relay-log=relay-bin relay-log-info-file=relay-log.info relay-log-index= relay-log.index replicate-do-db =

در سرور اصلی، یک کاربر تکراری با حق تکثیر داده ها اضافه کنید:

اعطای SLAVE REPLICATION ON *.* به "replication"@"replica" شناسایی شده توسط "password"

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

[ایمیل محافظت شده]> FLASH TABLES با قفل خواندن. [ایمیل محافظت شده]> SET GLOBAL read_only = روشن.

دستور باز کردن قفل این است:

[ایمیل محافظت شده]> SET GLOBAL read_only = OFF.

بیایید از تمام پایگاه های داده روی سرور اصلی (یا آنهایی که نیاز داریم) نسخه پشتیبان تهیه کنیم:

[ایمیل محافظت شده]# tar -czf mysqldir.tar.gz /var/lib/mysql/

یا با استفاده از ابزار mysqldump:

[ایمیل محافظت شده]# mysqldump -u root -p --lock-all-tables > dbdump.sql

بیایید هر دو سرور را متوقف کنیم (در برخی موارد، می توانید بدون آن کار کنید):

[ایمیل محافظت شده]# mysqlamdin -u root -p shutdown [ایمیل محافظت شده]# mysqlamdin -u root -p shutdown

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

[ایمیل محافظت شده]# سی دی /var/lib/mysql [ایمیل محافظت شده]# tar -xzf mysqldir.tar.gz

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

[ایمیل محافظت شده]# mysql -u root -p< dbdump.sql

بیایید mysql را در سرور اصلی (و در صورت لزوم در Slave) شروع کنیم:

[ایمیل محافظت شده]# /etc/init.d/mysql start [ایمیل محافظت شده]# /etc/init.d/mysql start

بیایید کار سرورهای master و slave را بررسی کنیم:

[ایمیل محافظت شده]> start Slave; [ایمیل محافظت شده]> نشان دادن وضعیت برده\G [ایمیل محافظت شده]> نشان دادن وضعیت کارشناسی ارشد\G

در سرور برده، گزارش های موجود در فایل master.info را بررسی کنید، آنها باید حاوی درخواست هایی برای تغییر داده ها در پایگاه داده باشند. بنابراین این فایل باینری ابتدا باید به فرمت متن تبدیل شود:

[ایمیل محافظت شده]# mysqlbinlog master.info > master_info.sql

در صورت بروز خطا، می توانید از دستورات زیر استفاده کنید:

[ایمیل محافظت شده]> Slave را متوقف کنید. [ایمیل محافظت شده]> RESET SLAVE. [ایمیل محافظت شده]> RESET Master;

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

برای افزودن داغ سرورهای تکرار، می توانید از نحو استفاده کنید:

[ایمیل محافظت شده]> نشان دادن وضعیت برده\G [ایمیل محافظت شده]> نشان دادن وضعیت کارشناسی ارشد\G [ایمیل محافظت شده]> CHANGE MASTER TO MASTER_HOST = "master"، MASTER_USER = "Replication"، MASTER_PASSWORD = "رمز عبور"، MASTER_LOG_FILE = "mysql-bin.000004 "، MASTER_LOG_POS = 155; [ایمیل محافظت شده]> START SLAVE.

اطلاعات وضعیت ها موقعیت و نام فایل گزارش فعلی را نشان می دهد.

در مورد تکرار ناهمزمان، به روز رسانی یک ماکت پس از مدتی به دیگران منتشر می شود و نه در همان تراکنش. بنابراین، تکثیر ناهمزمان یک تأخیر یا بازه زمانی ایجاد می‌کند که طی آن ممکن است تک تک ماکت‌ها واقعاً یکسان نباشند. اما این نوع تکرار جنبه‌های مثبتی نیز دارد: سرور اصلی نگران همگام‌سازی داده‌ها نیست، می‌توانید پایگاه داده (مثلاً برای ایجاد یک نسخه پشتیبان) را در یک ماشین برده بدون مشکل برای کاربران مسدود کنید.

فهرست منابع استفاده شده

  1. Habrahabr.ru - مبانی تکرار در MySQL (http://habrahabr.ru/blogs/mysql/56702/)
  2. ویکی پدیا (http://ru.wikipedia.org/wiki/Replication_(مهندسی_کامپیوتر))

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

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

این گزارش نمی تواند:


همه اینها در اینترنت است، تجزیه نحو منطقی نیست.

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

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

تکثیر به اشکال مختلفی وجود دارد. محورهای مختلف مقایسه:

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

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

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

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

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

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

هیچ «تعهد با موفقیت انجام شد، یعنی چه؟» در اینجا خودداری کنید. یک 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 هنوز به طور کامل از بین نرفته است، زمانی که گره ای که تغییرات را ایجاد کرده است موظف است آنها را به تمام گره های دیگر ارسال کند. از نقطه نظر وضعیت برنامه نویسی و ردیابی، این هنوز یک دردسر است. بنابراین، قوانین مبتنی بر Pull. برنامه ریزی به روز رسانی از یک گره خاص بسیار آسان تر از نظارت بر یک خوشه آشفته از کپی های شما در یک گره است.

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

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

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

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

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

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

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

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

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


برنامه متصل به سرور، آن را در یک جدول قرار داده و قطع کنید.

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


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

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

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

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

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

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

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

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


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

  • Master چند رشته ای است، اما Slave نه. واضح است که اگر مستر بار را در چهار هسته بریزد، برده وقت ندارد این بار را در یک هسته بریزد. همه چیز خیلی بد است.
  • حالت برده با نام موقعیت در فایل اصلی تعیین می شود. در مورد آن فکر کنید - وضعیت یک گره در خوشه با نام فایل و موقعیت این فایل در گره دیگر خوشه تعیین می شود، که با آن هر چیزی ممکن است به هر دلیلی اتفاق بیفتد!
  • "صرفه جویی" RBR. معلوم می شود که به طور پیش فرض، تصاویر کامل قبل / بعد از ردیف در آنجا نوشته شده است، i.e. ما یک ستون را در یک ردیف پنج کیلوبایتی تغییر داده ایم، اوه! - 10 کیلوبایت ترافیک و 20-40 بایت سربار در هر خط، سپس op! - چنین خط جسورانه ای از نسخه قبلی در حال رفتن است، op! – به دنبال این نسخه با مقادیر جدید می رود. مدیران یکپارچه زوزه می کشند! با این حال، از نظر برخی از برنامه‌های کاربردی منحرف، مانند خوانندگان خارجی که سعی می‌کنند به سرور 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 دوباره پخش کنید. ناگهان، حتی در این داستان ساده، وحشت رخ می دهد، زیرا ترکیب - ما از یک پایگاه داده استفاده می کنیم، و جدول را در پایگاه داده دیگری از طریق یک نحو جالب به روز می کنیم - به نوعی رفتار می کند ... اما دقیقاً چگونه رفتار خواهد کرد، مشخص نیست، زیرا فیلترهای مختلف در زمان های مختلف کار می کنند.

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

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

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


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

فوکوس شماره 2 - همه برده را بگیر - دلپذیرتر. هیچ بررسی غیرضروری وجود ندارد - چه چیزی از چه کسی پرواز می کند، به چه کسی می رسد و با آن چه باید کرد. به همین دلیل، می‌توانید کارهای خنده‌داری مانند یک برده انجام دهید، که یا بخشی از داده‌های دسته‌ای از سرورها به طور هدفمند ادغام می‌شوند، یا تمام داده‌های همه سرورها به طور هدفمند ادغام می‌شوند - سروری با همه، همه نسخه‌های پشتیبان. اما، تکرار می کنم، تکرار وجود دارد، یعنی. یک ابزار اساسی وجود دارد که جدول A را به جای B کپی می کند و تمام.

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

در طول ارائه، آموختیم:


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

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


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

روز همگی بخیر! امروز در مقاله ما به نمونه هایی از راه اندازی تکرار از نوع "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 server_username@ip_slave شناسایی شده توسط "password";

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

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

بررسی کار جادوگر:

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

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

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

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

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

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

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

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

SET GLOBAL read_only = روشن.

ما به وضعیت master-a نگاه می کنیم:

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

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

mysqldump -uname -ppassword db_master_name > dump_db،

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

SET GLOBAL read_only = OFF.

Dump را به Slave منتقل می کنیم و مستقر می کنیم

mysql -uname -ppassword db_slave_name< dump_db

راه اندازی Replication

CHANGE MASTER TO MASTER_HOST = "آی پی استاد"، MASTER_USER = "نام کاربری"، MASTER_PASSWORD = "رمز عبور"، MASTER_LOG_FILE = "نام ورود"، MASTER_LOG_POS = موقعیت.

ip-master - ip سروری که master در آن قرار دارد، user_name - نام کاربری که در master ایجاد کردیم، نام log - مقدار File در master هنگام تخلیه پایگاه داده، موقعیت - مقدار Position در 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 برای اتصال مشخص کنیم، خط را با 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 در صورت خرابی سرور اصلی را در نظر خواهیم گرفت.