Mysql 4

4.9.4. Бінарний журнал оновлень

Бінарний журнал містить всю інформацію, наявну в журналі оновлень, в більш ефективному форматі. У ньому є інформація і про час виконання кожного оновлюючого базу запиту. У ньому не міститься інформації про запити, які не змінюють дані. Якщо вам потрібно журналіровать всі запити (наприклад для виявлення проблемного запиту), вам слід використовувати загальний журнал запитів. See Розділ 4.9.2, «Загальний журнал запитів».

Бінарний журнал використовується і при реплікації підлеглого сервера (slave) з головного (master) (see Розділ 4.10, «Реплікація в MySQL»).

При запуску з ключем --log-bin [= file_name] mysqld створює файл журналу, в який вносяться дані про всі оновлюють дані командах SQL. Якщо ім'я файлу не задано, за умовчанням вона засвоює майже ім'я хоста з закінченням -bin. Якщо файлу присвоєно ім'я, яке не містить шляху доступу до нього, цей файл зберігається в каталозі даних.

При введенні розширення в ім'я файлу (наприклад: --log-bin = filename.extension) це розширення видаляється без попередження.

До імені файлу бінарного журналу програма mysqld додає спеціальне розширення - номер, що збільшується при кожному виконанні команд mysqladmin refresh. mysqladmin flush-logs. FLUSH LOGS або перезапуску сервера. При досягненні файлом журналу максимального розміру, заданого в параметрі max_binlog_size. автоматично створюється новий. Всі неактивні файли бінарних журналів можна видалити командою RESET MASTER (see Розділ 4.5.4, «Синтаксис команди RESET».

На вибір даних, що записуються в журнал, впливають наступні настройки mysqld.

Вказує головному сервера що він повинен журналіровать поновлення в двійковий журнал якщо поточна (тобто обрана) база даних - це 'database_name'. Решта бази даних, особливо не відмічені, ігноруються. Майте на увазі, що якщо ви використовуєте цю опцію, то вам слід робити оновлення тільки в цій базі даних. (Приклад: binlog-do-db = some_database)

Змушує master відмовитися від занесення в журнал оновлень певної бази даних (приклад: binlog-ignore-db = some_database)

Щоб була можливість визначити, які файли журналів використовуються в даний момент, mysqld створює і індексний файл, який містить імена всіх, хто знаходиться в роботі файлів. За замовчуванням йому присвоюється той же ім'я, що і файлу журналу, але з розширенням .index. Ім'я цього файлу можна змінити за допомогою параметра --log-bin-index = [filename].

При використанні реплікації видаляти старі файли журналів не варто до тих пір, поки ви не будете впевнені в тому, що вони ніколи не знадобляться ні однієї залежної базі. Домогтися такого результату можна, запускаючи команду mysqladmin flush-logs раз в день і потім видаляючи всі журнали, створені понад 3 днів тому.

Працювати з файлами бінарного журналу можна за допомогою програми mysqlbinlog. Оновити MySQL відповідно до записів в журналі можна так:

За допомогою програми mysqlbinlog можна навіть зчитувати файли журналу прямо з віддаленого сервера MySQL!

При запуску mysqlbinlog з ключем --help на екран виводиться додаткова інформація по роботі з цією програмою.

При роботі з настройками BEGIN [WORK] або SET AUTOCOMMIT = 0 для резервного копіювання потрібно використовувати бінарний журнал, а не старий журнал оновлень.

Занесення даних в бінарний журнал відбувається відразу по завершенні виконання запиту, але до зняття блокувань. Таким чином забезпечується впевненість в тому, що журнал ведеться саме в порядку виконання запитів.

Updates to non-transactional tables are stored in the binary log immediately after execution.

Оновлення нетранзакціонних таблиць зберігаються в двійковому журналі негайно після виконання. Всі оновлення (UPDATE. DELETE або INSERT), що змінюють дані в транзакційних таблицях (наприклад, BDB-таблицю) знаходяться в кеші до виклику COMMIT. У цей момент mysqld пише всю транзакцію цілком в двійковий журнал перед тим, як виконати COMMIT. Кожен потік при запуску буде створювати буффер розміром binlog_cache_size для буферизації запитів. Якщо запит перевищує цей розмір, тоді потік відкриє тимчасовий файл для збереження транзакції. Тимчасовий файл буде видалений при виході потоку.

При запуску кожного потоку створюється буфер запитів, обсяг якого відповідає значенню параметра binlog_cache_size. Якщо запит не поміщається в буфері, потік створить тимчасовий файл для кеша. Тимчасовий файл видаляється після закінчення роботи потоку.

Параметр max_binlog_cache_size (за замовчуванням 4Гб) дозволяє обмежити загальний обсяг пам'яті, використовуваної для кешування мультітранзакціонного запиту. Якщо транзакція більше цього - буде проведений відкат.

При використанні журналу оновлень або бінарного журналу паралельні операції вставки будуть перетворені в нормальні операції вставки в командах CREATE. SELECT і INSERT. SELECT. Це зроблено спеціально - для того, щоб забезпечити можливість створення точної копії таблиць шляхом об'єднання резервної копії з журналом.

Схожі статті