У архітектурах MySQL з високою доступністю первинна реплікація бази даних є дуже поширеним типом.
Коли первинна база даних виходить з ладу, ви можете оновити підлеглу базу даних як нову первинну, щоб забезпечити доступність сервісу. Водночас QPS усього кластера можна покращити, розширивши підлеглої бібліотеки.
У архітектурі реплікації майстер-слейв MySQL використовує binlog для досягнення узгодженості даних майстер-слейв.
Як показано на рисунку вище, реплікація майстер-слейв MySQL в основному складається з наступних кроків
1. Майстер записує зміни у бінарному журналі
2. Підлеглий io_thread запросити бінлог основної бібліотеки та записати отриманий журнал бінлогу до релейного журналу
3. Події рабства sql_thread повторення у журналі ретранслятора
Окрім того, що binlog є посиланням для реплікації майстра-підлеглого MySQL, він також виконує інші функції. Наприклад, що саме:
1. Використовуйте інструмент mysqlbinlog для аналізу файлу бінлогу з метою відновлення бази даних у точці часу.
2. Флешбек бази даних на основі подій binlog (MariaDB може безпосередньо використовувати mysqlbinlog для флешбеку)
3. Відкритий онлайн-інструмент зміни таблиць на Github gh-ost також реалізований через binlog
4. Ви також можете поступово підписуватися та споживати, розбираючи бінлоги
Бінлог дуже корисний, але неминуче зіткнутися з певними проблемами у щоденній експлуатації та обслуговуванні. Ось деякі помилки, пов'язані з бінлогом.
Одне з найпоширеніших питань
Явище
mysqlbinlog5.5 розбирає файл binlog mysql5.7
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Аналіз причин
MySQL 5.6 та інші вищі версії binlog-файлів додали нові події binlog, такі як події GTID.
mysqlbinlog у mysql5.5 не розпізнає такі події binlog.
Обхідний шлях
Використовуйте вищу версію mysqlbinlog, щоб розв'язати бінлог, згенерований нижчою версією mysql
Поширене питання друге
Явище
З'являється здоровий mysql-сервер, який показує статус slave
Last_SQL_Error:Помилка читання релейного журналу: Не вдалося розібрати запис події релейного журналу.
Можливі причини: бінарний журнал майстра пошкоджений (це можна перевірити, запустивши 'mysqlbinlog' у бінарному журналі),
Журнал реле підлеглого пошкоджений (це можна перевірити, запустивши 'mysqlbinlog' у журналі реле),
мережеву проблему або помилку в коді MySQL майстра чи слейва.
Якщо хочете перевірити бінарний журнал майстра або реле підлеглого,
ви зможете дізнатися їхні імена, видавши «ПОКАЗАТИ СТАТУС РАБА» для цього раба.
Аналіз причин
Записи в журналі реле не можуть бути прочитані через помилки бінлогу в головній бібліотеці, помилки релейного журналу в підлеглій бібліотеці або мережеві проблеми та помилки. Зазвичай це спричинено збоєм мережі або надмірним навантаженням на підлеглу бібліотеку, що призводить до неправильного форматування релейного журналу.
Обхідний шлях
Після знаходження поточної точки часу синхронізації та скидання синхронізації майстер-слейв буде згенерований новий журнал реле, і синхронізація майстер-слейв буде відновлена.
З результату "show slave status\G" знайдіть таку інформацію:
Relay_Master_Log_File: mysql-bin.002540 // The binlogExec_Master_Log_Pos of master, зчитуваний бібліотекою slave: 950583017 // Точка позиції, виконана на підлеглому
Зупиніть підлеглий режим і знову встановіть синхронізацію, починаючи з файлу binlog, який слейв прочитав, і позиції, яку було виконано.
Relay_Master_Log_File: mysql-bin.002540 // The binlogExec_Master_Log_Pos of master, зчитуваний бібліотекою slave: 950583017 // Точка позиції, виконана на підлеглому
Поширене питання третє
Явище
Відновити статус show slave після помилки простою:
Last_SQL_Error: Помилка ініціалізації релейного журналу: Помилка зчитування заголовка з бінарного журналу
Last_SQL_Error: Помилка ініціалізації позиції релейного журналу: Binlog має погане магічне число; Це не бінарний файл журналу, який може використовувати ця версія MySQL
Аналіз причин
Простої, такі як відключення живлення, згоряння материнської плати тощо, або незаконне вимкнення, що призводить до пошкодження файлу релейного біна
Обхідний шлях
Те саме друге питання.
relay_log_recovery = 1 також можна встановити.
Коли підлеглий журнал виходить з ладу, якщо релей-журнал пошкоджений і частина релейного журналу не оброблена, релейний журнал автоматично залишається, і журнал повторно забирається з майстра, завершуючи відновлення релейного журналу.
Поширене питання четверте
Явище
З'являється при зміні майстра на після відключення перезавантаження з бібліотечної машини
Помилка (Код 1201): Не вдалося ініціалізувати структуру головної інформації; більше повідомлень про помилки можна знайти в журналі помилок MySQL
або
ПОМИЛКА 1872 (HY000): Slave не зміг ініціалізувати структуру релейного журналу з репозиторію
Аналіз причин
Простої, такі як відключення електроенергії, згоряння материнської плати тощо, або незаконне вимкнення, що пошкоджує файли master.info або realy-log.info
Обхідний шлях
Раб> скинув Slave All, змінив Master на
Профілактичні заходи
Налаштування профілю
relay_log_info_repository=таблиця
master_info_repository=таблиця
Рушій зберігання MySQL 5.6.5 mysql.slave_master_info і mysql.slave_relay_log_info за замовчуванням встановлений на MyISAM, і потрібно змінити його на рушій зберігання InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info таблиця буде оновлена після sync_master_info подій.
mysql.slave_relay_log_info таблиця оновлюватиметься з кожним комітом транзакції.
Поширене питання 5
Явище
Майстер-підлеглий спочатку binlog_format оператор, після зміни основної бази даних binlog_format на рядок, з бібліотеки з'являється статус підлеглого:
Last_Error: Помилка, що виконує подію рядка: «Не може виконати оператор: неможливо записувати у бінарний журнал, оскільки оператор у форматі рядка, а BINLOG_FORMAT = ОПЕРАТОР.»
Аналіз причин
Коли основна база даних binlog_format рядок, а оператор binlog_format підлеглої бібліотеки is, з'явиться наведена вище помилка.
Але головна бібліотека binlog_format — це заява, а рабська бібліотека binlog_format ряд;
Або якщо основна база даних binlog_format є рядком, помилка не буде зареєстрована, якщо binlog_format бази даних змішана.
Якщо ваш SQL-потік дійсно налаштований з
binlog_format=STATEMENT, коли отримує подію ROW, він зупиняється. The
причина полягає в тому, що він не зможе зареєструвати цю подію ROW у форматі STATEMENT (іноді це називається ін'єкцією ROW, що або є
оператор BINLOG або подія ROW, виконана SQL-потоком підлеглого)
Детальна причина:https://bugs.mysql.com/bug.php?id=69095
Обхідний шлях
РАБ> ЗУПИНИСЬ РАБ;
SLAVE> SET GLOBAL binlog_format=MIXED;
РАБСТВО> ПОЧАТИ РАБСТВО;
Поширене питання номер 6
Явище
Помилка при синхронізації mysql5.6 з mysql5.5
Last_IO_Error: Отримав фатальну помилку 1236 від майстра при читанні даних із бінарного журналу: 'Slave не може обробляти події реплікації з контрольною сумою, яку майстер налаштований на лог; Перша подія 'mysql-bin.000001' о 120, остання подія читалася з 'mysql-bin.000001' на 120, останній байт читався з 'mysql-bin.000001' на 120.'
Аналіз причин
Щоб вирішити проблему того, що SQL-оператори, що працюють на основному сервері, не узгоджуються з SQL-операторами, що працюють на сервері (це називається event corrupt) через помилки програмного та апаратного забезпечення або мережевої передачі, MySQL 5.6 додає функцію Replication Event Checksum. Коли подія записується у бінарний журнал, контрольна сума також записується у бінарний журнал, а після передачі події підлеглому через мережу вона перевіряється на слейві і записується у релейний журнал підлеглого. Оскільки події та контрольні суми фіксуються на кожному кроці, ми швидко можемо з'ясувати, у чому проблема.
У mysql5.6.5 та пізніших версіях binlog_checksum значення за замовчуванням — crc32,
Значення за замовчуванням binlog_checksum попередній версії не було
рішення
Slave> set global binlog_checksum=none
Поширене питання 7
Явище
Після того, як диск заповниться, вручну очистите файл binlog і mysql-bin.index
Бінарні журнали шоу порожні, але статус шоу майстер є нормальним.
mysql> показувати бінарні журнали; Порожній набір (0,00 сек)mysql> статус майстер-шоу;
+------------------+-----------+--------------+------------------+
| Файл | Позиція | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Аналіз причин
Перевіривши файл mysql-bin.index, я знайшов перший порожній рядок.
У вихідному коді mysql rpl_master.cc:show_binlogs() ви знайдете наступний код:
/* The file ends with EOF or empty line */
тоді як ((довжина=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Порожні рядки вважаються кінцем документа
(Джерело.)https://yq.aliyun.com/articles/213657Стаття)
Профілактичні заходи
Не видаляйте бінлог вручну, не редагуйте файл mysql-bin.index вручну, якщо ви не знаєте, що робите, інакше можете самі собі шкодити!
зведення
DBA повинні звертати увагу на покращення бінлогування в кожній новій версії MySQL (наприклад, функцію gtid, додану у версії 5.6, Enhanced Multi-threaded Slaves у версії 5.7), і детально розуміти значення кожного параметра, щоб розуміти, що вони мають на увазі, коли стикаються з помилками, і легко вирішувати проблеми.
|
Опубліковано 25.09.2018 10:31:40
|
|
|
|
