Я обнаружил, что, возможно, есть более крутой способ решения этой проблемы, работающий с многораздельными таблицами. Мне нужно было удалить разделы несколько лет назад, и мне пришлось добавить несколько на 2014 год. Почти все разделы сообщают об этой ошибке, также как и старые. Очень неприятный сбой.
Таким образом, в то время как УДАЛЕНИЕ старого и использование REORGANIZE раздела MAXVALUE (последнего), он будет создавать новые файлы, которые в порядке, поэтому я получаю все меньше и меньше предупреждений. В то же время, это помогает увеличить счетчик последовательности журнала, поэтому мне не нужно вставлять фиктивные данные. У меня это происходит на главном сервере, кстати ...
Итак, это:
ALTER TABLE Events DROP PARTITION p1530 , p1535 , p1540 , p1545 ,
p1550, p1555 , p1560 , p1565 , p1570 , p1575 , p1580 , p1585 , p1590 ,
p1595 , p1600 , p1605 , p1610 , p1615 , p1620 , p1625 , p1630 , p1635 ,
p1640 , p1645 , p1650 , p1655 , p1660 , p1665 , p1670 , p1675 , p1680 ,
p1685 , p1690 , p1695 , p1700 , p1705 , p1710 , p1715 , p1720 , p1725 ,
p1730 , p1735 , p1740 , p1745 , p1750 , p1755 , p1760 , p1765 , p1770 ,
p1775 , p1780 , p1785 , p1790 , p1795 , p1800 , p1805 , p1810 , p1815 ,
p1820 , p1825 , p1830 , p1835 , p1840;
И это:
ALTER table Events REORGANIZE PARTITION p3000 INTO (
PARTITION p3500 VALUES LESS THAN (TO_DAYS('2013-01-01')),
PARTITION p3510 VALUES LESS THAN (TO_DAYS('2013-01-04')),
PARTITION p3520 VALUES LESS THAN (TO_DAYS('2013-01-07')),
PARTITION p3530 VALUES LESS THAN (TO_DAYS('2013-01-10'))
...
PARTITION p4740 VALUES LESS THAN (TO_DAYS('2014-01-08')),
PARTITION p9000 VALUES LESS THAN MAXVALUE)
Это эффективно отбросит каждый раздел в изменении и воссоздает его с временной копией содержимого того, что было там. Вы можете сделать это для каждой таблицы, если хотите, мое приложение позволяет это делать, поэтому не нужно беспокоиться о синхронизированных резервных копиях и т. Д.
Теперь для остальной части таблицы, так как я не коснулся всех разделов в процессе, некоторые останутся с предупреждением о последовательности журналов, для тех, которые сломаны, но и покрыты этим действием реорганизации, я, вероятно, выполню это:
ALTER TABLE Events REBUILD PARTITION p0, p1;
или это
ALTER TABLE Events OPTIMIZE PARTITION p0, p1;
Итак, это заставило меня задуматься: вы можете сделать это с простыми ванильными таблицами, временно добавить разделы с помощью хэша, а затем удалить его (или оставить их, я настоятельно рекомендую разделы).
Однако я использую mariadb, а не mysql (поэтому XtraDB)
Возможно, это кому-то поможет. Я все еще бегаю, пока все хорошо. Смена ENGINE, похоже, тоже хорошо справляется с этой задачей, поэтому я перенесу ее обратно между MyIsam и ими обратно в InnoDB.
Это довольно логично, если вы измените ENGINE, таблица исчезнет из innodb, так что это больше не будет проблемой.
ALTER TABLE Events ENGINE=MyISAM;
ALTER TABLE Events ENGINE=InnoDB;
это похоже на работу здесь. Я могу подтвердить несколько вещей на секционированных таблицах:
- ALTER TABLE xyz ENGINE = InnoDB очень медленный, в Aria (mariadb) в два раза быстрее, но в целом медленный способ увеличить счетчик лог-последовательности
- ALTER TABLE xyz REBUILD PARTITION ALL - это самый быстрый способ «исправить» таблицы и помочь увеличить счетчик
- ALTER TABLE xyz ANALYZE PARTITION ALL медленно сравнивается с первым и не переписывает разделы, которые подтвердили, что все в порядке. REBUILD обеспечивает перезапись схемы временной таблицы.
Я использовал последние на нескольких столах. Предупреждения появляются, когда он пытается открыть файлы, и есть одно для каждого определения раздела, которое он открывает с проблемами счетчика. Почти перевернулся сегодня за последние столы. Я думаю, что после того, как все это обработано, нужно очистить двоичные журналы.
обновление : я могу сделать несколько выводов, теперь мне удалось решить эту проблему.
- Мой сбой был вызван реорганизацией разделов таблицы в формате Aria (MariaDB).
- (для меня) перестройка разделов работала лучше и быстрее, чтобы получить счетчик последовательности. Изменение двигателя происходит медленно, и вам нужно сделать это дважды, чтобы повлиять на innodb. изменение innoDB происходит довольно медленно по сравнению с MyIsam или Aria.
- Я обновил до MariaDB 5.3, а не до 5.5 (был: 5.2), и он работает нормально. Я думаю, что слишком много проблем с aria, разделами в 5.5 (и подтвержденными ошибками), чтобы использовать эту комбинацию.
- Там действительно должен быть лучший способ сбросить счетчик последовательности журнала.