Первой ласточкой того, что это произошло станет сообщение “SLAVE DOWN” от мониторинговой системы и запись в MySQL-логе слейва сродни этой:

090917 14:55:51 [ERROR] Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 71, event_type: 19
090917 14:55:51 [ERROR] Error reading relay log event: slave SQL thread aborted because of I/O error
090917 14:55:51 [ERROR] Slave: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' o
n the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL
code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 0
090917 14:55:51 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'bin-us1.000022' position 17007149


Попытки пропустить неугодные записи старым добрым методом:
slave stop;
set global sql_slave_skip_counter=1;
slave start;
в данном случае не помогают.

Как вариант решения предлагаю:

1. Останавливаем slave: “SLAVE STOP;”
2. “Выуживаем” из текста ошибки имя бинлога и позицию, на которой произошла ошибка.
   В данном случае это bin-us1.000022 и позиция 17007149
3. На мастере выполняем запрос “FLUSH LOGS;”
4. Делаем дамп бинлога начиная с найденной позиции:
   mysqlbinlog --start-position=17007149 bin-us1.000022  >  bin-us1-from17007149.sql
5. Загружаем полученный дамп на слейве с ключем “–force”
   mysql --force -uuser -ppassword database < bin-us1-from17007149.sql
6. Выполняем на слейве “FLUSH LOGS;”
7. В data-директории находим relay-log с максимальным номером и размером около 100 байт (в моем случае это mysqld-relay-bin.000037)
8. В той же директории в файле relay-log.info
   первую строку заменяем на имя только что найденного relay-log-а, во вторую вписываем 0, в третью – следующий после “испорченного” бинлог, в четвертую – 0
   Получится что-то вроде:
   /var/lib/mysql/mysqld-relay-bin.000037
0
bin-us1.000023
0
9. Дальше на слейве выполняем:
   CHANGE MASTER TO MASTER_LOG_FILE='bin-us1.000023', MASTER_LOG_POS=0;
SLAVE START;
10. Ну и потом чтоб удостоверится что все “завелось”
    SHOW SLAVE STATUS\G

Должно работать.
Подозреваю что пункты 4 и 5 можно обьеденить в один, более простой и элегантный.
Но как это сделать – не гуглил.

if ( <row exists in table> )
   then <insert new record into table>

Из-за того, что данный блок псевдо-кода не выполяняется атомано, может возникнуть ситуация, когда между проверкой <row exists in table> и выполнением действия <insert new record> паралельный поток (клиент)  выполнит добавление новой записи и в итоге в БД окажется 2 одинаковых записи (или произойдет ошибка “duplicate key”).

Такой, не самый приятный case, в книгах по паралельному программированию называют race condition и обходят путем создания синхронизирующих блокировок , использованием “выпрямителей” и тд.

С точки зрения MySQL надо бы переписать приведенный псевдокод в таком виде:

mysql_query('LOCK TABLE `table` WRITE')

if ( <row exists in table> )
   then <insert new record into table>

mysql_query('UNLOCK TABLES') 

В таком случае таблица будет заблокирована для записи и мы будем уверены что во время выполнения нашего кода, никто, кроме текущего потока, ничего в таблицу не “дозапишет” и race condition не возникнет.

Способ вроде простой, и если мне не изменяет память, даже рекомендовался в какой-то книге по разработке web-приложений.
Самый же существенный его минус – он блокирует ВСЮ таблицу и все запросы на запись в эту таблицу будут ждать окончания выполнения блока кода и вызова “UNLOCK TABLES”.
Это, в условиях интенсивной записи в таблицу, может создать весьма критичный bottleneck в производительности всей системы.

Очень неплохо бы в таком случае выполнять блокировку на уровне не всей таблицы, а только определенной строки. Немного покопавшись в мануале MySQL, отыскал несколько встроенных функций, которые помогают это реализовать:

GET_LOCK(str, timeout)

Создает глобальный мютекс с именем str и временем жизни timeout. При попытке другого потока “занять” уже созданный мютекс, он будет ожидать пока он не освободится вызовом RELEASE_LOCK() или не пройдет timeout секунд

RELEASE_LOCK(str)

Освобождает глобальный мютекс с именем str

Кроме того есть еще 2 вспомогательные фунцкции для проверки создан ли уже мютекс, и если создан, то каким ProcessID: IS_FREE_LOCK() и IS_USED_LOCK()

С учетом вышесказанного описанный выше псевдокод, с использованием row-based блокировки будет выглядеть таким образом:

mysql_query('DO GET_LOCK("my-prefix.my-row-id", 60)')

if ( <row exists in table> )
   then <insert new record into table>

mysql_query('DO RELEASE_LOCK("my-prefix.my-row-id")') 

Из своего опыта работы с достаточно большими массивами данных, хранимых в современных реляционных СУБД (по большей части в MySQL) могу сказать что не менее 50% данных в любой системе – это данные которые представляют собой только “историческую” ценность.

Чаще всего по ним просчитаны-пересчитына все возможные “срезы”, построены все отчеты и вероятность их использования в дальнейшем с каждым днем все больше приближается к нулю.
Также часто бывает, что просто удалить подобные данные по разным причинам нельзя.

Будучи чуть более молодым и менее опытным, чем сейчас я делал так: разделял данные на 2 части (старые и новые), со старых делал дапм, архивировал и писал на CD, после чего смело удалял их из MySQL.
Думаю не стоит обьяснять во что выливалась внезапная необходимость поднять старый массив данных для какого-то супер-нового отчета. :)

Вот тут очень кстати вспомнить за что я люблю MySQL – это его plugable storage engines, которые существуют под любую специфичную задачу.

Потому предлагаю кратко пробежаться по особенностям ARCHIVE storage engine, созданного для хранения “архивных” данных максимально эффективно:

• данные в archive-таблицах хранятся в сжатом библиотекой zlib виде
• не поддерживает обновление и удаление даннных (UPDATE/REPLACE/DELETE) – только добавление (INSERT)
• не поддерживает индексы
• использует row-based локи
• поддерживает strict sql_mode

С появлением ARCHIVE  Storage Engine описанный выше use-case существенно преобразился: теперь старые данные не дампятся, а переносятся в “архивную” таблицу – полную копию существующей.
В результате их хранение за долгий период не является очень накладным, а удобство использования и мгновенный доступ посредством SQL сохраняется.

В качестве эксперимента приведу результаты сегодняшнего “архивирования” описанным образом одной небольшой таблицы:
(по хорошему надо было взять таблицу побольше, но под рукой такой не оказалось)
После разделения данных на “архивные” и “актуальные” и оптимизации таблицы “актулаьных” данных получил такое:

+--------------------+--------+---------------+------------+
| table_name         | engine | total_size_mb | table_rows |
+--------------------+--------+---------------+------------+
| arch_downloads_log | MyISAM |         63.68 |      45801 |
| wap_downloads_log  | MyISAM |         18.67 |      13429 |
+--------------------+--------+---------------+------------+

Итого 69тыс строк данных занимают почти 82Mb дискового пространства.
После удаления индексов из arch_downloads_log и конвертирования в тип ARCHIVE получил:

+--------------------+---------+---------------+------------+
| table_name         | engine  | total_size_mb | table_rows |
+--------------------+---------+---------------+------------+
| arch_downloads_log | ARCHIVE |          1.49 |      45801 |
| wap_downloads_log  | MyISAM  |         18.67 |      13429 |
+--------------------+---------+---------------+------------+

Итого, таблица размером в 64Mb была сжата в 1.5Mb – тоесть в 42 раза.
(хм… как интересно совпало с 42%, о которых писалось вначале заметки)

Выводы? – Тут уж думайте сами, решайте сами надо ли и поможет ли оно вам.

Ссылки:

• Документация об ARCHIVE storage engine от MySQL AB
• Обзор возможностей ARCHIVE storage engine от Robin Schumacher

P.S. Перечитал написанное  – какой-то банальщиной попахивает. Ну и ладно.

P.S.S. Ах, да! Те кто сейчас хочет подискутировать на тему “MySQL не предназначен для хранения больших обьемов данных” – предлагаю даже не начинать, ибо ответ будет единственно-правильный: “Просто вы не умеете его готовить”.

SELECT
    table_name AS table_name,
    engine,
    ROUND(data_length/1024/1024,2) AS total_size_mb,
    table_rows
FROM
    information_schema.tables
WHERE
    table_schema=DATABASE();

Показывает обьем и количество строк в таблицах MySQL.
Результат выглядит приблизительно так:

+-------------------+--------+---------------+------------+
| table_name        | engine | total_size_mb | table_rows |
+-------------------+--------+---------------+------------+
| categories        | MyISAM |          0.00 |         17 |
| downloadlinks     | InnoDB |         13.02 |      19158 |
| errors            | InnoDB |         15.02 |      84104 |
| lastdownloads     | MEMORY |          3.19 |        524 |
| providers         | MyISAM |          0.00 |         17 |
| starstags         | InnoDB |          1.52 |      14323 |
| tagids            | InnoDB |         35.59 |     759694 |
| tags              | InnoDB |       2036.00 |   21971934 |
| vars              | InnoDB |          0.02 |         51 |
| videocategories   | InnoDB |         49.58 |    1583675 |
| videos            | InnoDB |       1864.00 |    1954427 |
| videos_deleted    | MyISAM |         56.33 |      75889 |
| videostats2       | InnoDB |        271.88 |    3417776 |
| videostats2_daily | InnoDB |          0.02 |        266 |
+-------------------+--------+---------------+------------+

Правда есть один нюанс: на InnoDB-таблицах показывает количество незалоченных в данный момент строк.

P.S. А кто-то пробовал использовать ARCHIVE storage engine?
Как он в плане fail-over и repair?
Поделитесь good/bad experience?

В отличии от MyISAM, значение автоинкрементного счетчика может повторяться.
Пример:

(root@localhost) [test]> CREATE TABLE `innodb` (
  `id` int(11) NOT NULL auto_increment,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB;

(root@localhost) [test]> INSERT INTO innodb (id) VALUE(null);
(root@localhost) [test]> INSERT INTO innodb (id) VALUE(null);
(root@localhost) [test]> INSERT INTO innodb (id) VALUE(null);

(root@localhost) [test]> SELECT * FROM innodb;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
+----+
3 rows in set (0.00 sec)

(root@localhost) [test]> DELETE FROM innodb WHERE id=3;

После этого делаем рестарт MySQL-сервера и выполняем:

(root@localhost) [test]> INSERT INTO innodb (id) VALUE(null);

(root@localhost) [test]> SELECT * FROM innodb;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
+----+
3 rows in set (0.00 sec)