MySQL es un sistema gestor de base de datos con mejores o peores consideraciones. Como punto positivo, está la posibilidad de usar más de un motor de base de datos. Básicamente dos son los más conocidos: MyISAM e InnoDB.
¿Cómo saber desde la consola de MySQL esta información? Con la siguiente orden, fijaos que el DESCRIBE TABLE no ofrece esta información, sólo la información referente al tipo de dato de cada columna, así que tenemos que usar:
SHOW TABLE STATUS WHERE Name = 'nombre_tabla'
Si sois de los que aprovecháis las nuevas funcionalidades de MySQL como yo y dentro de vuestra base de datos usáis: stored procedures, functios o los famosos triggers (disparadores), os habréis dado cuenta que en vuestro dump, es decir en vuestras copias de seguridad, éstos no aparecen si los hacéis de la forma típica.
Yo me di cuenta de la mala forma, es decir, cuando recuperas el dump y te das cuenta de que no están en ningún sitio. Por eso mismo os traigo esta entrada, para que no os pase y tengáis en cuenta que si usáis este tipo de cosas, quizás debáis reformar la forma en la que llamáis a mysqldump.
Por defecto y por fortuna los triggers sí son guardados por defecto por mysqldump. Para añadir procedimientos y funciones, las llamadas rutinas, deberemos añadir el parámetro –routines, veamos:
En las instalaciones por defecto de MySQL, en muchas ocasiones, o aparece deshabilitada la caché de consultas o aparece, pero con muy poco espacio disponible.
Como podréis figuraros, la caché de consultas almacena en memoria física, la RAM, las últimas consultas realizadas y su resultado, de forma que si alguien repite dichas consultas, el acceso a su resultado sea casi inmediato comparado con recurrir a la base de datos en sí, a la que probablemente debamos acceder a disco y recorrer sus complejos árboles B y B+ internos.
El resultado de usar caché de MySQL es muy evidente en cuando a velocidad y en una entrada posterior os comentaré cómo sacar estadísticas para ver con más concreción cuál es la mejora.
¿Cómo activarla? ¿Cómo aumentar su tamaño?
Para ver si está activada nos dirigimos al fichero my.cnf (que probablemente esté en /etc o /etc/mysql) y buscamos dentro las siguientes cadenas:
Probablemente, en alguna ocasión te hayas enfrentado vía log o vía mensaje de urgencia con un mensaje de este tipo: “table marked as crashed and should be repaired” cuando trabajas con MySQL. Más aún si has tenido un reinicio de emergencia, si usas MyISAM o si tienes problema con tu sistema de ficheros (o tus discos).
Puedes tratar de reparar tabla a tabla, sin embargo, lo más productivo es hacer todas de una vez. Antes de cualquier operación de este tipo, haz una copia de todo por si acaso (aquí en Linux Hispano hablé de cómo hacer backups y recuperarlos).
La orden a ejecutar será la siguiente y el resultado lo veréis en la consola, si OK o si hay problemas:
mysqlcheck -u root -p --auto-repair --optimize --all-databases
Hola, quería aportar contenido sobre una interesante herramienta para implementar replicación de base de datos (para postgres y mysql). Me tope con ésta herramienta hace unos días, cuando estaba buscado información/soporte para utilizar Slony-I (herramienta de replicación para PostgreSQL). Resulta ser una solución muy buena, fácil de implementar y relativamente simple. (en comparación con Slony-I). Está escrita en JRuby, lo cual la hace independiente de la plataforma (donde corra Java, lo hará ésta herramienta).
Características principales:
Cuando trabajamos con MySQL es muy frecuente que tengamos que acceder al servidor para realizar desde equipos cliente operaciones con el mismo. Una solución muy frecuente en el mundo de la web, es ahorrarnos abrir conexiones y trabajar directamente desde dicho equipo, ¿cómo? Usando un software que se instale en el equipo servidor de base de datos y permita a la vez interactuar contra él mediante un interfaz web. Hablo de phpMyAdmin.
Sin embargo, en ocasiones, preferimos directamente conectarnos al servidor. Yo personalmente lo hago porque prefiero usar SQLyog Community sobre Wine antes que phpMyAdmin. ¿Cómo lo hacemos? Veamos:
Bind address
Lo primero es buscar en el fichero de configuración de MySQL y modificar la línea siguiente:
bind-address = 127.0.0.1
Por esta otra:
bind-address = TU_IP
Si indicamos 0.0.0.0 estamos dejando conectarnos desde cualquier dirección.
Dar permisos a nuestro usuario
La segunda parte viene derivada de dar permisos a nuestro usuario. ¿Cómo? Desde la consola de MySQL:
GRANT ALL PRIVILEGES ON base_datos.* TO ‘usuario’@'tu_IP' IDENTIFIED BY 'tu_password';
La versión 12.04 LTS de Ubuntu tiene un amplio soporte y resulta muy interesante para usuarios particulares y, sobre todo, empresas instalar un servidor LAMP en dicha distribución. Tener 5 años de soporte extendido da una seguridad y estabilidad más que considerable con respecto a otras versiones de Ubuntu. En esta versión instalarlo es aún más fácil que en otras versiones como la 11.04 ó 11.10.
La seguridad es un punto básico en un blog, portal, red social, foro… o cualquier otra aplicación realizada con WordPress. Os comento 10 pasos básicos, que deberéis realizar para estar seguros de tener una instalación WordPress sin problemas de seguridad (al menos con la menor cantidad de problemas posibles).
Esta entrada es una traducción, adaptación y mejora del original en inglés: 10 Basics Steps To WordPress Security de Designrfix.
Manten el núcleo de WordPress actualizado
El equipo entero de desarrolladores y colaboradores de WordPress hace un gran trabajo para tratar de tener los problemas de seguridad a raya, si no mantenemos actualizado el núcleo, este trabajo servirá para nada. En otros CMS (aún recuerdo las actualizaciones que hacía en Drupal) son más complejos, pero en WordPress con un sólo clic hasta actualizado. No hay excusa.
Manten también los plugins y los temas actualizados
Ídem que el anterior, pero esta vez me refiero a los plugins y a los temas. Si estáis usando un tema propio, en el que partís de otro anterior, recordad usar temas hijos.
Cuando estamos trabajando con datos, la mayor parte de las veces tendremos versiones que por unas razones u otras no queramos usar para pruebas. Debemos ser precavidos y tratar de evitar a toda costa de asumir riesgos en temas como éste en los que es muy fácil cubrirse las espaldas.
Una de las mejores formas de hacerlo es duplicando la estructura y los datos de una base de datos, de forma que en lugar de trabajar con la base de datos original, trabajemos con la copia hasta que estemos seguro de que todo marcha perfectamente.
¿Cómo copiar una base de datos en un sistema gestor de bases de datos MySQL? Aquí está el proceso:
