Pregunta sobre Wordfence Security de Wordpress:

La tabla se bloquea y muestra advertencias después de actualizar MySQL 5.6 a MariaDB 10.3

Un usuario preguntó 👇

Hola,

Estoy actualizando mi servidor de MySQL 5.6 a MariaDB 10.3 y recibo numerosos errores de bloqueo de tabla para varias cuentas, seguidos de una advertencia de verificación de tabla. A continuación, se muestra un ejemplo de una cuenta de usuario.

Example:

[ERROR] mysqld: Table './user_wp649/wpjs_wfSNIPCache' is marked as crashed and should be repaired
[Warning] Checking table:   './user_wp649/wpjs_wfSNIPCache'
[ERROR] mysqld: Table './user_wp649/wpjs_wfScanners' is marked as crashed and should be repaired
[Warning] Checking table:   './user_wp649/wpjs_wfScanners'
[ERROR] mysqld: Table './user_wp649/wpjs_wfLeechers' is marked as crashed and should be repaired
[Warning] Checking table:   './user_wp649/wpjs_wfLeechers'
[ERROR] mysqld: Table './user_wp649/wpjs_wfBlocks' is marked as crashed and should be repaired
[Warning] Checking table:   './user_wp649/wpjs_wfBlocks'
[ERROR] mysqld: Table './user_wp649/wpjs_wfReverseCache' is marked as crashed and should be repaired
[Warning] Checking table:   './user_wp649/wpjs_wfReverseCache'

También veo miles de advertencias sobre la inserción de consultas en performance_schema.

INSERT INTO 'wp_wfHits' ( 'ctime' , 'statusCode' , 'isGoogle' , 'IP' , 'userID' , 'URL' , 'referer' , 'UA' , 'jsRun' ) VALUES (...)

Creo que la razón de esto es agregar un método estricto en MySQL 5.7 / MariaDB 10.2. Los bloqueos de la tabla parecen corregirse por sí mismos (es decir, todas las tablas informan bien) después del acceso inicial a cada tabla. Pero las advertencias de la investigación continúan.

Por lo tanto, mientras que los bloqueos de la tabla de autocorrección parecen ser un incidente aislado, las alertas de consulta están en curso. Quería confirmar esto con alguien de WF y también informar el problema.

Este tema fue modificado hace 1 año, 11 meses por. Este tema fue modificado hace 1 año, 11 meses por.

(@wfdave)

Hace 1 año, 11 meses

Hola @hyssop,

¿Puede ejecutar el siguiente comando dentro de su SSH / terminal en su host?

mysqlcheck -u root -p --auto-repair --check --all-databases

(Reemplace la raíz con el nombre de usuario de la base de datos)

Si eso no funciona, o si no tiene acceso a ese programa en su host, puede seguir estos pasos:

1. Vaya a Wordfence -> Todas las opciones 2. Marque Delete Wordfence tables and data on deactivation
3. Guardar 4. Vaya a Wordfence -> Herramientas -> Opciones de importación / exportación 5. Opciones de exportación de Wordfence -> Guardar clave 6. Desactive, reinstale Wordfence 7. Regrese a Importar / Exportar -> Importar Guardar clave

Eso debería reconstruir la base de datos y su configuración.

Dave

(@hisopo)

Hace 1 año, 11 meses

Ya estoy ejecutando una revisión / reparación, pero la ejecuté de nuevo por ti, todos estaban «bien». Creo que fueron un evento único que causó la actualización de MySQL y que WF no era compatible de alguna manera.

Sigo viendo advertencias en la tabla (como se muestra arriba). Además, la tabla wfConfig arroja un error (no calentamiento) en INSERT INTO. Creo que todo esto se aplica a un método MySQL rígido. Quería agregar IGNORE como prueba para ver si funciona, como fue el caso con otro código que escribí antes, pero no pude encontrar el lugar correcto.

-Pete

(@hisopo)

Hace 1 año, 11 meses

¿Que recomiendas? ¿Ha probado su código con las últimas versiones de MySQL / MariaDB? (Si es así, ¿quién es compatible?)

Si proporciona nombres de archivo y (aproximadamente) números de línea para las instrucciones INSERT INTO para las tablas wfConfig y wfHits, probaré si IGNORE deja de agregar errores / advertencias. Busqué estos antes, pero no pude determinarlo exactamente, sin conocer su codificación.

-Pete

(@hisopo)

Hace 1 año, 11 meses

Hola @wfdave

No estoy impaciente, pero me pregunto si este hilo ha sido …

-Pete

(@wfdave)

Hace 1 año, 10 meses

Hola de nuevo,

Nunca había visto eso antes, pero tengo una última sugerencia que puedes probar:

Entra en tu my.cnf archivar y buscar la línea sql_mode=***** y reemplazar sql_mode="".

Desde allí, reinicie el proceso de MySQL (reiniciando o usando el host mysql restart.

Dave

(@hisopo)

Hace 1 año, 10 meses

Hola @wfdave

Sé cómo deshabilitar el modo estricto (pero eso es solo un recurso provisional). Se supone que esto cambia los errores a advertencias como resultado, pero parece que los arregla. Hacer lo que sugirió parece respaldar esa decisión. Pero…

Para otras aplicaciones que escribí, pude insertar IGNORE en la declaración INSERT INTO para resolver temporalmente el problema (hasta que pueda reescribirlo correctamente). Esto tiene la ventaja de no tener que deshabilitar el modo estricto globalmente, así que veré qué más necesita un ajuste (como WordFence, aparentemente). Estoy usando MariaDB 10.3.xy supongo que está al tanto de la aplicación del modo estricto recientemente. Entonces estoy pensando en las versiones de db que han probado su código hasta ahora.

Por eso pregunté qué hice arriba … lo cito aquí:

“¿Ha probado su código con las últimas versiones de MySQL / MariaDB? (Si es así, ¿quién es compatible?)

Si proporciona nombres de archivo y números de línea (aproximados) para las instrucciones INSERT INTO para las tablas wfConfig y wfHits, probaré si IGNORE deja de agregar errores / advertencias. Busqué estos antes, pero no pude determinarlos con exactitud, sin conocer su codificación. «

Gracias, y responda tan pronto como pueda para que pueda probar esto (agregando IGNORE).

-Pete

¿Solucionó tu problema??

0 / 0

Deja una respuesta 0

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *