Версія 5.6 бази даних MySQL з'явилася вже досить давно. і, гадаю, всі вже обізнані з вдосконаленями, які були впроваджені в цій версії. Зокрема, мене свого часу приємно вразило зростання продуктивності -- швидкість виконання деяких запитів в застосуванні, з яким я працював, зросла у 10-20 разів. Проте, зараз хочу звернутися до іншої доданої функціональності -- використання контрольних сум під час реплікації.
Технологія реплікації в найпростішому випадку передбачає дублювання інформації певного сервера баз даних (майстера) на іншому сервері (слейві). Одне з можливих використань реплікації -- резервне копіювання даних. При цьому важливим є гарантування ідентичності даних на майстері і слейві. На жаль, MySQL 5.6 не дає повної гарантії відповідності даних, проте має певне вдосконалення порівняно з версією 5.5: можливість контроля цілісності бінарних лог-файлів (які є засобом передачі інформації від майстера до слейву) за допомогою контрольних сум. Контрольні суми можуть вираховуватися як на майстері, так і на слейві. У разі пошкодження бінарних логів здійснюється відповідна сигналізація про помилку. Про це стисло і наглядно йдеться в статті Peter Zaitsev "Replication checksums in MySQL 5.6".
До речі, один з наслідків впровадження контрольних сум у реплікації в версії 5.6 -- це порушення сумісності з 5.5. Щойно спостерігав, як перехід з 5.5 до 5.6 на майстері призвів до зупинки слейва, який залишився у версії 5.6:
mysql> show slave status \G...
Slave_IO_Running: No
Slave_SQL_Running: Yes
...
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave can not handle replication events with the checksum that master is configured to log; the first event 'mysql-bin.000035' at 834715620, the last event read from './mysql-bin.000037' at 120, the last byte read from './mysql-bin.000037' at 120.'
...
Вочевидь, варто оновлювати версії на майстері і слейві синхронно.
Немає коментарів:
Дописати коментар