Большие Двоичные Журналы, Создаваемые При Возврате Функций

Мы используем функции для управления типами контента и группами полей, и при каждом обновлении кода, когда мы выполняем features-revert для внесения последних изменений в CTS и группы полей, мы получаем огромное количество данных, записываемых в наши двоичные журналы - примерно каждые 10 минут: 

-rw-rw----. 1 mysql mysql 1073759569 Aug  1 02:31 mysql-bin.000138
-rw-rw----. 1 mysql mysql 1073766800 Aug  1 02:42 mysql-bin.000139
-rw-rw----. 1 mysql mysql 1074139941 Aug  1 02:50 mysql-bin.000140
-rw-rw----. 1 mysql mysql 1073954804 Aug  1 02:59 mysql-bin.000141

, который быстро блокирует наши серверы MySQL.

Что может быть причиной записи большого объема данных? Что мы можем сделать на стороне MySQL и на стороне Drupal, чтобы держать это под контролем?

Author: KM., 2012-08-01
Source

1 answers

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Не эксперт по Drupal, просто администратор базы данных MySQL

На самом деле существует два класса ответов на этот вопрос

  • АВТОНОМНЫЙ СЕРВЕР БД
  • РЕПЛИКАЦИЯ ВЕДУЩЕГО/ВЕДОМОГО УСТРОЙСТВА

АВТОНОМНЫЙ СЕРВЕР БД

Если вы знаете, что собираетесь выполнить feature-revert, самое простое, что можно сделать, это

Автономный метод #1: Отключить двоичные журналы

  • ШАГ 01) Выполнить SET GLOBAL SQL_LOG_BIN = 0;
  • ШАГ 02) Запустите свой feature-revert
  • ШАГ 03) Выполнить SET GLOBAL SQL_LOG_BIN = 1;

Это отключит двоичное ведение журнала во время возврата функции и ее последующего повторного включения

Автономный метод #2: Удалите Все Двоичные Журналы, Кроме Последнего

Вы можете создать задание, которое выполняет следующее:

PURGE BINARY LOGS BEFORE NOW();

Автономный метод #3: Стереть Все Двоичные Журналы

Вы можете создать задание, которое выполняет следующее:

RESET MASTER;

РЕПЛИКАЦИЯ ВЕДУЩЕГО/ВЕДОМОГО УСТРОЙСТВА

В стандартном Ведущем/Ведомом устройстве MySQL Репликация, Ведущий Имеет Активное Двоичное Ведение Журнала, а Ведомый - Нет. Вы не можете просто отключить двоичное ведение журнала, как это было бы для автономного сервера БД, потому что вам нужно воспроизвести изменения БД функции-вернуться.

Вот что нужно сделать, чтобы остановить рост двоичных журналов и журналов ретрансляции

Мастер Репликации (Управление двоичными журналами)

По завершении feature-revert, какие двоичные журналы безопасно удалять, чтобы репликация MySQL все еще могла работать и оставаться неповрежденный?

Вот что вы делаете:

  • ШАГ 01) Запустите SHOW SLAVE STATUS\G На ведомом устройстве.

Например: 

mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.64.97.249
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000658
        Read_Master_Log_Pos: 799061333
             Relay_Log_File: relay-bin.003861
              Relay_Log_Pos: 47059
      Relay_Master_Log_File: mysql-bin.000658
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            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: 799061333
            Relay_Log_Space: 47059
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)
  • ШАГ 02) Получить двоичный журнал из Relay_Master_Log_File
    • Поле №10 из SHOW SLAVE STATUS\G
    • Это было бы mysql-bin.000658
  • ШАГ 03) На Главном устройстве запустите PURGE BINARY LOGS TO 'mysql-bin.000658';

Ведомое устройство Репликации (Управление журналами ретрансляции)

Чтобы заставить ведомое устройство ограничить объем журналов ретрансляции всего 2 ГБ, добавьте это к ведомому устройству мой.cnf

[mysqld]
relay_log_space_limit=2G

И перезапустите mysql на ведомом устройстве. Когда журнал ретрансляции полностью обработан, он автоматически удаляется и освобождает место для следующего журнала ретрансляции.

ЭПИЛОГ

Вы должны убедиться, что у вас есть этот набор в /etc/my.cnf на автономном сервере БД или главном сервере

[mysqld]
expire_logs_days = 3;

И перезапустите mysql. Это гарантирует, что все двоичные журналы старше 3 дней будут автоматически удалены.

Если вам любопытно и вы хотите знать, что работает в feature-revert, вы мог бы

  • Просмотрите исходный код модуля feature-revert
  • возьмите двоичные журналы и выгрузите содержимое в виде обычного текстового SQL

Выполните следующее: 

mysqlbinlog mysql-bin.000138 mysql-bin.000139 mysql-bin.000140 mysql-bin.000141 > Revert.sql
less Revert.sql

ОБНОВЛЕНИЕ 2012-08-09 12:40 EDT

Если вас интересует восстановление на определенный момент времени, вы должны решить, сколько дней двоичных журналов вы готовы хранить.

Вот сценарий: Допустим, вы хотите иметь возможность вернуться на 7 дней назад. Вам придется настроить следующее:

ШАГ 01) Попросите подчиненное устройство поддерживать свой набор двоичных журналов с истечением 7 дней

Добавьте это в /etc/my.cnf на ведомом устройстве

[mysqld]
log-bin=mysql-bin
expire_logs_days=7

ШАГ 02) перезапуск службы mysql

ШАГ 03) Выполните резервное копирование в полночь на ведомом устройстве следующим образом

  • ОСТАНОВИТЬ ВЕДОМОГО;
  • СБРОСИТЬ ЖУРНАЛЫ;
  • mysqldump на ведомом устройстве
  • ЗАПУСТИТЬ ВЕДОМОЕ УСТРОЙСТВО;

ШАГ 04) Удалите резервные копии старше 14 дней

Как только у вас появятся шаги 3 и 4 автоматизированы, вы должны позволить mysql вращать двоичные журналы на ведомом устройстве. Вы не должны вручную удалять двоичные журналы на ведомом устройстве. Имейте в виду, что восстановление на определенный момент времени не происходит автоматически. Это строгий ручной процесс.

Хотели бы вы получить описание восстановления на определенный момент времени??? Поехали...

Допустим, у вас есть следующее

  • Сейчас 9 августа 2012 года 12:11 вечера
  • запускайте mysqldumps на ведомом устройстве каждую ночь в полночь
  • каждая резервная копия имеет имя по дате Backup_99999999.sql в /резервных копиях
  • и у вас есть следующий список двоичных журналов на ведомом устройстве

_

-rw-rw---- 1 mysql mysql 1073742269 Aug  2 11:22 mysql-bin.001789
-rw-rw---- 1 mysql mysql 1073762807 Aug  2 16:22 mysql-bin.001790
-rw-rw---- 1 mysql mysql 1073742048 Aug  2 21:28 mysql-bin.001791
-rw-rw---- 1 mysql mysql 1073741969 Aug  3 06:34 mysql-bin.001792
-rw-rw---- 1 mysql mysql 1073741954 Aug  3 11:20 mysql-bin.001793
-rw-rw---- 1 mysql mysql 1073742182 Aug  3 16:19 mysql-bin.001794
-rw-rw---- 1 mysql mysql 1073742228 Aug  3 21:37 mysql-bin.001795
-rw-rw---- 1 mysql mysql 1073753003 Aug  4 06:32 mysql-bin.001796
-rw-rw---- 1 mysql mysql 1073742100 Aug  4 13:18 mysql-bin.001797
-rw-rw---- 1 mysql mysql 1073741891 Aug  4 18:56 mysql-bin.001798
-rw-rw---- 1 mysql mysql 1073742424 Aug  5 06:12 mysql-bin.001799
-rw-rw---- 1 mysql mysql 1073742017 Aug  5 18:35 mysql-bin.001800
-rw-rw---- 1 mysql mysql 1073741952 Aug  6 05:27 mysql-bin.001801
-rw-rw---- 1 mysql mysql 1073757571 Aug  6 13:00 mysql-bin.001802
-rw-rw---- 1 mysql mysql 1073742172 Aug  6 17:35 mysql-bin.001803
-rw-rw---- 1 mysql mysql 1073742067 Aug  7 00:35 mysql-bin.001804
-rw-rw---- 1 mysql mysql 1073777487 Aug  7 10:45 mysql-bin.001805
-rw-rw---- 1 mysql mysql 1073791986 Aug  7 15:51 mysql-bin.001806
-rw-rw---- 1 mysql mysql 1073742035 Aug  7 20:37 mysql-bin.001807
-rw-rw---- 1 mysql mysql 1073741978 Aug  8 05:28 mysql-bin.001808
-rw-rw---- 1 mysql mysql 1073742217 Aug  8 10:30 mysql-bin.001809
-rw-rw---- 1 mysql mysql 1073742422 Aug  8 14:41 mysql-bin.001810
-rw-rw---- 1 mysql mysql 1073743447 Aug  8 18:47 mysql-bin.001811
-rw-rw---- 1 mysql mysql 1073742241 Aug  9 00:36 mysql-bin.001812
-rw-rw---- 1 mysql mysql 1073741985 Aug  9 08:45 mysql-bin.001813
-rw-rw---- 1 mysql mysql  743967477 Aug  9 12:10 mysql-bin.001814

Вы хотите перезагрузить Мастер, возвращаясь к 5 августа 2012 года 02:30 вечера

Вот ваши шаги

ШАГ 01) Возьмите все двоичные журналы, которые охватывают 5 августа 2012 года с 12:00 до 2:30 вечера. Это будут двоичные журналы mysql-bin.001799 и mysql-bin.001800. Они используются, потому что

  • ПРИНЦИП: первая запись binlog также является последней записью предыдущего binlog
    • последняя запись в mysql-bin.001798 - 4 августа 18:56 (18:56 вечера) 2012-08-04 18:56:00
    • первая запись в mysql-bin.001799 - 4 августа 18:56 (6:56 вечера) 2012-08-04 18:56:00
    • последняя запись в mysql-bin.001799 5 августа 06:12 (6:12 утра) 2012-08-05 06:12:00
    • первая запись в mysql-bin.001800 5 августа 06:12 (6:12 утра) 2012-08-05 06:12:00
    • последняя запись в mysql-bin.001800 - 5 августа 18:35 (6:35 вечера) 2012-08-05 18:35:00

Диапазон 2012-08-04 18:56:00 до 2012-08-05 18:35:00 является самым узким диапазоном, который охватывает 2012-08-05 00:00:00 до 2012-08-05 14:30:00. Вот почему бинлоги mysql-bin.001799 и mysql-bin.001800 являются правильным выбором

ШАГ 02) Создайте весь SQL, который выполнялся 5 августа 2012 года с 12:00 до 2:30 вечера

mysqlbinlog --start-datetime="2012-08-05 00:00:00" --stop-datetime="2012-08-05 14:30:00" mysql-bin.001799 mysql-bin.001800 > ForwardChanges.sql

ШАГ 03) Сделайте копию резервной копии от 5 августа 2012 года в полночь на PITR.sql

cp /backups/Backup_20120805.sql PITR.sql

ШАГ 04) Добавить Перенаправление изменений.sql в PITR.sql

cat ForwardChanges.sql >> PITR.sql

ШАГ 05) Загрузите PITR.sql в мастер

mysql -h IPAddressOfMaster -u ... -p... < PITR.sql

Когда сценарий будет завершен, база данных будет в том состоянии, в котором она была по состоянию на 5 августа 2012 года 2:30 вечера

Довольно просто, да???

 2
Author: RolandoMySQLDBA, 2012-08-09 16:40:01