¿Qué tablas son seguras para limpiar?

40

Heredé un sitio de cliente que tiene una base de datos extremadamente grande sin ninguna razón. Hay una cantidad moderada de contenido y muy pocos módulos habilitados. Sin embargo, la base de datos es demasiado grande para moverse fácilmente y quiero limpiarla.

He borrado las tablas de caché estándar, syslog y accesslog.

¿Hay otras tablas que pueda truncar de forma segura en un sitio estándar de Drupal?

Nigel Waters
fuente
1
Puede ordenar las tablas según su tamaño en phpmyadmin. Pruebe eso y luego mire qué tablas son las más grandes e informe eso aquí. Por ejemplo, he visto enormes tablas de sesiones que no se limpian por alguna razón. Eso es algo que podría borrar si puede vivir con los usuarios que tienen que iniciar sesión nuevamente (y posiblemente perder los datos ingresados ​​del formulario si están en el sitio, por lo que es posible que desee coordinar esto con los usuarios)
Berdir
Solo una nota al margen, que todas las respuestas a continuación que mencionan el truncamiento {cache_form}no son realmente correctas. Esta no es una verdadera tabla de caché. Contiene presentaciones de formularios en curso. Si elimina todos los datos de esta tabla, su usuario puede perder datos. Lo correcto para hacer con esta tabla es expirar las entradas.
mpdonadio

Respuestas:

21

Use el módulo de copia de seguridad y migración , viene con buenos valores predeterminados para omitir los datos no necesarios . Por defecto genera una copia de seguridad de la base de datos sin caché, watchdog y algunas otras tablas.

Si esto no ayuda, eche un vistazo a phpMyAdmin y díganos qué tablas tienen muchas entradas.

BetaRide
fuente
1
Este es el primer lugar al que fui. Sin embargo, la base de datos está en un concierto y no realizará una copia de seguridad a través de este método. Mi intención es limpiar la base de datos para poder usar la copia de seguridad y migrar regularmente. Esencialmente, me pregunto si hay más tablas que pueda eliminar (que BAM no omite de forma predeterminada).
Nigel Waters
Si tiene acceso a la línea de comandos, puede usar drush para iniciar la copia de seguridad y migrar. O acceda a mysql en la línea de comando (ejemplo: mysqldump --host = your.host.com --user = db_user --compress --password your_pw> dump.sql) De esta manera no se encontrará con tiempos de espera. En general, limpiar sin tener una copia de seguridad no es muy seguro. Puede terminar fácilmente con una página rota y no hay forma de regresar.
BetaRide
El problema no es con los tiempos de espera. Sé que puedo ejecutar fácilmente copias de seguridad a través de ssh / drush. Me gustaría limpiar la base de datos, ya que ha visto una o muchas manos en los últimos años y hay mucha basura innecesaria allí. Solo necesito saber qué tablas puedo eliminar de forma segura (no sé cómo hacer una copia de seguridad o mover mi sitio).
Nigel Waters
@BetaRide es correcto, los predeterminados que BAM excluye son los seguros. Los demás pueden o no tener datos reales.
mpdonadio
22

Drupal 7 tablas que se pueden excluir

Aquí hay una lista de tablas en Drupal 7 que puede borrar (para reducir el tamaño de la base de datos) o excluir de forma segura para realizar una migración (como en la pregunta sobre ¿Cómo reducir el tamaño de la base de datos exportada localmente para evitar el límite de importación de mi servidor? ):

  • registro de acceso
  • lote
  • todas las tablas relacionadas con caché, como:
    • cache*
    • caché_bloque
    • contenido_caché
    • cache_filter *
    • cache_form
    • cache_calendar_ical
    • cache_menu *
    • cache_page *
    • vistas_caché
    • * _cache, como features_cache o views_data_object_export_cache
  • ctools_views_cache
  • ctools_object_cache
  • devel_queries
  • devel_times
  • inundar
  • historia
  • cola
  • varias tablas search_ *, como:
    • search_dataset
    • search_index
    • search_keywords_log
    • búsqueda_total
  • semáforo
  • sesiones
  • perro guardián
  • webform_submitted_data

Por lo general, las tablas como search_indexy watchdogusan una gran cantidad de espacio en la base de datos, por lo que simplemente eliminar esas 2 tablas puede marcar una gran diferencia.

Otras tablas que pueden excluirse

Verifique el tamaño de las tablas restantes e identifique cuál de ellas es la más grande.

Por lo general, puede encontrar tablas de sesiones para las que no hay un procedimiento de limpieza. Estas tablas probablemente también pueda excluirlas.

Módulo de copia de seguridad y migrar

Para reducir aún más el desafío como se detalla en " ¿Cómo reducir el tamaño de la base de datos exportada localmente para evitar el límite de importación de mi servidor? ", Mire también el módulo Copia de seguridad y migración . Aquí hay una cita de su página de proyecto (marcado en negrita agregado aquí):

Haga una copia de seguridad y restaure su base de datos, código y archivos de Drupal MySQL o migre un sitio entre entornos. Backup and Migrate admite la compresión gzip, bzip y zip, así como copias de seguridad programadas automáticas.

Con Backup and Migrate, puede volcar algunas o todas las tablas de su base de datos en una descarga de archivos o guardarlas en un archivo en el servidor o fuera del sitio, y restaurar desde un volcado de base de datos cargado o guardado previamente. Puede elegir qué tablas y qué datos respaldar y los datos de caché están excluidos de forma predeterminada .

Y aún hay más: si su entorno local (por ejemplo, Win o Mac) difiere del sistema operativo que está ejecutando el servidor de su sitio web alojado (como Linux), entonces estas diferencias entre los sistemas operativos implican desafíos adicionales potenciales. He tenido buenas experiencias con el módulo Copia de seguridad y migración entre diferentes sistemas operativos, lo que no causó ningún problema (funcionó bien) en situaciones en las que la exportación / importación típica de MySql fallaba antes.

Pierre.Vriens
fuente
Es bueno agregar que cualquier tabla con cache_antepuestos o _cacheanexos también es segura de truncar, como features_cacheo views_data_object_export_cacheetc.
Beebee
1
Palabra de advertencia, los datos de la tabla de búsqueda pueden excluirse, pero puede llevar mucho, mucho tiempo reconstruir los índices en sitios grandes. Juzgue esto caso por caso.
mpdonadio
2
Además, el extracto de B&M sobre los datos en caché es ligeramente incorrecto. Cuando se habilita en un sitio, excluirá las tablas de caché. Sin embargo, si agrega un módulo después de configurar B&M, es posible que las tablas de caché no se agreguen a la lista de datos de exclusión. He visto que esto sucede muchas, muchas veces, generalmente cuando anulo la configuración en el perfil predeterminado.
mpdonadio
@MPD: gracias por este comentario interesante (¡todavía no sabía nada de eso!). Sobre la tabla de búsqueda: punto válido. Pero personalmente siempre preferiría el enfoque de reconstrucción: ayuda a sortear la limitación y garantiza que el índice coincida con el contenido real en el objetivo. Sobre su segundo comentario: el extracto es un corte y pasado de la página del proyecto, por lo que tal vez desee presentar un problema al respecto en su cola de problemas (Drupal.SE no es el lugar para informar sobre errores, etc., ¿verdad?) .
Pierre.Vriens
@ Pierre.Vriens Coincidir con el contenido no debería importar, suponiendo que tenga cron ejecutándose y asegúrese de que se realiza la indexación. B & M, bastante seguro de que es un problema conocido. Además, la sección sobre datos de sesión no es 100% correcta. Esa tabla se agranda porque el tiempo de sesión predeterminado es de aproximadamente tres semanas; _drupal_session_garbage_collectionmantendrá esa tabla ordenada, según la configuración del sistema.
mpdonadio
19

En mi experiencia, purgo todas las tablas "cache_ *".

  • más "perro guardián" si no me importan los registros anteriores de Drupal
  • más "registro de acceso" si no me importan los usuarios registrados
  • más "buscar" si no me importa el contenido de los nodos indexados
thePanz
fuente
1
Lo mismo aquí, también haría sesiones.
Alex Weber
2
Una nota para cualquiera que intente esto: primero cree una copia de seguridad. Y no suelte las tablas, más bien Vacío o Truncado.
timofey.com
9

A veces ejecuto este SQL para vigilar el crecimiento de las tablas superiores:

SELECT * 
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA =  'yourdbnamehere'
ORDER BY table_rows DESC 
uwe
fuente
¿En qué columna debo verificar el crecimiento ?, quieres decir TABLE_ROWS
Bala
8

Watchdog y las sesiones también se pueden borrar, tenga en cuenta que todos los usuarios cerrarán sesión.

Attiks
fuente
6

Con mySQL puede hacer cosas divertidas con el programa mysqldump para exportar la base de datos en su totalidad o en partes. Por ejemplo, esto solo exporta la estructura:

mysqldump -u root -pBatteryHorseStapleObviously -h some_host --no-data dbname > ~/dbname.sql

Luego puede usar la opción 'ignorar tabla' para exportar más datos, por ejemplo

mysqldump -u root -pBatteryHorseStapleObviously -h some_host --ignore-table=dbname.huge_table --ignore-table=dbname.massive_table --ignore-table=dbname.useless_table some_host >> ~/dbname.sql

Eso coloca los datos al final del archivo anterior ignorando algunas tablas masivas.

Si luego necesita las tablas masivas, puede exportarlas a un archivo diferente utilizando el enfoque anterior, luego puede importarlas en fragmentos (aunque podría ser necesario marcar fk).

¿Descomprimiste tu archivo antes de subirlo, o es una pregunta tonta?

Gato de henry
fuente
5

Use el módulo OptimizeDB para limpiar las tablas de caché. La administración de la base de datos también es útil.

No olvide tener una copia de seguridad de las bases de datos.

M ama D
fuente
la base de datos ahora es 14Mo, utilicé OptimizeDB, gracias de nuevo
Mitch
@Mitch de nada
M ama D
2

No los super experto en esto pero compartir mi experiencia ... si usted no está utilizando la copia de seguridad y el módulo de migración y de forma manual exportarlos algunas de las mesas se podía vaciar / truncado sería watchdog, cache, cache_menu, cache_block, cache_content, cache_formya que pueden contener una gran cantidad de borrado de cosas en caché que supongo que no haría daño ... pero de nuevo esta es mi experiencia y no he encontrado problemas o pérdida de datos debido a esto.

optimusprime619
fuente
2

Algunas ideas:

  • Un enfoque completamente diferente sería crear fuentes RSS utilizando vistas de los datos que desea conservar. Luego cree una nueva instalación de Drupal e importe estos datos con Feed API .
  • Y solo otro enfoque: contratar a un estudiante y dejar que transfiera los datos manualmente a su nueva instalación.
  • O este: Cuéntanos más sobre qué tablas son muy grandes y cuál es la razón de esto (si lo sabes).
BetaRide
fuente
2

Verifique la example.drushrc.phplista de estos:

$options['structure-tables']['common'] = array('cache', 'cache_*', 'history', 'search_*', 'sessions', 'watchdog');
$options['skip-tables']['common'] = array('migration_*');

Es seguro borrarlos en términos de mover la base de datos entre diferentes entornos (especialmente cuando trabaja con grandes bases de datos ). Sin embargo, aún necesita comprender lo que está limpiando.

kenorb
fuente
1

Tablas adicionales que se pueden borrar:

  • lote
  • webform_submitted_data

Otras cosas que pueden ocupar bastante espacio: - versiones anteriores de su contenido (no es posible limpiarlas con un simple truncamiento). - locales_source y locales_target. Si tiene idiomas que ya no se usan o traducciones de cadenas para módulos que ya no usa. Parece que estas mesas nunca se limpian.

fietserwin
fuente