Descubrí que quizás haya una forma más genial de resolver este problema trabajando en tablas particionadas. Necesitaba eliminar particiones de algunos años atrás, y tuve que agregar algunas para 2014. Casi todas las particiones informan este error, así que también las antiguas. Choque muy desagradable.
Entonces, mientras DROPPING old y use REORGANIZE de la partición MAXVALUE (la última), creará nuevos archivos que están bien, por lo que recibo cada vez menos advertencias. Mientras tanto, ayuda a incrementar el contador de secuencia de registro, por lo que no necesito insertar datos falsos. Tengo esto sucediendo en un servidor maestro por cierto ...
Así que esto:
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;
Y esto:
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)
Eso eliminará efectivamente cada partición en el cambio y la recreará con una copia temporal del contenido de lo que estaba allí. Puede hacerlo por tabla si lo desea, mi aplicación permite que eso suceda, por lo que no tiene que preocuparse por las copias de seguridad sincronizadas, etc.
Ahora, para el resto de la tabla, dado que no he tocado todas las particiones en el proceso, algunas quedarán con la advertencia de secuencia de registro, para aquellas que están rotas pero cubiertas por esta acción de reorganización, probablemente ejecutaré esto:
ALTER TABLE Events REBUILD PARTITION p0, p1;
o eso
ALTER TABLE Events OPTIMIZE PARTITION p0, p1;
Entonces, eso me hizo pensar, podría hacer esto con tablas simples de vainilla, agregar particiones temporalmente por hash y luego eliminarlo (o mantenerlas, puedo recomendar particiones).
Sin embargo, estoy usando mariadb, no mysql (entonces XtraDB)
Quizás esto ayude a alguien. Todavía lo estoy ejecutando, hasta ahora todo bien. Cambiar ENGINE también parece hacer el trabajo, así que lo traigo de regreso entre MyIsam y ellos a InnoDB.
Es bastante lógico, si cambia ENGINE, la tabla desaparece de innodb, por lo que ya no será un problema.
ALTER TABLE Events ENGINE=MyISAM;
ALTER TABLE Events ENGINE=InnoDB;
Parece que funciona aquí. Puedo confirmar algunas cosas en tablas particionadas:
- ALTER TABLE xyz ENGINE = InnoDB es muy lento, para Aria (mariadb) dos veces más rápido, pero en general es una forma lenta de incrementar el contador de secuencia de registro
- ALTER TABLE xyz REBUILD PARTITION ALL es la forma más rápida de 'arreglar' las tablas y ayudar a incrementar el contador
- ALTER TABLE xyz ANALYZE PARTITION ALL es lento comparado con el primero y no reescribe las particiones que están bien. RECONSTRUCCIÓN asegura una reescritura en un esquema de tabla temporal.
Usé los últimos en varias mesas. Las advertencias ocurren cuando se trata de abrir los archivos y hay una para cada definición de partición que se abre con problemas de contador. Casi rodé sobre el mostrador hoy para las últimas mesas. Creo que una vez que todo está procesado, uno necesita vaciar los registros binarios.
actualización : puedo concluir algunas cosas ahora que logré resolver este problema.
- Mi bloqueo fue causado por la reorganización de particiones en una tabla en formato Aria (MariaDB).
- (para mí) hacer una reconstrucción de las particiones funcionó mejor y más rápido para obtener el contador de secuencia. La alteración del motor es lenta y debe hacerlo dos veces para afectar innodb. alterar a innoDB es bastante lento en comparación con MyIsam o Aria.
- Actualicé a MariaDB 5.3 y no a 5.5 (era: 5.2) y funciona bien. Creo que hay demasiados problemas con aria, particiones en 5.5 (y errores confirmados) para usar esa combinación.
- Realmente debería haber una mejor manera de restablecer el contador de secuencia de registro.