Este documento proporciona información sobre la instalación de MySQL. Explica que antes de instalar MySQL se debe determinar si la plataforma está soportada, elegir la distribución a instalar y descargarla. Luego describe los sistemas operativos soportados por MySQL y los factores que determinan qué plataformas son más adecuadas para ejecutar MySQL con alto volumen de carga. Finalmente, resume los diferentes tipos de distribuciones disponibles y cómo se actualizan.

1. 2.1. Cuestiones generales sobre la instalación
2.1.1. Sistemas operativos que MySQL soporta
2.1.2. Escoger la distribución MySQL a instalar
2.1.3. Cómo obtener MySQL
2.1.4. Comprobar la integridad de paquetes con sumas de verificación MD5 o GnuPG
2.1.5. Conformación de la instalación
Antes de instalar MySQL, se debería hacer lo siguiente:
1. Determinarse si la plataforma donde se desea hacer la instalación está soportada.
2. Elegirse la distribución que se instalará.
3. Descargar la distribución que se desea instalar y verificar su integridad.
Esta sección contiene la información necesaria para llevar adelante estos pasos. Una vez
ejecutados, se puede seguir las instrucciones de secciones posteriores del capítulo, para
instalar la distribución elegida.
2.1.1. Sistemas operativos que MySQL soporta
En esta sección aparecen listados los sistemas operativos en los que es posible instalar
MySQL.
Se ha utilizado GNU Autoconfig, de modo que es posible portar MySQL a todos los
sistemas modernos que tengan un compilador de C++ y una implementación funcional de
subprocesos (threads) POSIX. (El soporte de subprocesos es necesario para el servidor.
Para compilar únicamente el código del cliente, no se requiere más que el compilador de
C++). Nosotros mismos desarrollamos y utilizamos el software ante todo en Linux (SuSE y
Red Hat), FreeBSD, y Sun Solaris (Versiones 8 y 9),
MySQL ha sido compilado correctamente en las siguientes combinaciones de sistemas
operativos y paquetes de subprocesos. Nótese que, para varios sistemas operativos, el
soporte nativo de subprocesos funciona solamente en las versiones más recientes.
AIX 4.x, 5.x con subprocesos nativos. Consulte Sección 2.12.5.3, “Notas sobre
IBM-AIX”.
Amiga.
BSDI 2.x with con el paquete MIT-pthreads. Consulte Sección 2.12.4.5, “Notas
sobre BSD/OS Version 2.x”.
BSDI 3.0, 3.1 y 4.x con subprocesos nativos. Consulte Sección 2.12.4.5, “Notas
sobre BSD/OS Version 2.x”.
Digital Unix 4.x con subprocesos nativos. Consulte Sección 2.12.5.5, “Notas AlphaDEC-UNIX (Tru64)”.
FreeBSD 2.x con el paquete MIT-pthreads. Consulte Sección 2.12.4.1, “Notas sobre
FreeBSD”.

2. FreeBSD 3.x and 4.x con subprocesos nativos. Consulte Sección 2.12.4.1, “Notas
sobre FreeBSD”.
FreeBSD 4.x con LinuxThreads. Consulte Sección 2.12.4.1, “Notas sobre
FreeBSD”.
HP-UX 10.20 con el paquete DCE threads o MIT-pthreads. Consulte
Sección 2.12.5.1, “Notas sobre HP-UX Version 10.20”.
HP-UX 11.x con subprocesos nativos. Consulte Sección 2.12.5.2, “Notas sobre HPUX Version 11.x”.
Linux 2.0+ con LinuxThreads 0.7.1+ o glibc 2.0.7+ para varias arquitecturas de
CPU. Consulte Sección 2.12.1, “Notas sobre Linux”.
Mac OS X. Consulte Sección 2.12.2, “Notas sobre Mac OS X”.
NetBSD 1.3/1.4 Intel y NetBSD 1.3 Alpha (requiere GNU make). Consulte
Sección 2.12.4.2, “Notas sobre NetBSD”.
Novell NetWare 6.0. Consulte Sección 2.6, “Instalar MySQL sobre NetWare”.
OpenBSD> 2.5 con subprocesos nativos. OpenBSD< 2.5 con el paquete MITpthreads. Consulte Sección 2.12.4.3, “Notas sobre OpenBSD 2.5”.
OS/2 Warp 3, FixPack 29 y OS/2 Warp 4, FixPack 4. Consulte Sección 2.12.6,
“Notas sobre OS/2”.
SCO OpenServer 5.0.X con una versión del paquete FSU Pthreads recientemente
portada. Consulte Sección 2.12.5.8, “Notas sobre SCO UNIX y OpenServer 5.0.x”.
SCO UnixWare 7.1.x. Consulte Sección 2.12.5.9, “Notas sobre SCO UnixWare
7.1.x y OpenUNIX 8.0.0”.
SCO Openserver 6.0.x. Consulte Sección 2.12.5.10, “Notas sobre SCO OpenServer
6.0.x”.
SGI Irix 6.x con subprocesos nativos. Consulte Sección 2.12.5.7, “Notas sobre SGI
Irix”.
Solaris 2.5 y posteriores con subprocesos nativos en SPARC y x86. Consulte
Sección 2.12.3, “Notas sobre Solaris”.
SunOS 4.x con el paquete MIT-pthreadspackage. Consulte Sección 2.12.3, “Notas
sobre Solaris”.
Tru64 Unix. Consulte Sección 2.12.5.5, “Notas Alpha-DEC-UNIX (Tru64)”.
Windows 9x, Me, NT, 2000, XP, y 2003. Consulte Sección 2.3, “Instalar MySQL
en Windows”.
No todas las plataformas son igualmente aptas para ejecutar MySQL. Los siguientes
factores determinan si una plataforma está más o menos bien preparada para un servidor
MySQL con alto volumen de carga y para misiones crítica:
Estabilidad general de la biblioteca de subprocesos. Una plataforma puede tener una
excelente reputación en otras situaciones, pero MySQL es estable como lo sea la
biblioteca de subprocesos que utiliza la plataforma, aun cuando cualquier otro
aspecto sea perfecto.
La capacidad del núcleo o kernel del sistema operativo y de la biblioteca de
subprocesos para aprovechar sistemas de multiprocesamiento simétrico (SMP). En
otras palabras, cuando un proceso crea un subproceso, éste debería poderse ejecutar
en una CPU diferente a la del proceso original.

3. La capacidad del núcleo o kernel del sistema operativo y de la biblioteca de
subprocesos para ejecutar varios subprocesos que bloquean y liberan mutexes
frecuentemente en una pequeña región crítica sin excesivos cambios de contexto. Si
la implementación de pthread_mutex_lock() es muy proclive a consumir tiempo
de CPU, esto afectará en gran manera a MySQL. Si no se previene este problema,
añadir más CPUs hará todavía más lento a MySQL.
El rendimiento y la estabilidad general del sistema de ficheros.
Si se emplean grandes tablas, la capacidad del sistema de ficheros para gestionar
eficientemente archivos de gran tamaño.
El nivel de experiencia que los desarrolladores de MySQL AB posean sobre una
determinada plataforma. Si la conocen bien, habilitan optimizaciones específicas y
soluciones en tiempo de compilación. Además pueden proporcionar consejos sobre
cómo configurar el sistema en forma óptima para MySQL.
El volumen de pruebas realizadas por MySQL AB sobre configuraciones similares.
La cantidad de usuarios que han ejecutado MySQL con éxito en la misma
plataforma y en configuraciones similares. Si este número es alto, las probabilidades
de encontrar sorpresas específicas de la plataforma son mucho menores.
En base a estos criterios, las mejores plataformas para ejecutar MySQL en este momento
son x86 con SuSE Linux (kernel versión 2.4 o 2.6), y ReiserFS (o cualquier distribución de
Linux similar) y SPARC con Solaris (2.7-9). FreeBSD aparece en tercer lugar, pero es de
esperar que se integre al lote principal cuando se mejore la biblioteca de subprocesos.
También las otras plataformas donde MySQL se compila y ejecuta en la actualidad podrian
ser incluidas en la categoria principal, pero no con el mismo nivel de estabilidad y
rendimiento. Esto requiere un esfuerzo por parte de los desarrolladores de MySQL en
cooperación con los desarrolladores de los sistemas operativos y de bibliotecas de
componentes de las que depende MySQL. Si Usted está interesado en mejorar alguno de
estos componentes, está en posición de influir en su desarrollo, y necesita información más
detallada acerca de lo que MySQL requiere para funcionar mejor, envíe un mensaje de
correo electrónico a la lista de correo internals de MySQL. Consulte Sección 1.6.1.1,
“Las listas de correo de MySQL”.
El propósito de la anterior comparación no es afirmar que un sistema es, en términos
generales, mejor o peor que otro. Se trata solamente de la elección de un sistema operativo
con el objetivo de ejecutar MySQL. Por lo tanto, el resultado de la comparación podría ser
diferente si se consideraran otros factores. En algunos casos, la razón de que un sistema
operativo sea mejor que otros podría residir simplemente en que los desarrolladores de
MySQL han podido dedicar más esfuerzos a la prueba y optimización sobre una plataforma
en particular. Lo aquí manifestado son las observaciones de estos desarrolladores a fin de
ayudar al usuario a decidir la plataforma sobre la que ejecutar MySQL.
2.1.2. Escoger la distribución MySQL a instalar
2.1.2.1. Escoger la versión de MySQL a instalar
2.1.2.2. Escoger un formato de distribución
2.1.2.3. Cómo y cuándo se entregan las actualizaciones

4. 2.1.2.4. Filosofía de las entregas—No hay bugs conocidos en las entregas
2.1.2.5. Binarios de MySQL compilados por MySQL AB
Como parte de los preparativos para instalar MySQL, debe decidirse qué versión se
utilizará. El desarrollo de MySQL se divide en entregas (releases) sucesivas, y el usuario
puede decidir cuál es la que mejor satisface sus necesidades. Después de haber elegido la
versión a instalar, se debe optar por un formato de distribución. Las entregas están
disponibles en formato binario o código fuente.
2.1.2.1. Escoger la versión de MySQL a instalar
La primera decisión a tomar es si se desea emplear una entrega "en producción" (estable) o
una entrega de desarrollo. En el proceso de desarrollo de MySQL coexisten múltiples
entregas, cada una con un diferente estado de madurez:
MySQL 5.1 es la próxima serie de entregas de desarrollo, y en ella se
implementarán las nuevas características. En breve se pondrán a disposición de los
usuarios interesados en hacer pruebas integrales las entregas Alfa.
MySQL 5.0 es la serie de entregas estables (para producción). Solamente se liberan
nuevas entregas para corrección de errores, no se añaden nuevas características que
pudieran afectar a la estabilidad.
MySQL 4.1 es la anterior serie de entregas estables (para producción). Se liberarán
nuevas entregas para solucionar problemas de seguridad o errores críticos. En esta
serie no se agregarán nuevas caracteristicas de importancia.
MySQL 4.0 y 3.23 son las antiguas series de entregas estables (para producción).
Estas versiones están discontinuadas, de modo que solamente se liberarán nuevas
entregas para solucionar errores de seguridad extremadamente críticos.
Los desarrolladores de MySQL no son partidarios de la "congelación" total del código de
una versión, puesto que anula la posibilidad de introducir soluciones a errores. Cuando se
habla de algo “congelado” se quiere expresar que no se harán más que pequeñas
modificaciones que no deberían afectar a la forma en que funciona actualmente una entrega
en un entorno de producción. Naturalmente, los errores que se corrigen en una serie se
propagan a las siguientes si son relevantes.
Si el usuario está comenzando a emplear MySQL por primera vez o intentando su
implementación en un sistema para el que no hay una distribución binaria, es recomendable
instalar una entrega perteneciente a una serie en producción. Actualmente, MySQL 5.0.
Todas las entregas de MySQL, aun aquellas pertenecientes a una serie en desarrollo, se
verifican con las pruebas de rendimiento de MySQL y se prueban extensamente antes de
liberarse.
Si se está ejecutando una versión más antigua y se desea actualizar, pero se quiere evitar un
cambio brusco con el consiguiente riesgo de incompatibilidades, debería actualizarse a la
última versión dentro de la misma serie de entregas que se utiliza actualmente (es decir,
aquélla donde únicamente la última parte del número de versión es más nueva que la

5. actual). En dicha versión los desarrolladores de MySQL han tratado de corregir solamente
errores fatales y realizar cambios pequeños, relativamente “seguros”.
Si se desea emplear características nuevas que no están en las entregas para ambientes de
producción, habrá que utilizar una versión perteneciente a una serie de entregas en
desarrollo. Hay que tener en cuenta que las entregas de desarrollo no son tan estables como
las que están en producción.
Si lo que se desea es emplear el código fuente más actualizado disponible, que contenga
todas las correcciones y esté libre de bugs, se debería emplear uno de los repositorios
BitKeeper, que no son “entregas” propiamente dichas, pero es el código en el que se
basarán las entregas futuras.
El esquema de denominaciones de MySQL emplea para las entregas nombres consistentes
en tres números y un sufijo; por ejemplo, mysql-5.0.9-beta. Los números dentro del
nombre de la entrega se interpretan como sigue:
El primer número (5) es la versión principal y describe el formato de fichero. Todas
las entregas de la versión 5 comparten el mismo formato para sus ficheros.
El segundo número (0) es el nivel de entrega. En conjunto, la versión principal y el
nivel de entrega constituyen el número de la serie.
El tercer número (9) es el número de versión dentro de la serie. Se incrementa para
cada nueva entrega. Usualmente es deseable poseer la última versión dentro de la
serie que se está usando.
Para los cambios menores, el que se incrementa es el último número en la denominación de
la versión. Cuando se adicionan características de importancia o aparecen
incompatibilidades menores con versiones precedentes, se incrementa el segundo número.
Cuando cambia el formato de los ficheros, se incrementa el primer número.
Las denominaciones de las entregas también incluyen un sufijo para indicar el grado de
estabilidad. Una entrega progresa a través de un conjunto de sufijos a medida que mejora su
estabilidad. Los posibles sufijos son:
alpha indica que la entrega contiene características nuevas que no han sido
plenamente probadas. Asimismo, en la sección "Novedades" deberían estar
documentados los errores conocidos, aunque usualmente no los hay. Consulte
Apéndice C, Historial de cambios de MySQL. Por lo general, en cada entrega alpha
se implementan nuevos comandos y extensiones, y es la etapa donde puede
producirse la mayor cantidad de cambios en el código. Sin embargo, debido a las
pruebas realizadas, no deberían existir errores conocidos.
beta significa que la entrega está destinada a poseer sus características completas y
que se probó todo el código nuevo. No se agregan características de importancia, y
no deberían existir errores críticos. Una versión cambia de alpha a beta cuando no
se han descubierto errores fatales durante al menos un mes, y no hay planes de
agregar características que pudieran comprometer la fiabilidad del código existente.

6. Todas las APIs, las estructuras visibles externamente y las columnas para comandos
SQL no se modificarán en las futuras entregas, sean beta, candidatas, o de
producción.
rc es una entrega candidata; o sea, una beta que ha estado funcionando un intervalo
de tiempo y parece hacerlo bien. Solamente podrían ser necesarias correcciones
menores. (Una entrega candidata es formalmente conocida como una entrega
gamma.)
Si no hay un sufijo, significa que la versión se ha estado utilizando por un tiempo en
diferentes sitios sin que se informaran errores críticos reproducibles, más allá de los
específicos de una plataforma. Esto es lo que se llama una entrega de producción
(estable) o “General Availability” (GA).
MySQL utiliza un esquema de denominaciones ligeramente diferente a muchos otros
productos. En general, se considera segura para usar una versión que ha durado un par de
semanas sin ser reemplazada por una nueva dentro de la misma serie de entregas.
La totalidad de las entregas de MySQL se someten a pruebas de fiabilidad y rendimiento
(estándares dentro de MySQL) para cerciorarse de que son relativamente seguras de
utilizar. Puesto que las pruebas estándar son ampliadas cada vez para que incluyan todos
los errores anteriormente descubiertos, el conjunto de pruebas se mejora continuamente.
Cada entrega se prueba al menos con:
Un conjunto interno de pruebas
El directorio mysql-test contiene un amplio conjunto de casos de prueba. En
MySQL, prácticamente cada versión binaria del servidor pasa por estas pruebas.
Consulte Sección 27.1.2, “El paquete de pruebas MySQL Test” para más
información sobre este conjunto de pruebas.
El conjunto de pruebas de rendimiento de MySQL
Este conjunto ejecuta una serie de consultas comunes. Es también una manera de
verificar que las últimas optimizaciones realizadas hacen efectivamente más rápido
el código. Consulte Sección 7.1.4, “El paquete de pruebas de rendimiento
(benchmarks) de MySQL”.
La prueba crash-me
Esta prueba intenta determinar las características soportadas por la base de datos y
cuáles son sus capacidades y limitaciones. Consulte Sección 7.1.4, “El paquete de
pruebas de rendimiento (benchmarks) de MySQL”.

7. Otra prueba consiste en utilizar la versión más reciente del servidor en el entorno de
producción de MySQL, en al menos un ordenador. Se dispone de más de 100GB de datos
para este fin.
2.1.2.2. Escoger un formato de distribución
Después de haber decidido qué versión de MySQL instalar, se debe elegir entre una
distribución binaria o una de código fuente. Probablemente la elección más frecuente sea la
distribución binaria, si existe una para la plataforma en cuestión. Hay distribuciones
binarias disponibles en formato nativo para muchas plataformas, como los ficheros RPM
para Linux, paquetes de instalación DMG para Mac OS X, y ficheros comprimidos Zip y
tar.
Algunas razones a favor de la elección de una distribución binaria:
Es más fácil de instalar que una distribución de código fuente.
Para satisfacer distintos requerimientos de usuarios, se facilita dos versiones
binarias diferentes: una que contiene motores de almacenamiento no transaccionales
(más pequeña y rápida) y una configurada con las más importantes opciones, como
por ejemplo tablas transaccionales. Ambas versiones se compilan a partir de la
misma distribución de código fuente. Todos los clientes MySQL nativos pueden
conectarse a ambas versiones indistintamente.
La versión binaria extendida de MySQL está señalada con el sufijo -max y está
configurada con las mismas opciones que mysqld-max. Consulte Sección 5.1.2, “El
servidor extendido de MySQLmysqld-max”.
Si se desea utilizar MySQL-Max en formato RPM, primero debe instalarse el RPM de
MySQL-server estándar.
Bajo ciertas circunstancias, puede ser mejor instalar MySQL a partir de una distribución de
código fuente:
Cuando se desea instalar MySQL en una ubicación especial. Las distribuciones
binarias estándar están listas para ejecutarse en cualquier sitio, pero podria ser
necesaria aún más flexibilidad en la elección de la ubicación de los componentes.
Cuando se desea configurar mysqld con algunas características adicionales que no
se encuentran incluídas en las distribuciones binarias estándar. La siguiente es una
lista de las opciones adicionales más comunes:
o --with-innodb (habilitado por defecto en todas las entregas binarias de la
serie 5.0 de MySQL)
o --with-berkeley-db (no está disponible en todas las plataformas)
o
o
o
--with-libwrap
--with-named-z-libs
--with-debug[=full]
(en algunas distribuciones binarias ya está incluido)
Cuando se desea excluir de mysqld algunas características presentes en las
distribuciones binarias estándar. Por ejemplo, estas distribuciones se compilan

8. normalmente con soporte para todos los conjuntos de caracteres. Si se deseara un
servidor MySQL más liviano, se lo puede recompilar con soporte solamente para el
conjunto de caracteres que se necesita.
Cuando se posee un compilador especial (como pgcc) o se desea utilizar opciones
de compilación optimizadas para un determinado procesador. Las distribuciones
binarias se compilan con opciones que deberían funcionar en diversos procesadores
de la misma familia.
Cuando se desea emplear la última versión de código fuente desde un repositorio
BitKeeper, para acceder a modificaciones recientes. Por ejemplo, si se detecta un
error y se comunica al equipo de desarrollo de MySQL, la corrección se realiza
sobre el código fuente, que queda almacenado en el repositorio. La primera entrega
con esta corrección será la siguiente.
Cuando se desea leer (o modificar) el código en C y C++ que conforma MySQL.
Para este fin, se debería poseer una distribución de código fuente, ya que es la
documentación más actualizada.
Las distribuciones de código fuente contienen más pruebas y ejemplos que las
distribuciones binarias.
2.1.2.3. Cómo y cuándo se entregan las actualizaciones
MySQL evoluciona con rapidez, y sus desarrolladores desean compartir el desarrollo con
los usuarios. Se intenta producir una entrega cada vez que se incorpora nuevas
características que pueden ser útiles para otros.
También se escucha a los usuarios que solicitan características sencillas de implementar. Se
toma nota de lo que los usuarios con licencia desean, y especialmente de lo que solicitan los
clientes de soporte, intentando actuar al respecto.
No es necesario descargar una entrega para conocer sus características, puesto que se puede
dilucidar si una entrega posee determinada característica en la sección Novedades. Consulte
Apéndice C, Historial de cambios de MySQL.
MySQL se rige por la siguiente política de actualizaciones:
Las entregas se liberan dentro de cada serie. Para cada entrega, el último número en
la versión es uno más que en la entrega anterior dentro de la misma serie.
Las entregas de producción (estables) tienden a aparecer 1 o 2 veces por año. Sin
embargo, de hallarse pequeños bugs, se libera una entrega con solamente
correcciones.
Las entregas de corrección para viejas entregas tienden a aparecer cada 4 u 8
semanas.
De cada entrega principal Mysql AB realiza distribuciones binarias para algunas
plataformas. Otros sujetos pueden realizar distribuciones binarias para otros
sistemas, pero probablemente con menos frecuencia.
Las correcciones están disponibles tan pronto se identifican errores pequeños o no
críticos, pero que igualmente afectan al uso normal de MySQL. Se colocan en el
repositorio público BitKeeper, y se incluyen en la entrega siguiente.

9. Si por cualquier motivo se descubre un error fatal en una entrega, la política de
MySQL es corregirlo mediante una nueva entrega, tan pronto como sea posible. (¡Y
veríamos con agrado que otras compañías hicieran lo mismo!).