Publicado el

Cambiar motor tablas mysql

MySQL EngineEn más de una ocasión, me he encontrado con la necesidad de verificar el motor (innodb o myisam) de las tablas de una determinada base de datos en mysql. Se puede ver el motor usado, seleccionando la base de datos y ejecutando el comando «show table status»:

use mydatabase;
show table status;

También me he encontrado con la necesidad de cambiar varias (o todas) las tablas de un motor a otro. Existe la posibilidad de ejecutar la siguiente sentencia para cambiar el motor de una tabla:

ALTER TABLE mytable ENGINE=InnoDB

Continuar leyendo «Cambiar motor tablas mysql»

Publicado el

MongoDB – Reconfigurar replica set

MongoDBSi se quiere cambiar alguno de los parámetros de cualquier nodo del réplica set, bastará con conectar con el nodo primario de ese conjunto, y seguir los pasos descritos a continuación.

En primer lugar, se deberá copiar la configuración actual del replica set a una variable auxiliar:

PRIMARY> cfg = rs.conf()
{
«_id» : «replica1»,
«version» : 6,
«members» : [
{
«_id» : 0,
«host» : «192.0.1.2:27001»
},
{
«_id» : 1,
«host» : «192.0.1.3:27001»
},
{
«_id» : 4,
«host» : «192.0.1.4:38001»,
«arbiterOnly» : true
}
]
}

Continuar leyendo «MongoDB – Reconfigurar replica set»

Publicado el

Usuarios y permisos MySQL

MysqlYa he escrito algunos posts donde se ha hablado un poco de la administración de usuarios y permisos en MySQL como éste o éste otro. Sin embargo, voy a resumir en un breve post la administración de usuarios y permisos de MySQL.
Podemos ver los usuarios que tenemos en el mysql con el siguiente comando:

mysql> select * from mysql.user;

Esto nos mostrará todos los usuarios definidos en mysql, separando además los usuarios por host (si tenemos un usuario user@localhost y el mismo usuario para acceder desde cualquier host user@’%’, aparecerán dos líneas para este usuario.

Para conocer los permisos que tiene un determinado usuario, se podrá usar:

mysql> show grants for user@’host’

Por ejemplo: mysql> show grants for user@’%’

Continuar leyendo «Usuarios y permisos MySQL»

Publicado el

Mysqlhotcopy

Para realizar backups de bases de datos MySQL, se suele usar el comando mysqldump. Este comando, se encarga de generar las consultas necesarias para recrear toda la estructura de tablas y su contenido, a base de sentencias SQL. Sin embargo, este comando, puede resultar muy lento, para bases de datos grandes.

Si se quiere hacer un backup de una base de datos con tablas MyISAM, desde la propia documentación oficial de MySQL se insta a usar mysqlhotcopy en lugar de mysqldump:

«If you are doing a backup on the server and your tables all are MyISAM tables, consider using the mysqlhotcopy instead because it can accomplish faster backups and faster restores»
Fuente: aquí

Continuar leyendo «Mysqlhotcopy»

Publicado el

Actualizar MongoDB 1.8 a 2.0

MongoDBEsta semana hemos realizado una actualización de nuestro clúster MongoDB de la versión 1.8 a la 2.0.

En nuestro caso, tenemos varias máquinas que forman parte del clúster, donde cada máquina contiene un seguido de mongods corriendo, cada uno de ellos correspondiente a un shard, que a su vez contiene un nodo de un determinado replica-set. Un poco complicado de entender, si no se ha tocado mucho MongoDB. En cualquier caso, con este escenario hemos relizado la actualización.

La idea ha sido aprovechar la funcionalidad de clúster, para poder actualizar las máquinas secundarias mientras las primarias continuaban dando servicio, con tal de minimizar el downtime que requiere un proceso de estas características.

Continuar leyendo «Actualizar MongoDB 1.8 a 2.0»

Publicado el

Mysql resetear password de root

Espero no tener que encontrarme nunca en esta situación, pero por si las moscas, me apunto el proceso para resetear el password de root para un mysql sobre linux, cuando no se dispone de la contraseña de root. Los pasos, los he sacado de aquí y de aquí.

  1. Detener el servicio mysql: killall mysqld
  2. Ejecutar mysql en modo seguro, sin cargar las tablas de usuarios: mysqld_safe –skip-grant-tables
  3. Conectar con el mysql que acabamos de arrancar: mysql –user=root mysql
  4. Ejecutar el cambio de contraseña (en este paso, he usado un password fácil como paso intermedio): update user set Password=PASSWORD(‘new-password’) where user=’root’;
  5. Recargar las credenciales y salir: flush privileges; exit;
  6. Detener el servicio mysql: /etc/init.d/mysqld stop
  7. Iniciarlo: /etc/init.d/mysqld start
  8. Comprobar que podemos acceder con el password indicado en el punto 4: mysql -u root -p
  9. Salir del mysql: exit;
  10. Ejecutar mysqladmin para cambiar el password definitivamente: mysqladmin -u root password ‘NEWPASSWORD’ -p
  11. Comprobar de nuevo que el acceo con el nuevo password es correcto: mysql -u root -p
  12. Apuntar el password en un lugar seguro 😀

 

Publicado el

MySQL usuario de lectura

Resulta que crear un usuario de mysql con acceso desde hosts remotos no es tan intuitivo como podría pensarse. Durante la creación de un usuario en mysql, ya sea con el comando apropiado o mediante utilidades como «mysql_setpermission», se debe indicar si el usuario mysql podrá conectar con el motor SQL únicamente desde el localhost, o si por el contrario, tendrá acceso desde un host remoto específico o desde cualquier host (%).

Sin embargo, para que el acceso remoto funcione, deberá crearse primero el usuario localhost y posteriormente el mismo usuario para %:

mysql> create user ‘readonly’@’localhost’ identified by ‘mipassword’;
Query OK, 0 rows affected (0.00 sec)

mysql> grant select on *.* to ‘readonly’@’localhost’;
Query OK, 0 rows affected (0.00 sec)

mysql> create user ‘readonly’@’%’ identified by ‘mipassword’;
Query OK, 0 rows affected (0.00 sec)

mysql> grant select on *.* to ‘readonly’@’%’;
Query OK, 0 rows affected (0.00 sec)

 

Esto se puede leer en la documentación oficial de MySQL:

«It is necessary to have both accounts for monty to be able to connect from anywhere as monty.»

Con estas instrucciones se habrá creado un usuario llamado «readonly» con únicamente permisos de lectura (selects) contra todas las bases de datos existentes, tanto desde el host local como desde cualquier otro host remoto.

Publicado el

Límite de conexiones en MySQL

MySQL tiene un límite de conexiones simultáneas que acepta, que por defecto en las versiones actuales está en 150. En realidad, 151, puesto que esta 1 está reservada para el administrador poder conectar en local y ver qué está pasando.

Podemos consultar el límite actual, tal y como se muestra en el siguiente ejemplo:

mysql> show variables like «max_connections»;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 151 |
+—————–+——-+
1 row in set (0.00 sec)

Si quisiéramos incrementar el límite por ejemplo a 300 conexiones simultáneas, únicamente deberíamos añadir la siguiente línea al archivo de configuración de MySQL, típicamente en /etc/my.cnf:

max_connections = 300

Una vez hecho esto, y después del posterior reinicio del servicio, deberíamos poder confirmar el incremento del límite:

mysql> show variables like «max_connections»;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 300 |
+—————–+——-+
1 row in set (0.00 sec)

Actualización: También podemos cambiar este parámetro «al vuelo» con el comando siguiente:

mysql> SET GLOBAL max_connections = 300;

Decir, que tenemos un par de opciones para ver el número de conexiones actuales:

mysql> SHOW STATUS WHERE `variable_name` = ‘Threads_connected’

O directamente,

mysql> SHOW PROCESSLIST;

Fuentes:
http://www.electrictoolbox.com/update-max-connections-mysql/
http://forums.mysql.com/read.php?24,15350,28036

Publicado el

BBDD – Mantenimiento

Bueno, hace ya bastante desde la última vez que escribí. Y como vengo con las manos vacías, he decidido recuperar una pequeña guía que escribí (para mi mismo) sobre el mantenimiento de una base de datos en SQL Server 2005.

En realidad, se trata de un resumen de un vídeo que adjunto en la fuente del final del post. Ahí va ese copy&paste:

Planes de mantenimiento

SQL Server 2005 incorpora la opción de “planes de mantenimiento”, que permiten mediante un asistente realizar tareas de mantenimiento de forma automatizada. Sin embargo, no siempre nos interesará realizar estas tareas de forma automatizada, y probablemente habrá ocasiones en que será necesario o preferible realizarlas de forma manual.

Esta guía pretende dar algunas pinceladas sobre conceptos de mantenimiento de bases de datos en SQL Server.

Hardware
Lo primero que hay que tener en cuenta, es que el mantenimiento de una base de datos también dependerá del hardware de la máquina sobre la que se aloje el SQL Server, en parte debido al elevado consumo de memoria requerido para realizar este tipo de tareas, pero sobretodo, especialmente al realizar tareas de:

  • Backups
  • Reorganización/recreación de índices

Hay que tener en cuenta si tenemos suficiente hardware como para poder realizar este tipo de tareas, y en cualquier caso, planificarlas para cuando el servidor esté en sus mínimos niveles de utilización.

Verificando las bases de datos con DBCC
SQL Server viene con varias sentencias DBCC de verificación de bases de datos, de entre las cuales destaca:

  • DBCC CHECKDB: esta sentencia muestra cuántas filas y páginas tiene cada tabla de una determinada base de datos, indicando errores de asignación y consistencia, sin bloquear. Realmente, esta sentencia ejecuta lo que en SQL Server 2000 sería:
    • CHECK ALLOC
    • CHECK CATALOG
    • CHECK TABLE

Con DBCC CHECKDB se pueden verificar cualquiera de las bases de datos de sistema (Máster + recursos, Model, MSDB y Tempdb, aunque esta última con bloqueo a nivel de tablas), así como las de usuario.

Fragmentación
Uno de los principales problemas de rendimiento viene dado por la fragmentación de los datos de la base de datos. Para evitarla, en medida de lo posible, será conveniente:

  • Crear de inicio del archivo de la base de datos lo suficientemente grande como para satisfacer las necesidades de espacio futuras.
    • No permitir el “autogrow” del fichero.
  • En muy pocas ocasiones se debería hacer uso de la opción “Shrink”, ya que se trata de una operación muy costosa que provoca una gran fragmentación tanto de datos como de índices. Se recomienda usar, en estos casos:
    • DBCC SHRINKDATABASE, cuya única limitación es que nunca podremos reducir la base de datos más allá de su tamaño de creación.

NOTA: a esta función se le puede pasar un parámetro numérico que indica el porcentaje de espacio disponible que se desea dejar en el archivo de la base de datos después de reducir la base de datos.

Finalmente, no hay que olvidar los problemas relacionados con:

  • Fragmentación lógica, referente al orden de las páginas de una tabla.
  • Fill Factor, o factor de llenado de las páginas (parámetro modificable).

Trabajo con índices
En cuanto a los índices, existen dos tipos de operaciones posibles:

  • ALTER INDEX REBUILD: operación online que actualiza estadísticas, pero que provoca una gran transacción (deberemos asegurar suficiente espacio en el log de transacciones, ya que además no lo podremos limpiar hasta que la operación no finalice) y que puede llegar a consumir una gran cantidad de recursos.
    • Recomendable únicamente cuando el porcentaje de fragmentación de los índices supera el 30%.
  • ALTER INDEX REORGANIZE: operación que en este caso no actualiza estadísticas (aunque normalmente no necesitaremos actualizarlas en ningún caso, ya que siempre viene habilitada la opción AUTO-UPDATE STATISTICS con las instalaciones de SQL Server).
    • Uso para índices poco fragmentados (porcentaje menor al 30%).

Únicamente deberemos realizar este tipo de trabajo cuando sea realmente necesario, con lo cual será conveniente comprobar el nivel de fragmentación de los índices antes de ejecutar cualquiera de las dos operaciones anteriores.

Backups
Será recomendable tener una buena política de backups, aunque de igual forma, será aún más recomendable realizar comprobaciones de la validez de los mismos:

  • RESTORE VERIFYONLY nos permitirá realizar una verificación de un archivo de backup, asegurando su funcionamiento ante un posible restore.

Hay que tener en cuenta que es una buena práctica ir eliminando los archivos de backup obsoletos, tanto del disco como del registro generado en el MSDB.

Otras consideraciones
Finalmente, únicamente indicar que el orden en el que se ejecutan las acciones de mantenimiento puede influir y mucho en el resultado de nuestro plan. De esta manera por ejemplo, no tendrá sentido realizar una reindexación de índices y a continuación un shrink, debido a que ésta última operación volverá a fragmentar los índices de la tabla.

Igualmente, se deberá tener en cuenta la existencia de operaciones incompatibles para realizarse de forma paralela, como por ejemplo una reindexación de índices y un CHECKDB.

Fuente
Mantenimiento de bases de datos en SQL Server 2005
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=es-CO&EventID=1032346791&CountryCode=CO

Publicado el

Crystal Reports e impresión en A4

sawing

Desde hace tiempo, trabajamos con Crystal Reports para generar informes con datos de bases de datos SQL Server. Por defecto, este tipo de aplicaciones, como Crystal Reports, al parecer ajustan la vista tanto de diseño como de previsualización, al área definida en la impresora predeterminada configurada en el PC desde el que se trabaja. Es decir, si estamos trabajando con un ordenador que tiene configurada una impresora predeterminada, configurada a su vez para imprimir por defecto en A3, esto afectará directamente a Crystal Reports, que por defecto nos mostrará un área de diseño y previsualización, también de tamaño A3.

Alguna vez nos hemos encontrado, que la vista de diseño del informe ha resultado ocupar un área de impresión mayor que la definida en la impresora predeterminada, y hemos necesitado cambiar la impresora predeterminada por algún programa como PDF Creator, con el área de impresión definida para nuestras necesidades.

El problema, es que cuando desde Crystal Reports se exporta a PDF el resultado del informe, se imprime con el tamaño definido en la impresora, que a su vez, hemos adaptado para que tenga un tamaño “no estándar”. Esto se puede solucionar, usando un programa gratuito, como PDF-XChange Viewer, que permite imprimir sobre PDF seleccionando la opción de escalado “Organizar las páginas largas”, la cual parte el fichero PDF original adaptándolo al tamaño de impresión, permitiendo imprimir, por ejemplo el fichero en varias páginas A4.

Seguramente habrá formas más sencillas de hacer este proceso. Si es así, no te cortes y propónlas 😉

Flickr! Foto por Bitterjug