2.10. Aumentar la versión de MySQL

MySQL 5.0

2.10. Aumentar la versión de MySQL

Como regla general, se recomienda que al actualizar de una serie a otra se pase a la serie inmediatamente superior sin saltar ninguna. Por ejemplo, si actualmente se está ejecutando MySQL 3.23 y se desea actualizar a una serie más moderna, debe pasarse a MySQL 4.0 y no 4.1 o 5.0.

Los siguientes puntos conforman una lista de lo que se debería hacer al llevar a cabo una actualización:

Antes de actualizar de MySQL 4.1 a 5.0, debe leerse Sección 2.10.1, “Aumentar la versión de 4.1 a 5.0” y Apéndice C, Historial de cambios de MySQL. Estos proveen información acerca de características que son nuevas o diferentes respecto a las halladas en MySQL 4.1. Si se deseara actualizar desde una serie anterior a MySQL 4.1, se debería actualizar a la serie inmediatamente superior cada vez hasta llegar a MySQL 4.1, entonces se procedería con la actualización a MySQL 5.0. Para más información sobre actualizaciones desde series anteriores a MySQL 4.1, consulte Manual de referencia de MySQL 4.1.
Antes de llevar a cabo una actualización, hay que hacer copia de respaldo de las bases de datos.
Si se está ejecutando MySQL Server en Windows, consulte Sección 2.3.15, “Aumentar la versión de MySQL en Windows”.
Una actualización a MySQL 5.0 desde la versión 4.1 implica cambios en las tablas de permisos almacenadas en la base de datos mysql; donde se agregaron columnas y tablas para soportar las nuevas características. Para sacar partido de estas características, hay que cerciorarse de que las tablas de permisos están actualizadas. El procedimiento para actualizar las tablas de permisos se describe en Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”. Antes de empezar, las tablas se pueden respaldar con mysqldump; y luego pueden volver a cargarse los datos utilizando mysql o mysqlimport para volver a crear y llenar las tablas.
Si se está empleando replicación, consulte Sección 6.6, “Aumentar la versión de la replicación” para información sobre la actualización de la configuración de replicación.
Si está instalada una distribución MySQL-Max, la cual incluye un servidor llamado mysqld-max, y luego se actualiza a una versión no Max de MySQL, mysqld_safe continuará intentando ejecutar el antiguo servidor mysqld-max. En ese caso se debe remover manualmente el antiguo servidor mysqld-max a fin de asegurarse que mysqld_safe ejecute el nuevo servidor mysqld.

Los ficheros de formato y datos pueden moverse entre diferentes versiones pertenecientes a la misma arquitectura en la medida que correspondan a la misma serie de MySQL. La serie actualmente en producción es la 5.0. Si se cambia el conjunto de caracteres al ejecutar MySQL, se debe emplear myisamchk -r -q --set-character-set= charset en todas las tablas MyISAM. De otro modo, los índices podrían estar incorrectamente ordenados, porque al cambiar el conjunto de caracteres también cambia la forma de ordenarlos.

Si se desea tomar precauciones al utilizar una nueva versión, siempre se puede renombrar el antiguo mysqld antes de instalar uno nuevo. Por ejemplo, si se está empleado MySQL 4.1.13 y se desea actualizar a la 5.0.10, se debe renombrar el servidor actual de mysqld a mysqld-4.1.13. Si el nuevo mysqld hace algo inesperado, simplemente se lo detiene y se reinicia con el viejo mysqld.

Si luego de una actualización se experimentan problemas con programas cliente recompilados, tal como Commands out of sync o volcados de núcleo inesperados, probablemente al compilarlos se hayan empleado ficheros de cabecera o bibliotecas antiguos. En tal caso se debería chequear la fecha de los ficheros mysql.h y libmysqlclient.a para verificar que pertenecen a la nueva distribución de MySQL. Si no es así, habrá que recompilar los programas con los nuevos ficheros de cabecera y bibliotecas.

Si ocurriesen problemas como que el nuevo servidor mysqld no se iniciara o que no fuera posible conectarse sin usar una contraseña, hay que cerciorarse de que no exista un fichero my.cnf perteneciente a la instalación anterior. Se puede verificar con la opción --print-defaults (por ejemplo, mysqld --print-defaults). Si éste imprimiera algo más que el nombre del programa, significa que se tiene un fichero my.cnf aún activo, que está afectando la operación del cliente o del servidor.

Es una buena idea recompilar y reinstalar el módulo Perl DBD::mysql cada vez que se instale un nuevo release de MySQL. Lo mismo se aplica a otras interfaces con MySQL, como la extensión mysql de PHP y el módulo MySQLdb de Python.

2.10.1. Aumentar la versión de 4.1 a 5.0

Nota: es una buena práctica hacer copia de respaldo de los datos antes de instalar una nueva versión del software. Si bien MySQL ha puesto lo mejor de sí para asegurar un alto nivel de calidad, se deberían proteger los datos mediante una copia de respaldo.

En general, al actualizar de MySQL 4.1 a 5.0, se debería hacer lo siguiente:

Verificar la lista de cambios que se encuentra más adelante en esta sección, para ver si cualquiera de ellos podría afectar las aplicaciones en uso. En especial, aquellos marcados como Cambio incompatible; estos resultan en incompatibilidades con versiones anteriores de MySQL, y podrían requerir atención antes de actualizar.
Se debe leer el historial de cambios de MySQL 5.0 para ver qué características significativas nuevas se pueden utilizar. Consulte Sección C.1, “Cambios en la entrega 5.0.x (Desarrollo)”.
Si se está ejecutando el Servidor MySQL para Windows, consulte Sección 2.3.15, “Aumentar la versión de MySQL en Windows”. Hay que tener en cuenta también que dos de los servidores MySQL para Windows cambiaron su nombre. Consulte Sección 2.3.9, “Seleccionar un tipo de servidor MySQL”.
MySQL 5.0 incorporó soporte para procedimientos almacenados. Esto requiere que la tabla proc se encuentre en la base de datos mysql. Para crear este fichero, se debe ejecutar el script mysql_fix_privilege_tables tal como se describe en Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.
MySQL 5.0 también incorporó soporte para vistas. Esto requiere columnas adicionales de privilegios en las tablas user y db en la base de datos mysql. Para crear estas columnas, se debe ejecutar el script mysql_fix_privilege_tables como se describe en Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.
Si se está usando replicación, consulte Sección 6.6, “Aumentar la versión de la replicación” para información sobre cómo actualizar la configuración de replicación.

Entre MySQL 4.1 y 5.0 se introdujeron varios cambios notorios de comportamiento, para hacer a MySQL más compatible con el estándar SQL. Estos cambios pueden afectar a las aplicaciones en uso.

La siguiente lista describe los cambios que pueden afectar a las aplicaciones, a los que se debería prestar atención cuando se actualice a la versión 5.0.

Server Changes:

Cambio incompatible: Cambió el orden de indexación para los espacios sobrantes en columnas TEXT en tablas InnoDB y MyISAM. A partir de MySQL 5.0.3, los índices son comparados incluyendo los espacios hasta el final (exactamente como MySQL ordena los campos CHAR, VARCHAR y TEXT). Si se tiene un índice sobre una columna TEXT, se debería ejecutar CHECK TABLE sobre ella. Si la verificación informa de errores, habrá que reconstruir los índices: volcar (dump) y volver a generar la tabla si es InnoDB, o bien ejecutar OPTIMIZE TABLE o REPAIR TABLE si es una tabla MyISAM.
Cambio incompatible: Las tablas MyISAM e InnoDB que tengan columnas DECIMAL y se crearon con MySQL 5.0.3 a 5.0.5 aparecerán corruptas tras una actualización a MySQL 5.0.6. Debe hacerse un volcado de dichas tablas con mysqldump antes de actualizar, y volver a generarlas luego de la actualización. (La misma incompatibilidad ocurriría con estas tablas si fueran creadas en MySQL 5.0.6 y se hiciera un regreso a las versiones de MySQL entre 5.0.3 y 5.0.5).
Cambio incompatible: a partir de MySQL 5.0.3, el servidor ya no carga por defecto las funciones definidas por el usuario, a menos que tengan por lo menos un símbolo auxiliar (por ejemplo, un símbolo xxx_init o xxx_deinit) además del símbolo principal de la función. Este comportamiento puede omitirse con la opción --allow-suspicious-udfs. Consulte Sección 27.2.3.6, “Precauciones de seguridad en funciones definidas por usuarios”.
Incompatible change: El registro (log) de actualización fue eliminado en MySQL 5.0. Si anteriormente se lo tenía habilitado, se debería habilitar el registro binario (binary log) en su lugar.
Cambio incompatible: Fue quitado el soporte para el motor de almacenamiento ISAM. Si se tenían tablas ISAM, se deberán convertir antes de actualizar. Por ejemplo, para convertir una tabla ISAM a fin de utilizar el motor de almacenamiento MyISAM, se emplea esta sentencia:
```
ALTER TABLE tbl_name ENGINE = MyISAM;
```
Debe emplearse una sentencia similar para cada tabla ISAM existente en las bases de datos.
Cambio incompatible: Se ha quitado de MySQL 5.0 el soporte para opciones RAID en tablas MyISAM. Si se tienen tablas que utilicen estas opciones, se deberían convertir antes de actualizar. Una forma de hacerlo es realizar un volcado de la tabla con mysqldump, editar el fichero creado para eliminar todas las opciones RAID en las sentencias CREATE TABLE, y luego volver a generar las tablas a partir del fichero. Otra posibilidad es utilizar CREATE TABLEnew_tbl ... SELECT raid_tbl para crear una nueva tabla a partir de la tabla RAID. Sin embargo, la parte CREATE TABLE de la sentencia debe contener suficiente información para regenerar los atributos de columna así como los índices, o los atributos de columna podrían perderse y los índices no aparecer en la nueva tabla. Consulte Sección 13.1.5, “Sintaxis de CREATE TABLE”.

Los ficheros .MYD para tablas RAID en una determinada base de datos, son almacenados bajo el directorio de la base de datos, en subdirectorios que tienen nombres consistentes en dos dígitos hexadecimales en el rango de 00 a ff. Luego de convertir todas las tablas que emplean opciones RAID, estos subdirectorios seguirán existiendo pero pueden eliminarse. Hay que cerciorarse de que están vacíos, y borrarlos manualmente. (Si no están vacíos, es señal de que alguna tabla RAID ha quedado sin convertir).

En MySQL 5.0.6, fue modificado el registro binario de procedimientos almacenados y triggers. Este cambio incide sobre la seguridad, la replicación, y la recuperación de datos, como se trata en Sección 19.3, “Registro binario de procedimientos almacenados y disparadores”.

SQL Changes:

Las columnas DECIMAL ahora se almacenan en un formato más eficiente. Para convertir una tabla a fin de utilizar el nuevo tipo DECIMAL, se le debería aplicar una sentencia ALTER TABLE. Esta sentencia también cambiará las columnas VARCHAR de la tabla para que utilicen el nuevo tipo de columna VARCHAR. Para información acerca de posibles incompatibilidades con aplicaciones preexistentes, consulte Capítulo 23, Matemáticas de precisión.

MySQL 5.0.3 y posteriores emplean matemática de precisión cuando realizan cálculos con valores DECIMAL (64 dígitos decimales) y para redondear números de valor exacto. Consulte Capítulo 23, Matemáticas de precisión.

A partir de MySQL 5.0.3, los espacios sobrantes no se quitan de los valores almacenados en columnas VARCHAR y VARBINARY. Las longitudes máximas para columnas VARCHAR y VARBINARY en MySQL 5.0.3 son de 65.535 caracteres y 65.535 bytes, respectivamente.

Nota: Si se crea una tabla con los nuevos tipos de columnas VARCHAR o VARBINARY en MySQL 5.0.3 o posterior, la tabla será inutilizable si se regresa a una versión anterior a la 5.0.3. Debe hacerse un volcado de la tabla antes de instalar la versión anterior y volver a generarla luego.

A partir de MySQL 5.0.3, BIT es un tipo de dato separado, no un sinónimo para TINYINT(1). Consulte Sección 11.1.1, “Panorámica de tipos numéricos”.

MySQL 5.0.2 incorpora varios modos SQL que permiten un control más estricto sobre el rechazo de registros que tengan valores inválidos o perdidos. Consulte Sección 5.3.2, “El modo SQL del servidor” y Sección 1.7.6.2, “Restricciones (constraints) sobre datos inválidos”. Si se desea habilitar este control pero continuar usando la capacidad de MySQL para almacenar fechas incorrectas, como '2004-02-31', se debería iniciar el servidor con la opción --sql_mode=TRADITIONAL,ALLOW_INVALID_DATES.

A partir de MySQL 5.0.2, las palabras clave SCHEMA y SCHEMAS son aceptadas como sinónimos de DATABASE y DATABASES respectivamente. (Mientras que “schemata” es gramaticalmente correcta e incluso aparece en algunos nombres de tablas y bases de datos de sistema de MySQL 5.0, no puede ser utilizada como palabra clave en la entrada de sentencias).

Las variables de usuario no son case sensitive en MySQL 5.0. En MySQL 4.1, SET @x = 0; SET @X = 1; SELECT @x; creaba dos variables y retornaba 0. En MySQL 5.0, crea una sola variable y devuelve 1.

Cambios en la API de C:

El flag reconnect en la estructura MYSQL es establecido en 0 por mysql_real_connect(). Solamente experimentan un cambio aquellos programas cliente que no establecen explícitamente este flag a 0 o 1 luego de mysql_real_connect(). Tener habilitada la reconexión automática por defecto se considera muy riesgoso (debido a que los bloqueos de tablas, las tablas temporales, las variables de usuario y las variables de sesión se pierden luego de la reconexión).

2.10.2. Aumentar la versión de las tablas de privilegios

MySQL 5.0 introduce una serie de cambios en la estructura de las tablas de permisos (las tablas en la base de datos mysql) a fin de agregar nuevos privilegios y características. Las tablas de permisos también deben actualizrse cuando se efectúa la actualización a MySQL 5.0. En primer lugar debe hacerse una copia de respaldo de la base de datos mysql, y luego emplear el siguiente procedimiento.

En Unix o sistemas similares, se deben actualizar las tablas de permisos mediante la ejecución del script mysql_fix_privilege_tables:

shell> mysql_fix_privilege_tables

Se debe ejecutar este script mientras el servidor está en ejecución. Intenta conectarse como root al servidor en localhost. Si la cuenta root requiere una contraseña, la misma debe indicarse en la línea de comandos. Para MySQL 5.0 la contraseña se indica de este modo:

shell> mysql_fix_privilege_tables --password=root_password

El script mysql_fix_privilege_tables ejecuta todas las acciones necesarias para convertir las tablas de permisos hacia el formato 5.0. Durante su ejecución podrían verse algunas alertas del tipo Duplicate column name, pero deben ignorarse.

Después de ejecutar el script, el servidor debe ser detenido y reiniciado.

MySQL 5.0 para Windows incluye un script SQL llamado mysql_fix_privilege_tables.sql que puede ejecutarse empleando el cliente mysql. Si la instalación de MySQL está ubicada en C:\Program Files\MySQL\MySQL Server 5.0, el comando se vería así:

C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysql -u root -p mysql mysql> SOURCE C:/Program Files/MySQL/MySQL Server 5.0/scripts/mysql_fix_privilege_tables.sql

Si la instalación se localizara en cualquier otro directorio, habrá que ajustar la ruta apropiadamente.

El comando mysql solicitará la contraseña para el usuario root; hay que ingresarla.

Al igual que en el procedimiento para Unix, se podrían observar algunas alertas Duplicate column name a medida que mysql procesa las sentencias en el script mysql_fix_privilege_tables.sql, pero pueden ignorarse.

Luego de ejecutar el script, hay que detener y reiniciar el servidor.

Si se está actualizando a MySQL 5.0.1 o posterior, el procedimiento de actualización de las tablas de permisos que se acaba de describir agrega columnas relacionadas con las vistas, para los privilegios CREATE VIEW y SHOW VIEW. Estos privilegios existen a nivel global y a nivel de base de datos. Sus valores iniciales se establecen de esta forma:

En MySQL 5.0.2 o posterior, mysql_fix_privilege_tables copia el valor de Create_priv de la tabla user dentro de las columnas Create_view_priv y Show_view_priv.

En 5.0.1, los permisos relacionados con vistas no están habilitados para ninguna cuenta, por lo que no se puede utilizar GRANT para otorgar estos permisos a las cuentas que deban tenerlos. Para solventar esto, hay que conectarse al servidor como root y utilizar las siguientes sentencias para otorgarle estos privilegios a las cuentas root en forma manual, a través de UPDATE:

mysql> UPDATE mysql.user SET Show_view_priv = 'Y', Create_view_priv = 'Y' -> WHERE User = 'root'; mysql> FLUSH PRIVILEGES;

Luego de esto, root se podrá usar GRANT para otorgar privilegios de vistas a otras cuentas. Nota: Se deben emplear las sentencias tal como se indican; GRANT ALL no tiene efecto en los niveles global y de base de datos, porque GRANT requiere que realmente se posean los privilegios que se otorgan.

2.10.3. Copiar bases de datos MySQL a otra máquina

Se pueden copiar los ficheros .frm, .MYI, y .MYD para tablas MyISAM entre diferentes arquitecturas siempre que soporten el mismo formato de punto flotante. (MySQL se encarga del problema de intercambio de bytes -byte-swapping-). Consulte Sección 14.1, “El motor de almacenamiento MyISAM”.

En casos en que se necesite transferir bases de datos entre diferentes arquitecturas, se puede emplear mysqldump para crear un fichero conteniendo sentencias SQL. Luego puede transferirse al otro ordenador y suministrarlo al cliente mysql.

mysqldump --help permite ver las opciones disponibles. Si se están transportando los datos hacia una versión de MySQL más nueva, se debería usar mysqldump --opt, para aprovechar las optimizaciones que resultan en un fichero de volcado más pequeño y más rápido de procesar.

La forma más fácil (aunque no la más rápida) de mover una base de datos entre dos ordenadores es ejecutar los siguientes comandos en el ordenador donde se encuentra la base de datos:

shell> mysqladmin -h 'otro_ordenador' create nombre_bd shell> mysqldump --opt nombre_bd | mysql -h 'otro_ordenador' nombre_bd

Si se desea copiar una base de datos desde un ordenador remoto a través de una red lenta, se puede utilizar:

shell> mysqladmin create nombre_bd shell> mysqldump -h 'otro_ordenador' --opt --compress nombre_bd | mysql nombre_bd

También se puede almacenar el resultado en un fichero, luego transferirlo al ordenador de destino, y cargar el fichero en la base de datos. Por ejemplo, para volcar una base de datos hacia un fichero en el ordenador de origen:

shell> mysqldump --quick nombre_bd | gzip > nombre_bd.contenidos.gz

(El fichero creado en este ejemplo está comprimido). Se debe transferir hacia el ordenador de destino el fichero con el contenido de la base de datos y ejecutar estos comandos allí:

shell> mysqladmin create nombre_bd shell> gunzip < nombre_bd.contenidos.gz | mysql nombre_bd

También se puede emplear mysqldump y mysqlimport para transferir la base de datos. Para tablas grandes, esto será mucho más rápido que simplemente utilizar mysqldump. En los siguientes comandos, DUMPDIR representa la ruta completa al directorio donde se depositará la salida de mysqldump.

En primer lugar, crear el directorio para los ficheros de salida y volcar la base de datos:

shell> mkdir DUMPDIR shell> mysqldump --tab=DUMPDIR nombre_bd

Luego, transferir los ficheros desde el directorio DUMPDIR hacia el directorio correspondiente en el ordenador de destino, y allí cargar los ficheros en MySQL:

shell> mysqladmin create nombre_bd # crea la base de datos shell> cat DUMPDIR/*.sql | mysql nombre_bd # crea las tablas en la base de datos shell> mysqlimport nombre_bd DUMPDIR/*.txt # carga los datos en las tablas

Además, no hay que olvidar copiar la base de datos mysql, porque es la que contiene las tablas de permisos. Posiblemente, los comandos en el ordenador de destino se deban ejecutar como usuario root de MySQL hasta que la base de datos mysql esté en su lugar.

Luego de importar la base de datos mysql en el ordenador de destino, ejecutar mysqladmin flush-privileges para que el servidor vuelva a cargar la información de la tabla de permisos.

previous page start next page