Tabla de contenidos
En este capítulo se describe cómo obtener e instalar MySQL:
Debe determinarse si la plataforma donde se desea hacer la instalación está soportada. Nótese que no todos los sistemas soportados son igualmente adecuados para ejecutar MySQL. En algunas plataformas el funcionamiento será mucho más robusto y eficiente que en otras. Consulte Sección 2.1.1, “Sistemas operativos que MySQL soporta” para más detalles.
Debe elegirse la distribución que se instalará. Hay varias versiones de MySQL disponibles, y la mayoría lo están en varios formatos de distribución. Se puede elegir entre distribuciones prearmadas que contienen programas binarios (precompilados) o bien código fuente. En caso de duda, debe elegirse una distribución binaria. También se provee acceso público al código fuente para quienes deseen ver los desarrollos más recientes y colaborar en el testeo de código nuevo. Para establecer qué versión y tipo de distribución debería usarse, consulte Sección 2.1.2, “Escoger la distribución MySQL a instalar”.
Descargar la distribución que se desea
instalar. Para ver una lista de sitios desde los
cuales se puede obtener MySQL, consúltese
Sección 2.1.3, “Cómo obtener MySQL”. Se puede verificar la
integridad de la distribución como se describe en
Sección 2.1.4, “Comprobar la integridad de paquetes con sumas de verificación MD5 o GnuPG
”.
Instalar la distribución. Para instalar MySQL desde una dsitribución binaria, empleense las instrucciones en Sección 2.2, “Instalación MySQL estándar con una distribución binaria”. Para instalar MySQL a partir de una distribución de código fuente o desde el directorio de desarrollo actual, utilícense las instrucciones en Sección 2.8, “Instalación de MySQL usando una distribución de código fuente”.
Nota: Si se planea actualizar una versión existente de MySQL a una versión más nueva en lugar de instalarlo por primera vez, consúltese Sección 2.10, “Aumentar la versión de MySQL” para obtener información acerca de procedimientos de actualización y de cuestiones que se deberían de considerar antes de actualizar.
Si se encontrasen problemas durante la instalación, consúltese Sección 2.12, “Notas específicas sobre sistemas operativos” para obtener información sobre la resolución de problemas en plataformas específicas.
Realizar cualquier ajuste que sea necesario con posterioridad a la instalación. Luego de instalar MySQL, léase Sección 2.9, “Puesta en marcha y comprobación después de la instalación”. Esta sección contiene información importante acerca de cómo asegurarse de que el servidor de MySQL está funcionando adecuadamente. También describe cómo hacer seguras las cuentas de usuario iniciales de MySQL, que no poseen contraseñas hasta que se les hayan asignado. Esta sección es de aplicación si MySQL se ha instalado utilizando tanto una distribución binaria como una de código fuente.
Si se desea ejecutar los scripts para medir el rendimiento de MySQL, debe estar disponible el soporte de Perl para MySQL. Consúltese Sección 2.13, “Notas sobre la instalación de Perl”.
Antes de instalar MySQL, se debería hacer lo siguiente:
Determinarse si la plataforma donde se desea hacer la instalación está soportada.
Elegirse la distribución que se instalará.
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.
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 Alpha-DEC-UNIX (Tru64)”.
FreeBSD 2.x con el paquete MIT-pthreads. Consulte Sección 2.12.4.1, “Notas sobre FreeBSD”.
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 HP-UX 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 MIT-pthreads. 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-pthreads package. 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.
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.
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.
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 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.
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”.
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.
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 MySQL mysqld-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:
--with-innodb
(habilitado por
defecto en todas las entregas binarias de la serie 5.0
de MySQL)
--with-berkeley-db
(no está
disponible en todas las plataformas)
--with-libwrap
--with-named-z-libs
(en algunas
distribuciones binarias ya está incluido)
--with-debug[=
full
]
Cuando se desea excluir de mysqld algunas características presentes en las distribuciones binarias estándar. Por ejemplo, estas distribuciones se compilan 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.
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.
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!).
Se dedica gran cantidad de tiempo y esfuerzo en producir entregas libres de errores. Que se tenga conocimiento, no se ha liberado una sola versión de MySQL con errores fatales reproducibles conocidos. (Un error “fatal” es uno que provoca la terminación abrupta de MySQL bajo condiciones de uso normales, que produce respuestas incorrectas para consultas normales, o que tiene problemas de seguridad).
Se han documentado todos los problemas, errores y cuestiones que dependen de decisiones de diseño. Consulte Sección A.8, “Problemas conocidos en MySQL”.
La intención de los desarrolladores es corregir todo lo que tenga solución sin afectar a la estabilidad de una versión estable de MySQL. En ciertos casos, esto significa que se puede corregir un error en las versiones en desarrollo, pero no en la versión estable (de producción). De todos modos estos errores se documentan para que los usuarios estén al tanto de ellos.
El proceso de desarrollo comprende las siguientes etapas:
Se recolectan informes de errores desde la lista de soporte técnico, desde la base de datos de errores en http://bugs.mysql.com/, y desde las listas de correo externas.
Todos los errores hallados en versiones con soporte, se introducen en la base de datos de errores.
Cuando se corrige un error, se intenta crear un caso de prueba e incluirlo en el sistema de pruebas, para tener seguridad de que el error no vuelva a ocurrir sin ser detectado. (Cerca del 90% de los errores corregidos tienen un caso de prueba).
Se crean casos de prueba para cada nueva característica que se agrega a MySQL.
Antes de crear una entrega, se verifica que todos los errores reproducibles informados para esa versión de MySQL (3.23.x, 4.0.x, 4.1.x, 5.0.x, etc.) están solucionados. Si alguno no pudiera corregirse (debido a una decisión de diseño) esto se documenta en el manual. Consulte Sección A.8, “Problemas conocidos en MySQL”.
Se hace una compilación para cada plataforma para la que se brinda una distribución binaria (más de 15) y se ejecutan pruebas de fiabilidad y rendimiento en todas ellas.
No se publica una distribución binaria para una plataforma en la que fallaron las pruebas de fiabilidad o rendimiento. Si el problema se debe a un error en el código fuente, se resuelve, y para todas las plataformas se vuelve a compilar y probar.
El proceso de compilación y prueba dura entre 2 y 3 días. Si durante el proceso se descubre un error fatal (por ejemplo, uno que genere un fichero de volcado del núcleo), se corrige el error y el proceso recomienza.
Después de publicar la distribución binaria en
http://dev.mysql.com/, se envía un mensaje
con la novedad a las listas de correo
mysql
y announce
.
Consulte Sección 1.6.1.1, “Las listas de correo de MySQL”. El mensaje
contiene una lista con todos los cambios y problemas
conocidos que contiene la entrega. La sección
Known Problems (problemas
conocidos) solo ha sido necesaria en una pequeña cantidad
de entregas.
Para que los usuarios accedan rápidamente a las nuevas características de MySQL, se produce una entrega nuevo cada 4 a 8 semanas. El código fuente se prepara diariamente y se pone a disposición en http://downloads.mysql.com/snapshots.php.
Si, a pesar de los esfuerzos realizados, se toma
conocimiento de un error o problema crítico específicos
de una plataforma después de que una entrega haya sido
liberada, se genera una nueva entrega
'a'
con la corrección para la
plataforma afectada. Gracias a la gran base de usuarios,
cualquier problema se detecta y resuelve muy rápidamente.
El trabajo del equipo de desarrollo en la generación de
entregas estables es bastante bueno. De las últimas 150
entregas, se han debido rehacer menos de diez. En tres de
estos casos, el error se debió a defectos en la
biblioteca glibc
en uno de los
ordenadores de desarrollo, que llevó tiempo descubrir.
Uno de los servicios que MySQL AB ofrece es proveer un conjunto de distribuciones binarias compiladas en sistemas propios o amablemente proporcionados por adeptos de MySQL.
A parte de las distribuciones binarias provistas en formatos
específicos de algunas plataformas, se ofrecen distribuciones
binarias para una serie de plataformas en forma de ficheros
comprimidos tar (ficheros
.tar.gz
). Consulte
Sección 2.2, “Instalación MySQL estándar con una distribución binaria”.
Para distribuciones Windows, consulte Sección 2.3, “Instalar MySQL en Windows”.
Estas distribuciones se generan empleando el script
Build-tools/Do-compile
, que compila el
código fuente y crea el fichero binario
tar.gz
empleando
scripts/make_binary_distribution.
Estos binarios están configurados y compilados con los
siguientes compiladores y opciones de compilación. Esta
información también puede obtenerse observando las variables
COMP_ENV_INFO
y
CONFIGURE_LINE
dentro del script
bin/mysqlbug de cada fichero de
distribución binaria tar.
Los siguientes binarios se compilan en los sistemas de desarrollo de MySQL AB:
Linux 2.4.xx x86 con gcc 2.95.3:
CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc
CXXFLAGS="-O2 -mcpu=pentiumpro -felide-constructors"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.x x86 con icc (compilador Intel C++ 8.1 o posterior):
CC=icc CXX=icpc CFLAGS="-O3 -unroll2 -ip -mp
-no-gcc -restrict" CXXFLAGS="-O3 -unroll2 -ip -mp -no-gcc
-restrict" ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static --with-embedded-server
--with-innodb
Obsérvese que las versiones 8.1 y posteriores del
compilador Intel tienen drivers separados para C 'puro'
(icc
) y c++ (icpc
);
si se utiliza icc versión 8.0 o
anterior para compilar MySQL, será necesario establecer
CXX=icc
.
Linux 2.4.xx Intel Itanium 2 con ecc (Compilador Intel C++ Itanium 7.0):
CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline"
CXX=ecc CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx Intel Itanium con ecc (Compilador Intel C++ Itanium 7.0):
CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx alpha con ccc
(Compaq C
V6.2-505 / Compaq C++ V6.3-006):
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx
CXXFLAGS="-fast -arch generic -noexceptions -nortti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-mysqld-ldflags=-non_shared
--with-client-ldflags=-non_shared
--disable-shared
Linux 2.x.xx ppc con gcc 2.95.4:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
Linux 2.4.xx s390 con gcc 2.95.3:
CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2
-felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared --with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.xx x86_64 (AMD64) con gcc 3.2.1:
CXX=gcc ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
Sun Solaris 8 x86 con gcc 3.2.3:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Sun Solaris 8 SPARC con gcc 3.2:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-z-libs=no --with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 8 SPARC 64-bit con gcc 3.2:
CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -m64 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 SPARC con gcc 2.95.3:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 SPARC con cc-5.0
(Sun
Forte 5.0):
CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa
-xstrconst -mt -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt
-D_FORTEC_ -xarch=v9" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=no
--enable-thread-safe-client --disable-shared
IBM AIX 4.3.2 ppc con gcc 3.2.3:
CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared
IBM AIX 4.3.3 ppc con xlC_r
(IBM Visual
Age C/C++ 6.0):
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-innodb
IBM AIX 5.1.0 ppc con gcc 3.3:
CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared
IBM AIX 5.2.0 ppc con xlC_r
(IBM Visual
Age C/C++ 6.0):
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-embedded-server
--with-innodb
HP-UX 10.20 pa-risc1.1 con gcc 3.1:
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC"
CXX=gcc CXXFLAGS="-DHPUX -I/opt/dce /include
-felide-constructors -fno-exceptions -fno-rtti -O3 -fPIC"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-pthread
--with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
--disable-shared
HP-UX 11.00 pa-risc con aCC
(HP ANSI
C++ B3910B A.03.50):
CC=cc CXX=aCC CFLAGS=+DAportable
CXXFLAGS=+DAportable ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
HP-UX 11.11 pa-risc2.0 64bit con aCC
(HP ANSI C++ B3910B A.03.33):
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
HP-UX 11.11 pa-risc2.0 32bit con aCC
(HP ANSI C++ B3910B A.03.33):
CC=cc CXX=aCC CFLAGS="+DAportable"
CXXFLAGS="+DAportable" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
HP-UX 11.22 ia64 64bit con aCC
(HP
aC++/ANSI C B3910B A.05.50):
CC=cc CXX=aCC CFLAGS="+DD64 +DSitanium2"
CXXFLAGS="+DD64 +DSitanium2" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
Apple Mac OS X 10.2 powerpc con gcc 3.1:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
FreeBSD 4.7 i386 con gcc 2.95.4:
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=not-used
--disable-shared
FreeBSD 4.7 i386 empleando LinuxThreads con gcc 2.95.4:
CFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98
-D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/pthread/linuxthreads"
CXXFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98
-D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/pthread/linuxthreads" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--enable-thread-safe-client --enable-local-infile
--enable-assembler
--with-named-thread-libs="-DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R
-D_THREAD_SAFE -I /usr/local/include/pthread/linuxthreads
-L/usr/local/lib -llthread -llgcc_r" --disable-shared
--with-embedded-server --with-innodb
QNX Neutrino 6.2.1 i386 con gcc 2.95.3qnx-nto 20010315:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
Las siguientes distribuciones binarias están compiladas sobre sistemas de terceros, facilitados por otros usuarios a MySQL AB. Se facilitan solamente por cortesía, ya que MySQL AB no tiene control total sobre estos sistemas, por lo que sólo puede proporcionar un soporte limitado sobre las distribuciones compiladas en ellos.
SCO Unix 3.2v5.0.7 i386 con gcc 2.95.3:
CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc
CXXFLAGS="-O3 -mpentium -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
SCO UnixWare 7.1.4 i386 con CC 3.2:
CC=cc CFLAGS="-O" CXX=CC ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared --with-readline
SCO OpenServer 6.0.0 i386 con CC 3.2:
CC=cc CFLAGS="-O" CXX=CC ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared --with-readline
Compaq Tru64 OSF/1 V5.1 732 alpha con
cc/cxx
(Compaq C V6.3-029i / DIGITAL
C++ V6.1-027):
CC="cc -pthread" CFLAGS="-O4 -ansi_alias
-ansi_args -fast -inline speed -speculate all" CXX="cxx
-pthread" CXXFLAGS="-O4 -ansi_alias -fast -inline speed
-speculate all -noexceptions -nortti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
--disable-shared
--with-mysqld-ldflags=-all-static
SGI Irix 6.5 IP32 con gcc 3.0.1:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared
FreeBSD/sparc64 5.0 con gcc 3.2.1:
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Las siguientes opciones de compilación han sido empleadas en distribuciones binarias en el pasado. Estas distribuciones ya no reciben actualizaciones, pero las opciones de compilación se listan para referencia.
Linux 2.2.xx SPARC con egcs 1.1.2:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--disable-shared
Linux 2.2.x con x686 con gcc 2.95.2:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3
-mpentiumpro -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--enable-assembler --with-mysqld-ldflags=-all-static
--disable-shared --with-extra-charsets=complex
SunOS 4.1.4 2 sun4c con gcc 2.7.2.1:
CC=gcc CXX=gcc CXXFLAGS="-O3
-felide-constructors" ./configure
--prefix=/usr/local/mysql --disable-shared
--with-extra-charsets=complex --enable-assembler
SunOS 5.5.1 (y posteriores) sun4u con egcs 1.0.3a o 2.90.27 o
gcc 2.95.2 y posteriores:
CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex --enable-assembler
SunOS 5.6 i86pc con gcc 2.8.1:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
BSDI BSD/OS 3.1 i386 con gcc 2.7.2.1:
CC=gcc CXX=gcc CXXFLAGS=-O ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
BSDI BSD/OS 2.1 i386 con gcc 2.7.2:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
AIX 4.2 con gcc 2.7.2.2:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
Si alguien tiene opciones más efectivas para cualquiera de
las configuraciones listadas, puede enviarlas por correo
electrónico a la lista de correo MySQL
internals
. Consulte
Sección 1.6.1.1, “Las listas de correo de MySQL”.
Las distribuciones RPM para entregas de MySQL 5.0 disponibles en el sitio web de MySQL están generadas por MySQL AB.
Si desea compilar una versión de depuración de MySQL,
debería agregar --with-debug
o
--with-debug=full
a los comandos
configure anteriores, y quitar cualquier
opción -fomit-frame-pointer
.
Consulte la página de descargas de MySQL (http://dev.mysql.com/downloads/) para obtener información acerca de la versión más actualizada e instrucciones de descarga. Para obtener una lista actualizada de los sitios de replicación que también ofrecen descargas de MySQL, consulte http://dev.mysql.com/downloads/mirrors.html. Encontrará información acerca de cómo constituir un sitio de replicación y de cómo informar sobre un sitio de replicación que esté funcionando mal o esté desactualizado.
El principal sitio de replicación se encuentra en http://mirrors.sunsite.dk/mysql/.
Después de descargar la distribución de MySQL que se adecúe a las necesidades del caso y antes de proceder a su instalación, se debería verificar su integridad. MySQL AB ofrece tres posibles formas de hacerlo:
Sumas de verificación (checksums) MD5
Firmas criptográficas empleando GnuPG
,
el GNU Privacy Guard.
Para paquetes RPM, el mecanismo de verificación de integridad que incorporan estos paquetes.
Las siguientes secciones describen cómo emplear estos métodos.
Si se advierte que la suma de verificación MD5 o la firma GPG
no coinciden, en primer lugar debe intentarse con una nueva
descarga del paquete, quizá desde otro sitio de replicación.
Si la verificación de la integridad del paquete fracasa
repetidas veces, se debe notificar el incidente a MySQL AB,
informando del nombre completo del paquete y del sitio de donde
se descargó, a las direcciones
<webmaster@mysql.com>
o
<build@mysql.com>
. No debe utilizarse el sistema de
informe de errores para comunicar problemas de descarga.
Después de haber descargado un paquete MySQL, se debería
estar seguro de que su suma de verificación (checksum) MD5
concuerda con la provista en la página de descarga. Cada
paquete tiene una suma de verificación individual, que se
puede verificar mediante el siguiente comando, donde
package_name
es el nombre del paquete
descargado:
shell> md5sum package_name
Ejemplo:
shell> md5sum mysql-standard-5.0.9-beta-linux-i686.tar.gz aaab65abbec64d5e907dcd41b8699945 mysql-standard-5.0.9-beta-linux-i686.tar.gz
Se debería verificar que la suma de verificación resultante (la cadena de dígitos hexadecimales) concuerda con la que se muestra en la página de descargas inmediatamente debajo del paquete correspondiente.
Nota: lo que se debe
comprobar es la suma de verificación del
fichero comprimido (por
ejemplo, el fichero .zip
o
.tar.gz
) y no de los ficheros contenidos
dentro del comprimido.
Hay que notar que no todos los sistemas operativos soportan el comando md5sum. En algunos, se llama simplemente md5 y otros, directamente no lo poseen. En Linux forma parte del paquete GNU Text Utilities, que está disponible para una gran variedad de plataformas. El código fuente puede bajarse desde http://www.gnu.org/software/textutils/. Si OpenSSL está instalado, también puede emplearse el comando openssl md5 package_name. Una versión para DOS/Windows del comando md5 se halla disponible en http://www.fourmilab.ch/md5/.
Otro método para verificar la integridad y autenticidad de un paquete es utilizar firmas criptográficas. Esta manera es más fiable que las sumas de verificación MD5, pero requiere más trabajo.
MySQL AB firma los paquetes de MySQL 5.0 con GnuPG (GNU Privacy Guard). GnuPG es una alternativa de código abierto frente a la conocida Pretty Good Privacy (PGP) de Phil Zimmermann. Consulte http://www.gnupg.org/ para más información acerca de GnuPG y de cómo obtenerlo e instalarlo en su sistema. La mayoría de las distribuciones Linux incluyen GnuPG instalado por defecto. Para mayor información acerca de GnuPG consulte http://www.openpgp.org/.
A fin de verificar la firma de un paquete específico, antes
se debe obtener una copia de la clave pública para GPG de
MySQL AB. Se puede descargar de
http://www.keyserver.net/. La clave está
identificada como build@mysql.com
.
Alternativamente, puede cortarse y copiarse la clave
directamente del siguiente texto:
Key ID: pub 1024D/5072E1F5 2003-02-03 MySQL Package signing key (www.mysql.com) <build@mysql.com> Fingerprint: A4A9 4068 76FC BD3C 4567 70C8 8C71 8D3B 5072 E1F5 Public Key (ASCII-armored): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3 RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3 BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE 7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p /1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92 6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ== =YJkx -----END PGP PUBLIC KEY BLOCK-----
Para incorporar esta clave dentro del GPG en uso, se emplea el
comando gpg --import. Por ejemplo, si la
clave estuviese guardada en un fichero llamado
mysql_pubkey.asc
, el comando de
importación tomaría esta forma:
shell> gpg --import mysql_pubkey.asc
Debe consultarse la documentación de GPG para obtener más información sobre el manejo de claves públicas.
Después de haber descargado e importado la clave pública,
debe descargarse el paquete MySQL deseado y la correspondiente
firma, que también se encuentra en la página de descargas.
El fichero de firma tiene el mismo nombre que el fichero de
distribución, con una extensión .asc
.
Por ejemplo:
Fichero de distribución | mysql-standard-5.0.9-beta-linux-i686.tar.gz |
Fichero de firma | mysql-standard-5.0.9-beta-linux-i686.tar.gz.asc |
Se debe verificar que ambos ficheros se encuentran en el mismo directorio y entonces ejecutar el siguiente comando para verificar la firma del fichero de distribución:
shell> gpg --verify package_name.asc
Ejemplo:
shell> gpg --verify mysql-standard-5.0.9-beta-linux-i686.tar.gz.asc gpg: Signature made Tue 12 Jul 2005 23:35:41 EST using DSA key ID 5072E1F5 gpg: Good signature from "MySQL Package signing key (www.mysql.com) <build@mysql.com>"
El mensaje Good signature
indica que todo
resultó correctamente. Puede ignorarse cualquier mensaje del
tipo insecure memory
que se obtenga.
No existe una firma por separado para paquetes RPM. Estos paquetes tienen incorporadas la firma GPG y la suma de verificación MD5. Para verificar un paquete RPM se utiliza el siguiente comando:
shell> rpm --checksig package_name.rpm
Ejemplo:
shell> rpm --checksig MySQL-server-5.0.9-0.i386.rpm MySQL-server-5.0.9-0.i386.rpm: md5 gpg OK
Nota: si está utilizando RPM
4.1 y emite mensajes de error del tipo (GPG) NOT OK
(MISSING KEYS: GPG#5072e1f5)
, aun cuando se haya
incorporado la clave pública dentro de las claves reconocidas
por el GPG (keyring), se necesitará importar primero la clave
pública dentro de las claves reconocidas (keyring) del RPM.
RPM 4.1 ya no utiliza las claves reconocidas (keyring)
personales (o GPG en sí mismo). En lugar de ello, mantiene su
propio repositorio de claves (keyring) ya que constituye una
aplicación a nivel de sistema, en tanto que el repositorio
público de claves (keyring) de GPG es un fichero específico
del usuario. Para importar la clave pública de MySQL dentro
del repositorio de claves (keyring) del RPM, primero debe
obtenerse la clave tal como se describe en la sección
anterior. A continuación debe utilizarse rpm
--import para importar la clave. Por ejemplo, si la
clave pública se encuentra en un fichero llamado
mysql_pubkey.asc
, se importa utilizando
el siguiente comando:
shell> rpm --import mysql_pubkey.asc
Para obtener la clave pública de MySQL, consulte:
Sección 2.1.4.2, “Verificación de firmas utilizando GnuPG
”.
Esta sección describe la conformación por defecto de los directorios creados por el instalador binario y por las distribuciones de código fuente provistas por MySQL AB. Si se instala una distribución obtenida de otro proveedor, esta conformación podría variar.
En MySQL 5.0 para Windows, el directorio de instalación por
defecto es C:\Program Files\MySQL\MySQL Server
5.0
. (Algunos usuarios de Windows prefieren realizar
la instalación en el antiguo directorio por defecto,
C:\mysql
. De todos modos, la conformación
de directorios permanece sin cambios). El directorio de
instalación contiene los siguientes subdirectorios:
Directorio | Contenido |
bin | Programas cliente y el servidor mysqld |
data | Ficheros de registro (logs), bases de datos |
Docs | Documentación |
examples | Programas y scripts de ejemplo |
include | Ficheros de inclusión |
lib | Bibliotecas |
scripts | Scripts de utilidades. |
share | Ficheros con mensajes de error |
Las instalaciones que se crean a partir de distribuciones RPM para Linux generadas por MySQL AB generan archivos bajo los siguientes directorios deL sistema:
Directorio | Contenido |
/usr/bin | Programas cliente y scripts |
/usr/sbin | El servidor mysqld |
/var/lib/mysql | Ficheros de registro (logs), bases de datos |
/usr/share/doc/packages | Documentación |
/usr/include/mysql | Ficheros de inclusión |
/usr/lib/mysql | Bibliotecas |
/usr/share/mysql | Ficheros con mensajes de error y conjuntos de caracteres |
/usr/share/sql-bench | Pruebas de rendimiento |
En Unix, un fichero binario de distribución
tar se instala descomprimiéndolo en la
ubicación que se escoja para la instalación (generalmente
/usr/local/mysql
) y crea los siguientes
directorios en dicha ubicación:
Directorio | Contenido |
bin | Programas cliente y el servidor mysqld |
data | Ficheros de registro (logs), bases de datos. |
docs | Documentación, registro de modificaciones. |
include | Ficheros de inclusión |
lib | Bibliotecas |
scripts | mysql_install_db |
share/mysql | Ficheros con mensajes de error |
sql-bench | Pruebas de rendimiento |
Una distribución de código fuente se instala después de
haberla configurado y compilado. Por defecto, la etapa de
instalación crea ficheros bajo /usr/local
,
en los siguientes subdirectorios:
Directorio | Contenido |
bin | Programas cliente y scripts |
include/mysql | Ficheros de inclusión |
info | Documentación en formato "Info" |
lib/mysql | Bibliotecas |
libexec | El servidor mysqld |
share/mysql | Ficheros con mensajes de error |
sql-bench | Pruebas de rendimiento y crash-me |
var | Bases de datos y ficheros de registro (logs) |
Dentro de su directorio de instalación, la conformación de una instalación de código fuente difiere de una binaria en los siguientes aspectos:
El servidor mysqld se instala en el
directorio libexec
en lugar de en el
directorio bin
.
El directorio para los datos es var
en
lugar de data
.
mysql_install_db se instala en el
directorio bin
en lugar de
scripts
.
Los directorios de ficheros de inclusión y bibliotecas son
include/mysql
y
lib/mysql
en lugar de
include
y lib
.
Se puede crear una instalación binaria propia a partir de una
distribución de código fuente compilada si se ejecuta el
script scripts/make_binary_distribution
desde el directorio principal de la distribución de código
fuente.
Las siguientes secciones cubren la instalación de MySQL en plataformas para las que se ofrecen paquetes que utilizan el formato de paquete de instalación respectivo de cada una. (Esto también es conocido como “instalación binaria”). Sin embargo, hay disponibles distribuciones binarias de MySQL para muchas otras plataformas. Consulte Sección 2.7, “Instalación de MySQL en otros sistemas similares a Unix” para encontrar instrucciones de instalación genéricas para estos paquetes que se aplican a todas las plataformas.
Consulte Sección 2.1, “Cuestiones generales sobre la instalación” para más información sobre otras distribuciones binarias y cómo conseguirlas.
Desde la versión 3.21, MySQL AB proporciona una versión Windows nativa de MySQL, que representa un apreciable porcentaje de las descargas diarias de MySQL. Esta sección describe el proceso para instalar MySQL en Windows.
El instalador para la versión Windows de MySQL 5.0, en conjunto con un asistente de configuración dotado de interfaz gráfica, instala automáticamente MySQL, crea un fichero de opciones, inicia el servidor, y otorga seguridad a las cuentas de usuario por defecto.
Si se está actualizando una instalación existente de MySQL anterior a la versión 4.1.5, deben observarse los siguientes pasos:
Obtener e instalar la distribución.
Establecer un fichero de opciones, de ser necesario.
Seleccionar el servidor que se desea emplear.
Iniciar el servidor.
Colocar contraseñas a las cuentas MySQL creadas inicialmente.
Este proceso también debe realizarse con instalaciones nuevas de MySQL, cuando el paquete de instalación no incluya un instalador.
MySQL 5.0 para Windows está disponible en tres formatos de distribución:
La distribución binaria contiene un programa de instalación que instala cada elemento necesario para iniciar el servidor inmediatamente.
La distribución de código fuente contiene todo el código y ficheros de soporte para generar ejecutables utilizando el compilador de VC++ 6.0
Siempre que sea posible debería emplearse la distribución binaria. Es más simple que las otras y no se necesita ninguna herramienta adicional para poner en funcionamiento el servidor MySQL.
Esta sección explica cómo instalar MySQL para Windows utilizando una distribución binaria. Para realizar la instalación a partir de una distribución de código fuente, consulte Sección 2.8.6, “Instalar MySQL desde el código fuente en Windows”.
Para ejecutar MySQL para Windows, se necesita lo siguiente:
Un sistema operativo Windows de 32 bits, tal como 9x, Me, NT, 2000, XP, o Windows Server 2003.
Se recomienda fuertemente el uso de un sistema operativo Windows basado en NT (NT, 2000, XP, 2003) puesto que éstos permiten ejecutar el servidor MySQL como un servicio. Consulte Sección 2.3.12, “Arrancar MySQL como un servicio de Windows”.
Soporte para protocolo TCP/IP.
Una copia de la distribución binara de MySQL para Windows, que se puede descargar de http://dev.mysql.com/downloads/. Consulte Sección 2.1.3, “Cómo obtener MySQL”.
Nota: Si se descarga la distribución a través de FTP, se recomienda el uso de un cliente FTP adecuado que posea la característica de reanudación (resume) para evitar la corrupción de ficheros durante el proceso de descarga.
Una herramienta capaz de leer ficheros
.zip
, para descomprimir el fichero de
distribución.
Suficiente espacio en disco rígido para descomprimir, instalar, y crear las bases de datos de acuerdo a sus requisitos. Generalmente se recomienda un mínimo de 200 megabytes.
También podrían necesitarse los siguientes ítems opcionales:
Si se planea conectarse al servidor MySQL a través de ODBC, se deberá contar con un driver Connector/ODBC. Consulte Sección 25.1, “MySQL Connector/ODBC”.
Si se necesitan tablas con un tamaño superior a 4GB, debe
instalarse MySQL en un sistema de ficheros NTFS o posterior.
Al crear las tablas no debe olvidarse el uso de
MAX_ROWS
y
AVG_ROW_LENGTH
. Consulte
Sección 13.1.5, “Sintaxis de CREATE TABLE
”.
En la versión 5.0 de MySQL hay tres paquetes de instalación para elegir cuando se instala MySQL para Windows. Son los siguientes:
El paquete Essentials:
Tiene un nombre de fichero similar a
mysql-essential-5.0.9-beta-win32.msi
y
contiene los ficheros mínimamente necesarios para instalar
MySQL en Windows, incluyendo el asistente de configuración.
Este paquete no incluye componentes opcionales como el
servidor incrustado (embedded) y el conjunto de pruebas de
rendimiento (benchmarks).
El paquete Complete
(Completo): Tiene un nombre de fichero similar a
mysql-5.0.9-beta-win32.zip
y contiene
todos los archivos necesarios para una instalación completa
bajo Windows, incluyendo el asistente de configuración.
Este paquete incluye componentes opcionales como el servidor
incrustado (embedded) y el conjunto de pruebas de
rendimiento (benchmarks).
El Paquete Noinstall (Noinstall
Archive): Tiene un nombre de fichero similar a
mysql-noinstall-5.0.9-beta-win32.zip
y
contiene todos los ficheros contenidos en el paquete
Complete, a excepción del asistente de configuración. Este
paquete no incluye un instalador automatizado, y debe ser
instalado y configurado manualmente.
El paquete Essentials es el recomendado para la mayoría de los usuarios.
El proceso de instalación que se siga depende del paquete de instalación escogido. Si se opta por instalar ya sea el paquete Complete o Essentials, consúltese Sección 2.3.3, “Instalación de MySQL con un instalador automático”. Si se opta por instalar MySQL a partir del paquete Noinstall, consúltese Sección 2.3.6, “Instalar MySQL partiendo de un archivo Zip Noinstall”.
Los usuarios nuevos de MySQL 5.0 pueden emplear el asistente de instalación y el asistente de configuración para instalar MySQL en Windows. Éstos están diseñados para instalar y configurar MySQL de tal forma que los usuarios nuevos pueden comenzar a utilizar MySQL inmediatamente.
Los asistentes de instalación y configuración se encuentran disponibles en los paquetes Essentials y Complete, y están recomendados para la mayoría de las instalaciones estándar de MySQL. Las excepciones incluyen a usuarios que necesitan implementar múltiples instancias de MySQL en un único servidor y a usuarios avanzados que desean un control completo de la configuración del servidor.
El asistente de instalación es un instalador para el servidor MySQL que emplea las últimas tecnologías de instalador para Microsoft Windows. El Asistente de Instalación de MySQL, en combinación con el asistente de configuración, le permite a un usuario instalar y configurar un servidor MySQL que esté listo para el uso inmediatamente a continuación de la instalación.
El asistente de instalación MySQL es el instalador estándar para todas las distribuciones del Servidor MySQL 5.0. Los usuarios de versiones anteriores de MySQL deberán detener y desinstalar sus servidores existentes antes de realizar una instalación con el asistente de instalación de MySQL. Consulte Sección 2.3.4.7, “Aumentar la versión MySQL” para más información acerca de actualizar una versión anterior.
Microsoft incluyó una versión mejorada de su Microsoft Windows Installer (Instalador de Microsoft Windows, MSI) en las versiones recientes de Windows. MSI se ha convertido en el estándar de facto para la instalación de aplicaciones bajo Windows 2000, Windows XP, y windows Server 2003. El asistente de instalación MySQL emplea esta tecnología para proporcionar un proceso de instalación más flexible y amigable.
El motor del instalador de Microsoft Windows fue actualizado en Windows XP; quienes utilicen una versión previa de Windows pueden remitirse a este artículo de la Base de Conocimiento de Microsoft para obtener información sobre cómo actualizar a la última versión de MSI.
Adicionalmente, Microsoft introdujo recientemente el conjunto de herramientas WiX (Instalador de Windows XML). Éste es el primer proyecto Open Source reconocido de Microsoft. Los desarrolladores de MySQL han optado por WiX porque es un proyecto Open Source y les permite manejar el proceso completo de instalación en Windows de una manera flexible, utilizando scripts.
Las mejoras al asistente de instalación MySQL dependen del soporte y comentarios recibidos de los usuarios. Si Usted descubre que el asistente de instalación está dejando de lado alguna característica que le resulte importante, o si halla un error, por favor emplee nuestro sistema de errores MySQL para solicitar características o informar sobre problemas.
Los paquetes de instalación del servidor MySQL pueden descargarse desde http://dev.mysql.com/downloads/. Si el paquete a descargar está contenido en un fichero ZIP, se deberá descomprimir el fichero antes.
El procedimiento para ejecutar el asistente de instalación
depende del contenido del paquete descargado. Si existe un
fichero setup.exe
o
.msi
, al hacerles doble click comenzará
la instalación.
Hay disponibles tres tipos de instalación: típica, completa, y personalizada.
La instalación típica instala el servidor MySQL, el cliente de línea de comandos mysql, y las utilidades de línea de comandos. Los clientes y utilidades incluyen mysqldump, myisamchk, y otras herramientas que ayudan a administrar el servidor MySQL.
La instalación completa instala todos los componentes incluidos en el paquete. El paquete completo incluye componentes como el servidor incrustado (embedded), el conjunto de pruebas de rendimiento (benchmarks), scripts de mantenimiento, y documentación.
La instalación personalizada otorga un control completo sobre los paquetes que se desea instalar y el directorio de instalación que se utilizará. Consulte Sección 2.3.4.4, “La ventana de diálogo de instalación personalizada” para más información sobre cómo llevar a cabo una instalación personalizada.
Si se escoge la instalación típica o la completa, al hacer click sobre el botón se avanza a la pantalla de confirmación para verificar las opciones y comenzar la instalación. Si se escoge la instalación personalizada, al hacer click sobre el botón , se avanza al cuadro de diálogo de instalación personalizada, descrito en Sección 2.3.4.4, “La ventana de diálogo de instalación personalizada”
Si se desea cambiar el directorio de instalación o los componentes que se instalarán, se deberá elegir el tipo de instalación personalizada.
Todos los componentes disponibles se encuentran en un diagrama de árbol en el lado izquierdo del cuadro de diálogo de instalación personalizada. Los componentes que no serán instalados tienen un icono X rojo; los componentes que se instalarán tienen un icono gris. Para indicar si un componente se instalará o no, debe hacerse click en su icono y elegir una opción de la lista desplegable que aparece.
Se puede cambiar el directorio de instalación por defecto haciendo click en el botón
a la derecha del directorio de instalación que se muestra.Después de elegir los componentes a instalar y el directorio de instalación, hacer click en el botón
hará avanzar al cuadro de diálogo de confirmación.Una vez que se elige un tipo de instalación y los componentes a instalar, se avanza al cuadro de diálogo de confirmación. Se muestran el tipo y el directorio de instalación se para ser confirmados.
Para instalar MySQL una vez que se está conforme con la configuración, debe hacerse click en el botón
. Para cambiar la configuración, debe hacerse click en el botón . Para abandonar el asistente de instalación sin terminar la instalación de MySQL, debe hacerse click en el botón .Una vez que la instalación está completa, se porporciona la opción de registrarse en el sitio web de MySQL. El registro otorga acceso para publicar mensajes en los foros de Mysql, en forums.mysql.com, junto con la posibilidad de informar errores en bugs.mysql.com y suscribirse al boletín electrónico. La pantalla final del instalador brinda un resumen de la instalación y la opción de ejecutar el asistente de configuración MySQL, que se utiliza para crear un fichero de configuración, instalar el servicio MySQL, y establecer la seguridad.
Una vez que se hace click en el botón
, el asistente de instalación MySQL comienza el proceso de instalación y realiza ciertos cambios en el sistema, que se describen en la siguiente sección.Cambios al Registro
El asistente de instalación crea una clave de registro,
durante una situación típica de instalación, localizada en
HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB
.
El asistente de instalación crea una clave cuyo nombre es el
número de versión principal (número de la serie) del
servidor que se encuentra instalado, tal como MySQL
Server 5.0
. Contiene dos valores de cadena,
Location
y Version
. La
cadena Location
contiene el directorio de
instalación. En una instalación corriente, contiene
C:\Program Files\MySQL\MySQL Server 5.0\
.
La cadena Version
contiene el número de
entrega (release). Por ejemplo, para una instalación de MySQL
Server 5.0.9 la clave contiene el valor
5.0.9
.
Estas claves del registro son útiles para ayudar a
herramientas externas a identificar la ubicación en la que se
instaló el servidor MySQL, evitando un rastreo completo del
disco para descubrirla. Las claves del registro no son
necesarias para la ejecución del servidor y no se crean
cuando se usa el fichero Zip noinstall
Cambios en el menú Inicio
El asistente de instalación crea una nueva entrada en el menú
de Windows, bajo una opción cuyo nombre es el número de versión principal (número de la serie) del servidor que se encuentra instalado. Por ejemplo, si se instala MySQL 5.0, se crea una sección en el menú .Se crean las siguientes entradas dentro de la nueva sección del menú
:
mysql y está configurado para iniciar
sesión como usuario root
. El atajo
pregunta por una contraseña perteneciente a un usuario
root
cuando se conecta.
: Es un atajo al asistente de configuración. Utilice este atajo para configurar un servidor recientemente instalado o reconfigurar uno existente.
: Es un vínculo a la documentación del servidor MySQL, que se almacena localmente en el directorio de instalación de MySQL. Esta opción no está disponible cuando el servidor MySQL fue instalado con el paquete Essentials.
Cambios en el sistema de ficheros
El asistente de instalación MySQL, por defecto instala el
servidor MySQL en C:\
, donde
Program
Files
\MySQL\MySQL Server
5.0
Program Files
es el directorio de
aplicaciones por defecto del sistema, y
5.0
es el número de versión
principal (número de la serie) de servidor MySQL instalado.
Ésta es la nueva ubicación donde se recomienda instalar
MySQL, en sustitución de la antigua ubicación por defecto,
c:\mysql
.
Por defecto, todas las aplicaciones MySQL se almacenan en un
directorio común localizado en
C:\
, donde
Program
Files
\MySQLProgram Files
es el directorio de
aplicaciones por defecto del sistema. Una instalación típica
de MySQL en el ordenador de un desarrollador podría verse
así:
C:\Program Files\MySQL\MySQL Server 5.0 C:\Program Files\MySQL\MySQL Administrator 1.0 C:\Program Files\MySQL\MySQL Query Browser 1.0
Esta proximidad entre los distintos directorios facilita la administración y el mantenimiento de todas las aplicaciones MySQL instaladas en un sistema en particular.
El asistente de instalación MySQL puede llevar a cabo actualizaciones del servidor automáticamente, empleando la capacidad de actualización de MSI. Ello significa que no es necesario desinstalar manualmente una versión previa antes de instalar una nueva entrega (release). El instalador, automáticamente, detiene y quita el servicio MySQL antiguo antes de instalar la nueva versión.
Las actualizaciones automáticas se hallan disponibles solamente cuando se actualiza entre instalaciones que tienen el mismo número de versión principal (número de la serie). Por ejemplo, se puede hacer una actualización automática desde MySQL 4.1.5 a MySQL 4.1.6, pero no desde MySQL 4.1 a MySQL 5.0.
Consulte Sección 2.3.15, “Aumentar la versión de MySQL en Windows”.
El asistente de configuración MySQL automatiza el proceso de
configurar el servidor bajo Windows. Crea un fichero
my.ini
personalizado, realizando una
serie de preguntas y aplicando las respuestas a una plantilla
para generar un fichero my.ini
apropiado
para la instalación en curso.
El asistente de configuración MySQL se incluye con la versión 5.0 de MySQL, y por el momento sólo está disponible para usuarios de Windows.
El asistente de configuración es en gran parte el resultado de los comentarios que MySQL AB recibió de muchos usuarios en un período de varios años. Sin embargo, si Usted descubre que el asistente de instalación está dejando de lado alguna característica que le resulte importante, o si halla un error, por favor emplee nuestro sistema de errores MySQL para solicitar características o informar sobre problemas.
El asistente de configuración generalmente se ejecuta a continuación del asistente de instalación, ni bien éste finaliza. También puede iniciarse haciendo click en la entrada
de la sección del menú .
Adicionalmente, es posible dirigirse al directorio
bin
de la instalación MySQL y ejecutar
directamente el fichero
MySQLInstanceConfig.exe
.
Si el asistente de configuración MySQL detecta un fichero
my.ini
preexistente, se tiene la opción
de reconfigurar el servidor o quitar la instancia borrando el
fichero my.ini
y deteniendo y quitando el
servicio MySQL.
Para reconfigurar un servidor existente, debe escogerse la
opción
my.ini
actual será renombrado
como
my
,
donde timestamp
.ini.baktimestamp
es la fecha y hora
en que el fichero my.ini
existente se
creó. Para quitar la instancia del servidor actual, debe
seleccionarse la opción
y hacer click en el botón .
Si se selecciona la opción
my.ini
. Los ficheros del servidor,
incluyendo el directorio data
, no se
eliminarán.
Si se opta por
, se continúa hacia el cuadro de diálogo donde puede elegirse el tipo de instalación a configurar.Cuando se inicia el asistente de configuración MySQL para una instalación nueva o se escoge la opción
para una configuración existente, se avanza hacia el cuadro de diálogo .Hay disponibles dos tipos de configuración:
y . La está orientada a usuarios nuevos que deseen comenzar rápidamente con MySQL sin tener que tomar varias decisiones relativas a la configuración del servidor. La está dirigida a usuarios avanzados que deseen un control más preciso sobre la configuración del servidor.Si se trata de un usuario nuevo de MySQL y necesita un servidor configurado para un ordenador de desarrollo con un único usuario, la
debería cubrir sus necesidades. Al elegir la el asistente de configuración MySQL establece todas las opciones de configuración automáticamente, a excepción de y .La
establece opciones que pueden ser incompatibles con sistemas donde existen instalaciones de MySQL previas. Si se posee una instalación de MySQL anterior además de la que se está configurando, se recomienda optar por laPara completar la Sección 2.3.5.11, “La ventana de diálogo de las opciones de servicio” y Sección 2.3.5.12, “La ventana de diálogo de las opciones de seguridad”, respectivamente.
, hay que remitirse a las secciones sobre y , enHay tres tipos de servidor distintos para elegir, y el tipo que se escoja afectará a las decisiones que el asistente de configuración MySQL tomará en relación al uso de memoria, disco y procesador.
: Esta opción se aplica a ordenadores de escritorio donde MySQL está orientado a un uso personal solamente. Se asume que se estarán ejecutando varias otras aplicaciones, por lo que el servidor MySQL se configura para utilizar una cantidad mínima de recursos del sistema.
: Esta opción se aplica a servidores donde MySQL se ejecuta junto con otras aplicaciones de servidor como son FTP, correo electrónico, y servidores web. MySQL se configura para utilizar una cantidad moderada de recursos del sistema.
: Esta opción se aplica a ordenadores donde solamente se ejecuta el servidor MySQL. Se asume que no hay otras aplicaciones ejecutándose. El servidor MySQL se configura para utilizar todos los recursos disponibles en el sistema.
El cuadro de diálogo InnoDB
estará disponible y
qué porcentaje de los recursos de servidor estarán
disponibles para InnoDB
InnoDB
como MyISAM
y
reparte los recursos uniformemente entre ambos. Se
recomienda para usuarios que emplearán los dos motores de
almacenamiento en forma habitual.
InnoDB
como MyISAM
,
pero destina más recursos del servidor al motor
InnoDB
. Se recomienda para usuarios que
emplearán InnoDB
casi exclusivamente,
y harán un uso mínimo de MyISAM
InnoDB
y destina todos
los recursos del servidor al motor
MyISAM
. Recomendado para usuarios que
no utilizarán InnoDB
.
Algunos usuarios pueden querer ubicar los ficheros
InnoDB
en una ubicación diferente al
directorio de datos del servidor MySQL. Esto puede ser
deseable si el sistema tiene disponible un dispositivo de
almacenamiento con mayor capacidad o mayor rendimiento, como
un sistema RAID.
Para modificar la ubicación por defecto de los ficheros
InnoDB
, debe elegirse una nueva unidad de
disco en la lista desplegable de letras de unidades y elegir
una nueva ruta en la lista desplegable de rutas. Haciendo
click en el botón podrá crearse
una ruta personalizada,
Si se está modificando la configuración de un servidor preexistente, debe hacerse click en el botón
antes de cambiar la ruta. En dicho caso habrá que desplazar manualmente los ficheros InnoDB existentes hacia la nueva ubicación antes de iniciar el servidor.Es importante establecer un límite para las conexiones simultáneas que se podrán establecer con el servidor MySQL, para evitar que éste se quede sin recursos. El cuadro de diálogo
permite indicar el uso que se planea darle al servidor, y establecer en consecuencia el límite de conexiones simultáneas. También es posible introducir manualmente el límite.: Debe escogerse esta opción si el servidor no necesitará una gran cantidad de conexiones simultáneas. El número máximo de conexiones se establece en 100, asumiéndose un promedio de 20 conexiones simultáneas.
: Debe escogerse esta opción si el servidor necesitará un gran número de conexiones simultáneas. El número máximo de conexiones se establece en 500.
: Debe escogerse esta opción para establecer manualmente el número máximo de conexiones simultáneas que admitirá el servidor. El número deseado puede elegirse de una lista desplegable o teclearse si no figura en ella.
El cuadro de diálogo
permite activar o desactivar el protocolo TCP/IP y modificar el número de puerto por el que se accederá al servidor MySQL.El protocolo TCP/IP está activado por defecto. Para desactivarlo debe quitarse la marca de la casilla al lado de la opción
Por defecto se utiliza el puerto 3306 para acceder a MySQL. Para modificar este valor, el número deseado puede elegirse de una lista desplegable o teclearse si no figura en la lista. Si el puerto indicado ya se encuentra en uso, se solicitará la confirmación de la elección.
El servidor MySQL soporta múltiples conjuntos de caracteres, y es posible establecer uno por defecto, que se aplicará a todas las tablas, columnas y bases de datos, a menos que se sustituya. Debe emplearse el cuadro de diálogo
para cambiar en el servidor el conjunto de caracteres por defecto.
Latin1
como el juego de caracteres por defecto en el servidor.
Latin1
se usa para el Inglés y muchos
idiomas de Europa Occidental.
UTF8
como el
conjunto de caracteres por defecto en el servidor.
UTF8
puede almacenar caracteres de
muchos idiomas diferentes en un único juego.
: Esta opción se emplea cuando se desea elegir manualmente el juego de caracteres por defecto del servidor, a través de una lista desplegable.
En plataformas basadas en Windows NT, el servidor MySQL puede instalarse como un servicio. De ese modo, se iniciará automáticamente durante el inicio del sistema, e incluso será reiniciado automáticamente por Windows en caso de producirse un fallo en el servicio.
El asistente de configuración MySQL instala por defecto el
servidor MySQL como un servicio, utilizando el nombre de
servicio MySQL
. Si se desea evitar la
instalación del servicio, debe vaciarse la casilla al lado de
la opción
. Se puede modificar el nombre del servicio eligiendo un nuevo
nombre o tecleándolo en la lista desplegable provista.
Para instalar el servidor MySQL como un servicio pero que no se ejecute al iniciarse Windows, debe vaciarse la casilla al lado de la opción
.
Se recomienda fuertemente que se establezca una contraseña
para el usuario root
del servidor MySQL. El
asistente de configuración MySQL la solicita por defecto. Si
no se desea establecer una contraseña, debe vaciarse la
casilla al lado de la opción
.
Para establecer la contraseña del usuario
root
, se debe introducir tanto en el cuadro
de texto
como en
. Si se está reconfigurando un servidor existente, también
será necesario introducir la contraseña en vigencia dentro
del cuadro de texto
.
Para evitar que el usuario root
inicie
sesión desde cualquier punto de la red, debe marcarse la
casilla al lado de la opción
. Esto fortalece la seguridad de la cuenta de
root
.
Para crear una cuenta de usuario anónimo, debe marcarse la casilla al lado de la opción
. No se recomienda crear un usuario anónimo porque puede disminuir la seguridad del servidor y ocasionar dificultades de inicio de sesión y de permisos.El último cuadro de diálogo del asistente de configuración MySQL es el de
. Para concretar el proceso de configuración, debe hacerse click en el botón . Para volver a un cuadro de diálogo anterior, debe hacerse click en el botón . Para abandonar el asistente de configuración sin cambiar la configuración del servidor, debe hacerse click en el botón .Después de hacer click en el botón
, el asistente de configuración MySQL llevará a cabo una serie de tareas cuyo avance se mostrará en la pantalla a medida que cada etapa termine.
El asistente de configuración MySQL determina en primer lugar
las opciones del fichero de configuración, basándose en las
preferencias del usuario, y empleando una plantilla
confeccionada por desarrolladores e ingenieros de MySQL AB.
Esta plantilla se llama my-template.ini
y
se localiza en el directorio de instalación del servidor.
Luego, el asistente de configuración guarda dichas opciones
en el fichero my.ini
. La ubicación final
de este fichero se muestra al lado de la tarea
Guardar fichero de configuración (Write
configuration file).
Si se optó por crear un servicio de Windows para el servidor MySQL, el asistente de configuración creará e iniciará el servicio. Si se está reconfigurando un servicio existente, el asistente de configuración reiniciará el servicio para que tomen efecto los cambios realizados.
Si se optó por establecer una contraseña para el usuario
root
, el asistente de configuración MySQL
se conectará al servidor, establecerá la nueva contraseña
para root
, y aplicará cualquier otra
opción de seguridad que se haya seleccionado.
Después de que el asistente de configuración MySQL haya completado sus tareas, se mostrará un resumen. Haciendo click en el botón
se abandonará el asistente.
El asistente de configuración MySQL coloca el fichero
my.ini
en el directorio de instalación
del servidor MySQL. De este modo se asocian los ficheros de
configuración con distintas instancias del servidor.
Para asegurarse de que el servidor MySQL sabe dónde buscar el
fichero my.ini
, durante la instalación
del servicio se pasa al servidor un argumento similar a este:
--defaults-file="
,
donde C:\Program
Files\MySQL\MySQL Server 5.0
\my.ini"C:\Program Files\MySQL\MySQL Server
5.0
se reemplaza con la ruta de instalación del
servidor MySQL.
--defaults-file
le indica al servidor MySQL
que lea el fichero especificado en busca de opciones de
configuración.
Para modificar el fichero my.ini
, se debe
abrir con un editor de texto y realizar cualquier cambio
necesario. También se puede modificar con la utilidad
MySQL
Administrator
Los programas cliente y las utilidades de MySQL, como el
cliente de línea de comandos mysql y
mysqldump, no son capaces de localizar el
fichero my.ini
ubicado en el directorio
de instalación del servidor. Para configurar las aplicaciones
cliente y de utilidades, debe crearse un nuevo fichero
my.ini
en el directorio
C:\Windows
o
C:\WINNT
, según corresponda a la
versión de Windows que se esté ejecutando.
Los usuarios que hayan optado por instalar desde el paquete Noinstall, pueden servirse de las instrucciones en esta sección para instalar manualmente MySQL. El proceso para instalar MySQL desde un fichero ZIP es el siguiente:
Extraer el contenido del fichero dentro del directorio de instalación deseado.
Crear un fichero de opciones.
Elegir un tipo de servidor MySQL
Iniciar el servidor MySQL.
Establecer la seguridad de las cuentas de usuario por defecto.
El proceso completo se describe en las secciones siguientes.
Para instalar MySQL manualmente, debe hacerse lo siguiente:
Si se está actualizando desde una versión anterior, se debe consultar Sección 2.3.15, “Aumentar la versión de MySQL en Windows” antes de comenzar el proceso de actualización.
Si se está utilizando un sistema operativo basado en Windows NT, como Windows NT, Windows 2000, Windows XP o Windows Server 2003, se debe iniciar sesión con un usuario con privilegios de administrador.
Debe elegirse una ubicación para la instalación.
Tradicionalmente, el servidor MySQL se ha venido colocando
en C:\mysql
, y el asistente de
instalación lo hace en C:\Program
Files\MySQL
. Si no se instala en
C:\mysql
, se debe indicar el directorio
de instalación al iniciar el servidor o en un fichero de
opciones. Consulte
Sección 2.3.8, “Creación de un fichero de opciones”.
Utilizando una aplicación capaz de expandir ficheros comprimidos, se debe extraer el contenido del paquete dentro de la ubicación elegida para la instalación. Algunas aplicaciones extraen el contenido del fichero dentro de una carpeta que crean en la ubicación que se les indica. Si este es el caso, debe moverse el contenido de dicha subcarpeta y colocarlo en la ubicación elegida.
Si es necesario especificarle opciones al servidor durante su inicio, esto puede hacerse desde la línea de comandos o bien colocando las opciones en un fichero de opciones. Aquellas opciones que se usarán cada vez que se inicie el servidor, es conveniente colocarlas en un fichero. Esto es especialmente cierto en las siguiente circunstancias:
El directorio de instalación o de datos son diferentes de
los usados por defecto (C:\Archivos de
Programa\MySQL\MySQL Server 5.0
y
C:\Archivos de Programa\MySQL\MySQL Server
5.0\data
).
Es necesario afinar la configuración del servidor
Cuando el servidor MySQL para Windows se inicia, busca opciones
en dos ficheros: en my.ini
en el directorio
de Windows, y en C:\my.cnf
. El directorio
de Windows generalmente es C:\WINDOWS
o
C:\WINNT
. Se puede verificar el valor
exacto consultando la variable de entorno
WINDIR
por medio del siguiente comando:
C:\> echo %WINDIR%
MySQL buscará opciones primero en el fichero
my.ini
y luego en
my.cnf
. Sin embargo, para evitar
confusiones, es mejor emplear un solo fichero. Si el ordenador
utiliza un gestor de arranque donde C:
no
es la unidad de inicio, la única opción será
my.ini
. Cualquiera que sea el fichero de
opciones empleado, deberá estar en texto plano.
Otra posibilidad es utilizar como base los ficheros de opciones
incluidos como ejemplo en la distribución de MySQL. Éstos se
encuentran en el directorio de instalación y tienen nombres
como my-small.cnf
,
my-medium.cnf
,
my-large.cnf
, y
my-huge.cnf
. Para utilizarlos como base de
la configuración basta renombrarlos y copiarlos en la
ubicación apropiada.
Un fichero de opciones puede crearse y modificarse con cualquier
editor de textos, como el Bloc de Notas o Notepad. Por ejemplo,
si MySQL está instalado en E:\mysql
y el
directorio de datos es E:\mydata\data
, se
puede crear un fichero de opciones que contenga una sección
[mysqld]
para especificar los valores que
tendrán los parámetros basedir
y
datadir
:
[mysqld] # coloca en basedir el directorio de instalación basedir=E:/mysql # coloca en datadir el directorio de datos datadir=E:/mydata/data
Debe tenerse en cuenta que las rutas de directorio, aun en Windows, deben escribirse en los ficheros de opciones con barras invertidas (/) en lugar de las habituales. Si se desea emplear estas últimas, deben colocarse en forma doble:
[mysqld] # coloca en basedir el directorio de instalación basedir=E:\\mysql # coloca en datadir el directorio de datos datadir=E:\\mydata\\data
En Windows, el instalador de MySQL coloca el directorio de datos
directamente bajo el directorio donde se instala MySQL. Si se
deseara tener el directorio de datos en una ubicación
diferente, se debería copiar el contenido completo del
directorio data
en la nueva ubicación. Por
ejemplo, si MySQL se instala en C:\Program
Files\MySQL\MySQL Server 5.0
, el directorio de datos
estará por defecto en C:\Program Files\MySQL\MySQL
Server 5.0\data
. Si se quiere que el directorio de
datos sea E:\mydata
deben hacerse dos
cosas:
Desplazar el directorio data y todo su contenido desde
C:\Program Files\MySQL\MySQL Server
5.0\data
hasta E:\mydata
.
Emplear la opción --datadir
para
especificar la nueva ubicación del directorio data cada vez
que se inicia el servidor.
La siguiente tabla muestra los servidores MySQL 5.0 disponibles para Windows:
Ejecutable | Descripción |
mysqld-debug | Compilado con el máximo de funciones de depuración y control
automático de asignación de memoria, así como con
soporte para tablas InnoDB y
BDB . |
mysqld | Ejecutable optimizado con soporte para InnoDB |
mysqld-nt | Ejecutable optimizado para Windows NT, 2000, y XP con soporte para named pipes. |
mysqld-max | Ejecutable optimizado con soporte para tablas InnoDB
y BDB . |
mysqld-max-nt | Similar a mysqld-max, pero compilado con soporte para named pipes. |
Todos los ejecutables mencionados están optimizados para los modernos procesadores Intel, pero deberían funcionar en cualquier procesador Intel de tipo i386 o superior.
En MySQL 5.0, todos los servidores Windows tienen soporte para vínculo simbólico de directorios de bases de datos.
MySQL tiene soporte para TCP/IP en todas las plataformas
Windows. Los servidores mysqld-nt y
mysql-max-nt
tienen soporte para named pipes
en Windows NT, 2000, XP y 2003. Sin embargo, lo habitual es
emplear TCP/IP sin tener en cuenta la plataforma. (Las named
pipes son más lentas que TCP/IP en muchas configuraciones de
Windows).
El uso de named pipes está sujeto a estas condiciones:
Las named pipes están habilitadas solamente si se inicia el
servidor con la opción
--enable-named-pipe
. Esto es necesario
porque algunos usuarios han experimentado problemas al
detener el servidor MySQL cuando las estaban utilizando.
Las conexiones con named pipes están permitidas solamente en los servidores mysqld-nt o mysqld-max-nt, y siempre que la versión de Windows utilizada las soporte (Windows NT, 2000, XP, 2003).
Estos servidores pueden ejecutarse en Windows 98 o Me, pero sólo si el protocolo TCP/IP está instalado; las conexiones con named pipe no pueden utilizarse.
Estos servidores no pueden ejecutarse en Windows 95.
Nota: la mayor parte de los ejemplos de este manual emplean mysqld como nombre de servidor. Si se opta por emplear un servidor diferente, como mysqld-nt, deben hacerse los reemplazos de nombre adecuados en los comandos de los ejemplos.
La información de esta sección se aplica principalmente si se
está instalando MySQL con la versión
Noinstall
, o si se desea configurar y probar
MySQL manualmente en lugar de usar las herramientas con interfaz
gráfica.
En Windows 95, 98, o Me, los clientes MySQL siempre se conectan al servidor utilizando TCP/IP. (Esto le permite a cualquier ordenador de la red conectarse al servidor MySQL). Debido a esto, hay que asegurarse de que TCP/IP esté soportado en el ordenador antes de iniciar MySQL. El protocolo TCP/IP se encuentra en el CD-ROM de Windows.
Es importante advertir de que si se está utilizando una versión antigua de Windows 95 (por ejemplo, OSR2), es muy probable que se disponga de un paquete Winsock antiguo; MySQL necesita Winsock 2. Puede descargarse el último paquete Winsock desde http://www.microsoft.com/. Windows 98 ya tiene la nueva biblioteca Winsock 2, de modo que no es necesario actualizarla.
En sistemas basados en NT, como Windows NT, 2000, XP, o 2003, los clientes tienen dos opciones. Pueden utilizar TCP/IP, o utilizar conexiones con named pipe si están soportadas por el servidor. Para lograr que MySQL trabaje con TCP/IP cuando se usa Windows NT 4, debe instalarse el service pack 3 (o posterior).
MySQL 5.0 para Windows también soporta conexiones de memoria
compartida (shared-memory) si se lo inicia con la opción
--shared-memory
. Los clientes pueden
conectarse a través de memoria compartida (shared memory) si
usan la opción --protocol=memory
.
Para más información sobre qué servidor ejecutar, consulte Sección 2.3.9, “Seleccionar un tipo de servidor MySQL”.
Esta sección brinda una visión de conjunto del arranque del servidor MySQL. Las siguientes secciones proporcionan información más específica para ejecutar el servidor MySQL desde la línea de comandos o como un servicio de Windows.
Los ejemplos de estas secciones asumen que MySQL está instalado
en la ubicación por defecto: C:\Program
Files\MySQL\MySQL Server 5.0
. Las rutas de directorio
mostradas en los ejemplos deben modificarse si MySQL está
instalado en una ubicación diferente.
Las pruebas se realizan mejor desde el indicador del sistema en una ventana de consola (o “ventana DOS”). De este modo, los mensajes mostrados por el servidor permanecen en la ventana, donde son más sencillos de leer. Si algo funciona mal en la configuración, estos mensajes facilitan la identificación y solución de los problemas.
Para iniciar el servidor, se emplea este comando:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld --console
En servidores que incluyen soporte para
InnoDB
, se deberían mostrar los siguientes
mensajes a medida que el servidor se inicia:
InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist: InnoDB: a new database to be created! InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200 InnoDB: Database physically writes the file full: wait... InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280 InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: creating foreign key constraint system tables InnoDB: foreign key constraint system tables created 011024 10:58:25 InnoDB: Started
Cuando el servidor finaliza su secuencia de inicio, se debería ver un mensaje similar al siguiente, que indica que el servidor está listo para dar servicio a conexiones de clientes:
mysqld: ready for connections Version: '5.0.9-beta' socket: '' port: 3306
El servidor continúa con la emisión por pantalla de cualquier otro mensaje de diagnóstico que se genere. Puede abrirse una nueva ventana de consola en la cual ejecutar programas cliente.
Si se omite la opción --console
, el servidor
dirige la información de diagnóstico hacia el registro de
errores en el directorio de datos (por defecto,
C:\Program Files\MySQL\MySQL Server
5.0\data
). El registro de errores es el fichero con
extensión .err
.
Nota: Las cuentas de usuario que aparecen inicialmente en las tablas de permisos de MySQL no están protegidas por contraseña. Después de iniciar el servidor, se deberían establecer las contraseñas para estas cuentas empleando las instrucciones que se hallan en Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
El servidor MySQL puede ser iniciado manualmente desde la línea de comandos. Esto es válido en cualquier versión de Windows.
Para iniciar el servidor mysqld desde la línea de comandos, se debería abrir una ventana de consola (o “ventana DOS ”) e ingresar este comando:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld
La ruta empleada en el ejemplo anterior puede variar según la ubicación de la instalación de MySQL en el sistema.
En versiones no NT de Windows, esto ejecutará mysqld en segundo plano. Esto significa que luego de que el servidor se inicia, puede verse otra ventana de comandos. Si se inicia el servidor de esta manera pero en Windows NT, 2000, XP o 2003, el mismo se ejecuta en segundo plano sin que aparezca ningún indicador del sistema hasta que el servidor finaliza. Debido a esto, se deberá abrir otra ventana de consola para correr programas cliente mientras el servidor se ejecuta.
El siguiente comando detendrá al servidor MySQL:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqladmin -u root shutdown
Esto invoca la utilidad administrativa de MySQL,
mysqladmin, para conectarse al servidor y
transmitirle la orden de finalización. El comando se conecta
como el usuario root
de MySQL, el cual es la
cuenta administrativa por defecto en el sistema de permisos de
MySQL. Debe advertirse que los usuarios en este sistema son
enteramente independientes de cualquier usuario de inicio de
sesión perteneciente a Windows.
Si mysqld no se inicia, debe verificarse el
registro de errores para ver si el servidor generó cualquier
mensaje que indique la causa del problema. El registro de
errores se localiza en el directorio C:\Program
Files\MySQL\MySQL Server 5.0\data
. Es el fichero con
extensión .err
. También puede intentarse
iniciar el servidor con el comando mysqld
--console; en este caso se podrá obtener alguna
información en pantalla que permita resolver el problema.
La última opción es ejecutar mysqld con
--standalone --debug
. En este caso,
mysqld guardará un fichero de registro
llamado C:\mysqld.trace
el cual debería
contener la razón por la cual mysqld no se
inicia. Consulte Sección D.1.2, “Crear ficheros de traza”.
El comando mysqld --verbose --help sirve para mostrar todas las opciones que mysqld es capaz de comprender.
En la familia NT (Windows NT, 2000, XP, 2003), la manera recomendada de ejecutar MySQL es instalarlo como un servicio del sistema operativo, de modo que se inicie y detenga automáticamente cuando Windows lo haga. Un servidor MySQL instalado como servicio también puede controlarse desde la línea de comandos empleando los comandos NET, o con la utilidad gráfica Services.
La utilidad Services (el Administrador de Servicios de Windows (Service Control Manager)) puede encontrarse en el Panel de Control (bajo en Windows 2000, XP, y Server 2003). Es aconsejable cerrar la utilidad Services mientras se lleven a cabo operaciones de instalación o remoción del servidor desde la línea de comandos. Esto evita una cantidad de errores.
Antes de instalar MySQL como un servicio Windows, se debería detener primero el servidor -si está en ejecución- mediante el siguiente comando:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqladmin -u root shutdown
Nota: si la cuenta de usuario
MySQL root
está protegida por una
contraseña, la forma de invocar este comando será
C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqladmin
-u root -p shutdown y porporcionando la contraseña
cuando sea solicitada.
Esto invoca la utilidad administrativa de MySQL,
mysqladmin, para conectarse al servidor y
transmitirle la orden de finalización. El comando se conecta
como el usuario root
de MySQL, el cual es la
cuenta administrativa por defecto en el sistema de permisos de
MySQL. Debe advertirse que los usuarios en este sistema son
enteramente independientes de cualquier usuario de inicio de
sesión perteneciente a Windows.
Este comando instalará el servidor como un servicio:
C:\> mysqld --install
Si se producen problemas al instalar mysqld como un servicio usando sólo el nombre del servidor, debe intentarse indicando la ruta completa. Por ejemplo:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld --install
La ruta al directorio bin
de MySQL puede
agregarse a la variable de entorno de Windows
PATH
:
En el Escritorio de Windows, hacer click derecho en el ícono Mi PC y seleccionar
A continuación, seleccionar la pestaña
de la ventana , y hacer click en el botón .Bajo Variables del Sistema, seleccionar , y hacer click en el botón . Aparecerá el cuadro de diálogo .
Debe colocarse el cursor al final del texto mostrado en el
espacio denominado Valor de la
Variable. (Presionando la tecla Fin
(End) se puede tener seguridad que el cursor
quede realmente al final del texto.) Luego debe ingresarse
la ruta completa al directorio bin
de
MySQL (por ejemplo, C:\Program Files\MySQL\MySQL
Server 5.0\bin
). Si había un texto anterior,
debe haber un punto y coma separando aquel y esta nueva
ruta. Cerrar todos los cuadros de diálogo haciendo click
en . Ahora debería poderse
invocar cualquier programa ejecutable de MySQL simplemente
tipeando su nombre en el indicador de sistema desde
cualquier directorio, sin tener que indicar la ruta
completa. Esto incluye a los servidores, el cliente
mysql, y todas las utilidades de línea
de comandos tal como mysqladmin y
mysqldump.
No se debería agregar el directorio
bin
de MySQL al
PATH
de Windows si se están ejecutando
múltiples servidores MySQL en el mismo ordenador.
Advertencia: debe tenerse mucho
cuidado al editar manualmente la variable de sistema
PATH
; el borrado o modificación accidental
de cualquier parte podría dejar al sistema funcionando mal o
incluso inutilizable.
El comando de instalación como servicio no inicia el servidor. Las instrucciones para hacerlo se dan luego en esta sección.
MySQL 5.0 soporta argumentos adicionales cuando se lo instala como servicio:
Puede indicarse un nombre para el servicio inmediatamente a
continuación de la opción --install
. El
nombre por defecto es MySQL
.
Si se indica un nombre de servicio, solamente puede
especificarse una opción a continuación. Por convención,
esta debería ser
--defaults-file=
para indicar el nombre de un fichero de opciones
que el servidor debería leer cuando se inicia.
file_name
Es posible emplear otra opción en vez de
--defaults-file
, pero no se recomienda.
--defaults-file
es más flexible porque
posibilita especificar múltiples opciones de inicio para el
servidor, colocándolas en el fichero indicado. Además, en
MySQL 5.0, el uso de una opción diferente a
--defaults-file
no está soportado hasta
la versión 5.0.3.
A partir de la versión 5.0.1, puede especificarse la
opción --local-service
a continuación
del nombre del servicio. Esto provoca que el servidor se
ejecute empleando la cuenta LocalService
de Windows, que tiene privilegios de sistema limitados. Esta
cuenta existe solamente en Windows XP y posteriores. Si
ambas opciones --defaults-file
y
--local-service
son colocadas a
continuación del nombre del servicio, pueden estar en
cualquier orden.
Para un servidor MySQL que se instaló como un servicio de Windows, las siguientes reglas determinan el nombre de servicio y los ficheros de opciones que utilizará:
Si el comando de instalación como servicio no especificó
un nombre de servicio o el nombre por defecto
(MySQL
) a continuación de la opción
--install
, el servidor tomará el nombre
de servicio MySQL
y leerá opciones desde
el grupo [mysqld]
en los ficheros de
opciones estándar.
Si el comando de instalación como servicio especifica un
nombre de servicio distinto a MySQL
luego
de la opción --install
, el servidor
empleará ese nombre de servicio. Leerá opciones en el
grupo que tenga el mismo nombre que el servicio, en los
ficheros de opciones estándar.
El servidor también leerá opciones desde el grupo
[mysqld]
de los ficheros de opciones
estándar. Esto permite usar el grupo
[mysqld]
para opciones que deban ser
utilizadas por todos los servicios MySQL, y un grupo de
opciones con el mismo nombre del servicio para ser usadas
sólo por aquel.
Si el comando de instalación del servicio especifica una
opción --defaults-file
después del
nombre del servicio, el servidor leerá opciones solamente
desde el grupo [mysqld]
del fichero
suministrado e ignorará los ficheros de opciones estándar.
A modo de un ejemplo más complejo, considérese el siguiente comando:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld --install MySQL --defaults-file=C:\my-opts.cnf
Aquí, el nombre de servicio por defecto
(MySQL
) se suministró a continuación de la
opción --install
. Si no se hubiera indicado
la opción --defaults-file
, este comando
hubiese tenido como efecto que el servidor leyera el grupo
[mysqld]
de los ficheros de opciones
estándar. No obstante, debido a que la opción
--defaults-file
se encuentra presente, el
servidor leerá las opciones del grupo
[mysqld]
, pero sólo del fichero indicado.
También es posible especificar opciones como Parámetros de Inicio (Start parameters) en la utilidad Services de Windows antes de iniciar el servicio MySQL.
Una vez que el servidor MySQL ha sido instalado como servicio, será iniciado automáticamente luego del arranque de Windows. El servicio también puede iniciarse desde la utilidad Services, o empleando el comando NET START MySQL. El comando NET no es case sensitive.
Cuando se ejecuta como servicio, mysqld no
tiene acceso a una ventana de consola, por lo que no puede
mostrar mensajes. Si mysqld no se inicia,
debe consultarse el registro de errores para ver si el servidor
ha dejado allí mensajes que indiquen la causa del problema. El
registro de errores se encuentra en el directorio de datos de
MySQL (por ejemplo, C:\Program Files\MySQL\MySQL
Server 5.0\data
). Es el fichero con extensión
.err
.
Cuando un servidor MySQL se instala como servicio, se detendrá
automáticamente si estaba en ejecución al momento de cerrar
Windows. También puede detenerse manualmente, ya sea a través
de la utilidad Services
, del comando
NET STOP MySQL, o del comando
mysqladmin shutdown.
También existe la opción de instalar el servidor como un
servicio de inicio manual, si no se desea que el servicio se
inicie en cada arranque de Windows. Para esto, debe emplearse la
opción --install-manual
en lugar de
--install
:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld --install-manual
Para cancelar un servidor que fue instalado como servicio,
primero se lo debe detener, si está en ejecución, por medio
del comando NET STOP MYSQL. Luego de esto se
usará la opción --remove
para cancelarlo:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld --remove
Si mysqld no se está ejecutando como un servicio, se lo puede iniciar desde la línea de comandos. Consulte Sección 2.3.11, “Arrancar MySQL desde la raya de comandos de Windows” para más instrucciones.
Consulte Sección 2.3.14, “Resolución de problemas en la instalación de MySQL bajo Windows” si se producen problemas durante la instalación.
Cualquiera de los siguientes comandos permitirá comprobar si el servidor MySQL está en funcionamiento:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqlshow C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqlshow -u root mysql C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqladmin version status proc C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysql test
Si mysqld responde con lentitud a las
conexiones TCP/IP provenientes de programas cliente,
probablemente haya un problema con el DNS. En este caso, hay que
iniciar mysqld con la opción
--skip-name-resolve
y utilizar solamente
localhost
y números de IP en la columna
Host
de las tablas de permisos de MySQL.
Puede forzarse a un cliente MySQL a utilizar una conexión named
pipe en lugar de TCP/IP especificando la opción
--pipe
o --protocol=PIPE
,
o indicando .
(punto) como nombre de host. La
opción --socket
se utilizará para
especificar el nombre del pipe.
Cuando se instala y ejecuta MySQL por primera vez, es posible encontrar ciertos errores que evitan el inicio del servidor. El propósito de esta sección es brindar auxilio en el diagnóstico y corrección de algunos de estos errores.
El primer recurso a considerar durante la resolución de
problemas en el servidor es el registro de errores. El servidor
MySQL utiliza este registro para guardar información relevante
acerca del error que está impidiendo su inicio. El registro de
errores se encuentra en el directorio de datos especificado en
el fichero my.ini
. La ubicación por
defecto es C:\Program Files\MySQL\MySQL Server
5.0\data
. Consulte Sección 5.10.1, “El registro de errroes (Error Log)”.
Otra fuente de información relativa a posibles errores son los mensajes mostrados en la consola cuando el servicio MySQL se está iniciando. Empleando el comando NET START mysql en la línea de comandos luego de isntalar mysqld como un servicio, se podrá ver cualquier mensaje de error relativo al inicio del servicio MySQL. Consulte Sección 2.3.12, “Arrancar MySQL como un servicio de Windows”.
A continuación se brindan ejemplos de algunos de los más comunes errores que pueden ocurrir cuando se instala MySQL y se inicia el servidor por primera vez:
System error 1067 has occurred. Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist
Este mensaje se emite cuando el servidor MySQL no puede
encontrar la base de datos mysql
u otros
ficheros vitales para su funcionamiento. A menudo sucede
cuando el directorio base o el directorio de datos de MySQL
se instalan en ubicaciones distintas a las predeterminadas
(C:\mysql
y C:\Program
Files\MySQL\MySQL Server 5.0\data
,
respectivamente).
Una situación en la que puede ocurrir esto es cuando se instala una actualización de MySQL en una nueva ubicación, pero el fichero de configuración no se modifica para reflejar el nuevo directorio. Accesoriamente puede suceder que haya ficheros de configuración antiguos y nuevos en conflicto. Al actualizar MySQL hay que asegurarse de borrar o renombrar los ficheros de configuración existentes.
Si se ha instalado MySQL en un directorio diferente a
C:\Program Files\MySQL\MySQL Server 5.0
es necesario asegurarse de que el servidor MySQL está al
tanto de esto a través del uso de un fichero de
configuración (my.ini
). El fichero
my.ini
debe estar localizado en el
directorio de Windows, generalmente
C:\WINNT
o
C:\WINDOWS
. Se puede determinar su
ubicación exacta a partir de la variable de entorno
WINDIR
si se ordena lo siguiente en la
línea de comandos:
C:\> echo %WINDIR%
Cualquier editor de texto, como Notepad, sirve para crear y
modificar un fichero de opciones. Por ejemplo, si MySQL se
instala en E:\mysql
y el directorio de
datos es D:\MySQLdata
, se puede crear
el fichero de opciones y establecer una sección llamada
[mysqld]
para indicar los valores de los
parámetros basedir y datadir:
[mysqld] # Coloca en basedir el directorio de instalación basedir=E:/mysql # Coloca en datadir el directorio de datos datadir=D:/MySQLdata
Debe tenerse en cuenta que las rutas de directorio, aún en Windows, deben escribirse en los ficheros de opciones con barras invertidas (/) en lugar de las habituales. Si se desea emplear estas últimas, deben colocarse en forma doble:
[mysqld] # Coloca en basedir el directorio de instalación basedir=C:\\Program Files\\MySQL\\MySQL Server 5.0 # Coloca en datadir el directorio de datos datadir=D:\\MySQLdata
Consulte Sección 2.3.8, “Creación de un fichero de opciones”.
Error: Cannot create Windows service for MySql. Error: 0
Este error ocurre cuando se reinstala o actualiza MySQL utilizando el Asistente de Configuración y sin detener y quitar primero el servicio MySQL existente. Sucede debido a que cuando el Asistente de Configuración intenta instalar el servicio, halla el anterior con el mismo nombre.
Una solución es escoger un nombre de servicio diferente a
mysql
cuando se emplea el Asistente de
Configuración. Esto le permitirá al nuevo servicio
instalarse correctamente, pero aún seguirá existiendo el
servicio anterior. Aunque no es nocivo, es mejor remover los
servicios que no están en uso.
Para quitar permanentemente el antiguo servicio mysql, debe emplearse el siguiente comando en la línea de comandos, dentro de un usuario que tenga privilegios de administrador:
C:\>sc delete mysql [SC] DeleteService SUCCESS
Si la versión de Windows que se está utilizando no posee
la utilidad sc
, puede descargarse la
utilidad delsrv
desde
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/delsrv-o.asp
y utilizarla con la sintaxis delsrv
mysql
.
Esta sección detalla algunos pasos a seguir cuando se actualiza MySQL para Windows.
Siempre debería hacerse una copia de respaldo de la instalación de MySQL en uso antes de llevar a cabo una actualización. Consulte Sección 5.8.1, “Copias de seguridad de bases de datos”.
Descargar la última distribución de MySQL para Windows desde http://dev.mysql.com/downloads.
Antes de actualizar MySQL, debe detenerse el servidor.
Si el servidor está instalado como servicio de Windows, debe detenerse el servicio ingresando lo siguiente en la línea de comandos:
C:\> NET STOP MYSQL
Si no se está ejecutando el servidor MySQL como un servicio de Windows, debe detenerse el servidor con el siguiente comando:
C:\> C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqladmin -u root shutdown
Cuando se actualiza a MySQL 5.0 desde una versión anterior de la 4.1.5 o bien cuando se actualiza desde una versión instalada desde un fichero zip a otra que utiliza el Asistente de Instalación MySQL, se debe quitar manualmente la instalación anterior, incluyendo el servicio MySQL (si el server se hubiera instalado como servicio de Windows).
Para quitar el servicio MySQL, debe utilizarse el siguiente comando:
C:\> C:\mysql\bin\mysqld --remove
Si no se quita el servicio existente, el Asistente de Instalación MySQL puede fallar al instalar el nuevo servicio MySQL.
Si se está empleando el Asistente de Instalación MySQL, debe iniciarse el asistente como se indica en Sección 2.3.4, “Usar el asistente de instalación de MySQL”.
Si se está instalando MySQL desde un fichero Zip, debe
descomprimirse el fichero. Durante la operación puede
sobreescribirse la instalación actual de MySQL
(generalmente localizada en C:\mysql
),
o instalar la nueva versión en una ubicación diferente,
como C:\mysql5
. Se recomienda
sobreescribir la instalación existente.
Reiniciar el servidor. Por ejemplo, usando el comando NET START MySQL si se ejecutará MySQL como un servicio, o en otro caso, invocar directamente el comando mysqld.
Consulte Sección 2.10, “Aumentar la versión de MySQL” para obtener información adicional (no limitada a Windows) sobre la actualización de MySQL.
Si se producen errores, consulte Sección 2.3.14, “Resolución de problemas en la instalación de MySQL bajo Windows”.
MySQL para Windows ha demostrado por sí mismo ser muy estable. La versión para Windows de MySQL tiene las mismas características que su contraparte Unix, con las siguientes excepciones:
Windows 95 y los subprocesos
Windows 95 pierde cerca de 200 bytes de memoria principal por cada vez que crea un subproceso. Cada conexión en MySQL crea un nuevo subproceso, de modo que no se debería ejecutar mysqld por un período prolongado de tiempo, en Windows 95, si el servidor va a gestionar muchas conexiones. Otras versiones de Windows no presentan este inconveniente.
Cantidad limitada de puertos
Los sistemas Windows tienen alrededor de 4.000 puertos disponibles para conexiones de clientes, y luego de que una conexión se cierra, el puerto demora entre dos y cuatro minutos en liberarse. En situaciones donde los clientes se conecten y desconecten del servidor frecuentemente, es posible que todos los puertos disponibles se utilicen antes de que los puertos cerrados sean utilizables de nuevo. Si esto ocurre, el servidor MySQL no responderá aun cuando se esté ejecutando. Debe tenerse en cuenta que los puertos pueden ser usados por otras aplicaciones que se ejecuten en el mismo ordenador, en cuyo caso la cantidad de puertos disponibles para MySQL será menor que lo mencionado.
Para más información, consulte http://support.microsoft.com/default.aspx?scid=kb;en-us;196271.
Lecturas simultáneas
MySQL depende de las llamadas del sistema
pread()
y pwrite()
para ser capaz de mezclar INSERT
y
SELECT
. Actualmente se usan mutexes para
emular pread()
y
pwrite()
. Se planea reemplazar en un
futuro la interfaz a nivel de ficheros con una interfaz
virtual, de modo que se pueda utilizar la interfaz
readfile()
/writefile()
en Windows NT, 2000 y XP, para obtener más velocidad. La
implementación actual limita a 2.048 el número de ficheros
abiertos que MySQL 5.0 puede usar, lo cual significa que no
se pueden abrir tantos procesos simultáneos en Windows NT,
2000, XP y 2003 como en Unix.
Bloqueo de lectura
MySQL utiliza un bloqueo de lectura por cada conexión, lo cual tiene los siguientes efectos cuando están habilitadas conexiones named pipe:
Una conexión no es desconectada automáticamente luego de ocho horas, como ocurre en la versión Unix de MySQL.
Si una conexión se congela, no es posible eliminarla sin interrumpir a MySQL.
mysqladmin kill no funciona con una conexión congelada.
mysqladmin shutdown no funciona en tanto haya conexiones congeladas.
Se planea resolver este problema en el futuro.
ALTER
TABLE
Mientras se está ejecutando una sentencia ALTER
TABLE
, la tabla está bloqueada frente al uso por
parte de otros subprocesos. Esto tiene que ver con el hecho
de que en Windows no se puede eliminar un fichero que está
en uso por otro subproceso. En el futuro se podría
encontrar alguna solución a este problema.
DROP
TABLE
Realizar DROP TABLE
sobre una tabla que
está en uso por una tabla MERGE
no
funcionará en Windows porque el manejador
MERGE
oculta el mapeo de la tabla a la
capa superior de MySQL. Debido a que Windows no permite
eliminar archivos que se encuentran abiertos, primero
deberán guardarse los cambios en todas las tablas
MERGE
(con FLUSH
TABLES
) o eliminar la tabla
MERGE
antes de borrar la tabla en
cuestión.
DATA DIRECTORY
e
INDEX DIRECTORY
Las opciones de CREATE TABLE
DATA DIRECTORY
e INDEX
DIRECTORY
se ignoran en Windows, ya que Windows no
soporta vínculos simbólicos. Estas opciones también se
ignoran en otros sistemas operativos que no tengan una
llamada realpath()
funcional.
DROP
DATABASE
No se puede eliminar una base de datos que está siendo utilizada por algún subproceso.
Finalizar MySQL desde el Administrador de Tareas
No es posible finalizar MySQL desde el Administrador de Tareas o con la utilidad shutdown en Windows 95. Se lo debe detener usando mysqladmin shutdown.
Nombres case-insensitive
Los nombres de ficheros no son case sensitive en Windows, por lo tanto tampoco lo son los nombres de bases de datos y tablas. La única restricción es que los nombres de bases de datos y tablas deben ser especificados empleando el mismo esquema de mayúsculas y minúsculas a lo largo de la misma sentencia. Consulte Sección 9.2.2, “Sensibilidad a mayúsuclas y minúsculas de identificadores”.
El separador de rutas
'\
'
En Windows, los componentes de las rutas de directorios
están separados por '\
', el cual es
también el carácter de escape en MySQL. Si se está
utilizando LOAD DATA INFILE
o
SELECT ... INTO OUTFILE
, deben usarse
nombres de ficheros al estilo Unix, separados con caracteres
'/
':
mysql> LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Una alternativa es duplicar el carácter
'\
':
mysql> LOAD DATA INFILE 'C:\\tmp\\skr.txt' INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
Problemas con pipes.
Los pipes no funcionan confiablemente desde la línea de
comandos de Windows. Si el pipe incluye el carácter
^Z
/ CHAR(24)
, Windows
lo reconocerá como fin de fichero y terminará el programa.
Esto es un problema particularmente cuando se intenta aplicar un fichero de registro (log) binario:
C:\> mysqlbinlog binary-log-name | mysql --user=root
Si ocurre un problema al aplicar el fichero de registro y se
sospecha que es causado por un carácter
^Z
/ CHAR(24)
, puede
intentarse la siguiente solución:
C:\> mysqlbinlog binary-log-file --result-file=/tmp/bin.sql C:\> mysql --user=root --execute "source /tmp/bin.sql"
El último comando tambien puede usarse para leer confiablemente cualquier fichero SQL que pueda contener datos binarios.
Error Access denied for
user
(Acceso denegado a usuario)
Si se intenta ejecutar un programa cliente MySQL para
conectarse a un servidor que funciona en el mismo ordenador,
pero se obtiene el mensaje de error Access denied
for user
'
, significa que MySQL no puede
resolver apropiadamente el nombre del ordenador anfitrión
(host).
algún-usuario
'@'unknown' to
database 'mysql'
Para resolver esto, se debe crear un fichero llamado
\windows\hosts
conteniendo la siguiente
información:
127.0.0.1 localhost
La siguiente es una lista de temas pendientes para aquellos que deseen colaborar en el perfeccionamiento de MySQL para Windows:
Agregar macros para utilizar los métodos de incremento/decremento provistos por Windows, más rápidos y seguros para el trabajo con subprocesos.
La manera recomendada de instalar MySQL en Linux es utilizando
paquetes RPM. Los RPMs de MySQL están generados en SuSE Linux
7.3, pero deberían funcionar con cualquier versión de Linux que
soporte rpm y el uso de
glibc
. Para obtener los paquetes RPM, consulte
Sección 2.1.3, “Cómo obtener MySQL”.
MySQL AB proporciona RPMs específicos para algunas plataformas; la diferencia entre un RPM específico para una plataforma y uno genérico es que el primero es generado sobre la misma plataforma a donde está destinado, y emplea enlazado dinámico, en tanto que el RPM genérico está enlazado estáticamente con LinuxThreads.
Nota: las distribuciones RPM de MySQL a menudo estan proporcionadas por otros proveedores. Hay que tener en cuenta que pueden diferir, en características y prestaciones, de aquellas generadas por MySQL AB, y que las instrucciones de instalación en este manual no se les aplican necesariamente. Se deberían consultar las instrucciones del proveedor.
Si ocurren problemas con un fichero RPM (por ejemplo, si se recibe
el error “Sorry, the host
'
”), consulte
Sección 2.12.1.2, “Notas sobre la distribución binaria de Linux”.
xxxx
' could not be looked
up
En la mayoría de los casos, sólo será necesario instalar los
paquetes MySQL-server
y
MySQL-client
para conseguir una instalación de
MySQL en funcionamiento. Los otros paquetes no se necesitan para
una instalación estándar. Si se deseara ejecutar un servidor
MySQL-Max, el cual posee capacidades adicionales, se debería
instalar también el RPM MySQL-Max
. No
obstante, ello debería hacerse solamente
después de instalar el RPM de
MySQL-server
. Consulte
Sección 5.1.2, “El servidor extendido de MySQL mysqld-max”.
Si se obtiene un mensaje de error de dependencias cuando se
intentan instalar los paquetes MySQL (por ejemplo,
“error: removing these packages would break
dependencies: libmysqlclient.so.10 is needed by
...
”), se deberá instalar también el paquete
MySQL-shared-compat
, el cual incluye las
bibliotecas para compatibilidad hacia atrás
(libmysqlclient.so.12
para MySQL 4.0 y
libmysqlclient.so.10
para MySQL 3.23).
Muchas distribuciones Linux aún incluyen MySQL 3.23 y usualmente
enlazan las aplicaciones dinámicamente para economizar espacio de
disco. Si estas bibliotecas compartidas están en un paquete
separado (por ejemplo, MySQL-shared
), es
suficiente con dejar ese paquete instalado y solamente actualizar
el servidor MySQL y los paquetes cliente (los cuales están
enlazados estáticamente y no dependen de bibliotecas
compartidas). Para aquellas distribuciones que incluyen las
bibliotecas compartidas en el mismo paquete que el servidor MySQL
(por ejemplo, Red Hat Linux), se puede instalar el RPM
MySQL-shared
3.23 o utilizar en su lugar el
paquete MySQL-shared-compat
.
Están disponibles los siguientes paquetes RPM:
MySQL-server-
VERSION
.i386.rpm
El servidor MySQL. Será necesario, a menos que solamente se
desee conectar a un servidor MySQL ejecutado en otro
ordenador. Nota: los ficheros RPM del servidor se denominaban
MySQL-
antes de la versión 4.0.10. Es decir, no incluían
VERSION
.i386.rpm-server
en su nombre.
MySQL-Max-
VERSION
.i386.rpm
El servidor MySQL-Max. Este servidor tiene capacidades
adicionales que no posee el provisto en el RPM
MySQL-server
. Igualmente, debe instalarse
primero el RPM MySQL-server
, porque el RPM
MySQL-Max
depende de él.
MySQL-client-
VERSION
.i386.rpm
Los programas cliente MySQL estándar. Es probable que siempre se instale este paquete.
MySQL-bench-
VERSION
.i386.rpm
Pruebas al programa y pruebas de rendimiento. Requieren Perl y
el módulo DBD::mysql
.
MySQL-devel-
VERSION
.i386.rpm
Las bibliotecas y ficheros de cabecera que se necesitan para compilar otros clientes MySQL, como los módulos Perl.
MySQL-shared-
VERSION
.i386.rpm
Este paquete contiene las bibliotecas compartidas
(libmysqlclient.so*
) que ciertos lenguajes
y aplicaciones necesitan para enlazar dinámicamente y usar
MySQL.
MySQL-shared-compat-
VERSION
.i386.rpm
Este paquete incluye las bibliotecas compartidas para MySQL
3.23 y MySQL 4.0. Debe instalarse en lugar de
MySQL-shared
si hay instaladas aplicaciones
enlazadas dinámicamente con MySQL 3.23 y se desea actualizar
a MySQL 4.0 sin afectar las dependencias de bibliotecas. Este
paquete se encuentra disponible desde MySQL 4.0.13.
MySQL-embedded-
VERSION
.i386.rpm
La biblioteca del servidor MySQL incrustado (desde MySQL 4.0)
MySQL-
VERSION
.src.rpm
Contiene el código fuente de todos los paquetes anteriores. Puede usarse para regenerar los RPMs bajo otras arquitecturas (por ejemplo, Alpha o SPARC).
Para ver todos los ficheros contenidos en un paquete RPM (por
ejemplo, un RPM MySQL-server
), se debe
ejecutar:
shell> rpm -qpl MySQL-server-VERSION
.i386.rpm
Para llevar a cabo una instalación estándar mínima, debe ejecutarse:
shell> rpm -i MySQL-server-VERSION
.i386.rpm shell> rpm -i MySQL-client-VERSION
.i386.rpm
Para instalar solamente el paquete cliente, debe ejecutarse:
shell> rpm -i MySQL-client-VERSION
.i386.rpm
RPM ofrece una característica para verificar la integridad y
autenticidad de los paquetes antes de instalarlos. Para más
información consulte
Sección 2.1.4, “Comprobar la integridad de paquetes con sumas de verificación MD5 o GnuPG
”.
El servidor RPM ubica los datos bajo el directorio
/var/lib/mysql
. También crea una cuenta de
acceso para el usuario mysql
(si no existe
anteriormente) a fin de ejecutar el servidor MySQL, y crea las
correspondientes entradas en /etc/init.d/
para iniciar el servidor automáticamente al arrancar el sistema.
(Esto significa que si se había realizado una instalación previa
y se hicieron cambios al script de inicio, posiblemente se desee
hacer una copia de ese script para no perder los cambios al
instalar un nuevo RPM). Consulte Sección 2.9.2.2, “Arrancar y parar MySQL automáticamente”
para más información sobre como MySQL puede iniciarse
automáticamente junto con el sistema.
Si se va a instalar el RPM MySQL en una distribución antigua de
Linux la cual no soporta scripts de inicio en
/etc/init.d
(directamente o por medio de un
symlink), deberá crearse un vínculo simbólico que apunte a la
ubicación donde realmente está instalado el script de
inicialización. Por ejemplo, si la ubicación es
/etc/rc.d/init.d
, se deberán ejecutar los
siguientes comandos antes de instalar el RPM para crear
/etc/init.d
como un vínculo simbólico que
apunte allí:
shell> cd /etc shell> ln -s rc.d/init.d .
Sin embargo, todas las principales distribuciones Linux de la
actualidad soportan la nueva disposición de directorios que
utiliza /etc/init.d
, porque es un requisito
para cumplir con el LSB (Linux Standard Base, Base Estándar para
Linux).
Si entre los ficheros RPM instalados se encuentra
MySQL-server
, el servidor
mysqld debería estar ejecutándose luego de la
instalación, y se debería estar en condiciones de comenzar a
utilizar MySQL.
Si algo no va bien, se puede hallar más información en la sección dedicada a la instalación binaria. Consulte Sección 2.7, “Instalación de MySQL en otros sistemas similares a Unix”.
Nota: Las cuentas que se hallan en las tablas de permisos de MySQL, en principio no están protegidas con contraseñas. Después de iniciar el servidor se deben establecer contraseñas para esas cuentas siguiendo las instrucciones en Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
Se puede instalar MySQL en Mac OS X 10.2.x (“Jaguar”) y posteriores utilizando un paquete binario de Mac OS X en formato PKG en lugar de la distribución binaria tarball. Debe tenerse en cuenta que las versiones anteriores de Mac OS X (por ejemplo, 10.1.x) no no están soportadas por este paquete.
El paquete se encuentra dentro de un fichero de imagen de disco
(.dmg
) que deberá montarse haciendo doble
click sobre su ícono en Finder. Una vez montado debería verse su
contenido en la pantalla.
Para obtener MySQL, consulte Sección 2.1.3, “Cómo obtener MySQL”.
Nota: Antes de proceder con la instalación, deben haberse finalizado todas las instancias del servidor MySQL en ejecución, ya sea usando la Aplicación MySQL Manager (en Mac OS X Server) o a través de mysqladmin shutdown en la línea de comandos.
Para instalar el fichero PKG de MySQL, debe hacerse doble click en el ícono del paquete. Esto iniciará el Instalador de Paquetes de Mac OS X, el cual guiará el resto de la instalación.
Debido a un error en el instalador de paquetes de Mac OS X, puede llegar a verse este error en el cuadro de diálogo de selección de disco destino:
You cannot install this software on this disk. (null)
Si ocurre este error, simplemente debe hacerse click en el botón
Go Back
una vez para volver a la pantalla
anterior. Luego hacer click en Continue
para
avanzar nuevamente a la selección de disco destinto, y entonces
debería poderse elegir sin problemas la unidad de instalación.
MySQL AB ha informado de este error a Apple, quien se encuentra
investigando el problema.
El PKG para Mac OS X de MySQL se instala en
/usr/local/mysql-
y también instala un vínculo simbólico,
VERSION
/usr/local/mysql
, apuntando a la nueva
ubicación. Si existe un directorio llamado
/usr/local/mysql
, será renombrado a
/usr/local/mysql.bak
primero. Adicionalmente,
el instalador creará las tablas de permisos en la base de datos
mysql
a través de la ejecución de
mysql_install_db después de la instalación.
La disposición de la instalación es similar a la de la
distribución binaria en fichero tar, todos los
ficheros binarios de MySQL están ubicados en el directorio
/usr/local/mysql/bin
. El fichero de socket
MySQL se crea por defecto en /tmp/mysql.sock
.
Consulte Sección 2.1.5, “Conformación de la instalación”.
La instalación de MySQL requiere una cuenta de usuario Mac OS X
llamada mysql
. En Mac OS X 10.2 y posteriores,
debería existir por defecto una cuenta con este nombre.
Si se está ejecutando Mac OS X Server, entonces se tiene una versión de MySQL instalada. Las versiones de MySQL que acompañan a cada versión de Mac OS X Server se muestran en la siguiente tabla:
Versión de Mac OS X Server | Versión de MySQL |
10.2-10.2.2 | 3.23.51 |
10.2.3-10.2.6 | 3.23.53 |
10.3 | 4.0.14 |
10.3.2 | 4.0.16 |
10.4.0 | 4.1.10a |
Esta sección del manual abarca solamente la instalación del PKG oficial para Mac OS X de MySQL. Se debe leer la ayuda de Apple relativa a la instalación de MySQL: Ejecutando la aplicación “Help View”, seleccionando la ayuda de “Mac OS X Server”, haciendo una búsqueda por “MySQL”, y leyendo el tema titulado “Installing MySQL.”
En versiones de MySQL preinstaladas en Mac OS X Server, hay que tener en cuenta especialmente que se debería dar inicio a mysqld con el comando safe_mysqld en lugar de mysqld_safe si MySQL es anterior a la versión 4.0.
Si anteriormente se estuvieron utilizando los paquetes para Mac OS X de Marc Liyanage, descargados de http://www.entropy.ch, es suficiente con seguir las instrucciones para actualizar paquetes que usan la disposición de la instalación binaria, como se ha presentado en estas páginas.
Si se está actualizando hacia el PKG MySQL oficial desde alguna de las versiones 3.23.xx de Marc, o desde la versión de MySQL que acompaña al Mac OS X Server, se pueden convertir al formato actual las tablas de privilegios MySQL existentes, ya que se añadieron algunos nuevos privilegios de seguridad. Consulte Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.
Si se desea iniciar automáticamente el servidor MySQL junto con el arranque del sistema, será necesario instalar también el Componente MySQL Startup (Inicio de MySQL). En el caso de MySQL 5.0, viene como un paquete separado dentro de las imágenes de disco de instalación. Siplemente hay que hacer doble click en el ícono MySQLStartupItem.pkg y seguir las instrucciones para instalarlo.
El Componente de Inicio de MySQL sólo necesita ser instalado una vez: no hay necesidad de instalarlo cada vez que se hace una actualización de MySQL
El Componente de Inicio de MySQL se instala en
/Library/StartupItems/MySQLCOM
. (Antes de
MySQL 4.1.2, la ubicación era
/Library/StartupItems/MySQL
, pero entraba en
conflicto con el Componente de Inicio de MySQL instalado por Mac
OS X Server). La instalación del Componente de Inicio agrega una
variable MYSQLCOM=-YES-
al fichero de
configuración del sistema /etc/hostconfig
.
Si se deseara deshabilitar el inicio automático de MySQL,
simplemente hay que cambiar esta variable a
MYSQLCOM=-NO-
.
En Mac OS X Server, la instalación por defecto de MySQL utiliza
la variable MYSQL
en el fichero
/etc/hostconfig
. El instalador del Componente
de Inicio de MySQL provisto por MySQL AB deshabilita esta variable
estableciéndola en MYSQL=-NO-
. Esto evita
conflictos al momento del arranque del sistema con la variable
MYSQLCOM
utilizada por el Componente de Inicio
de MySQL AB. Sin embargo, ello no finaliza un server MySQL en
ejecución. Eso debería ser hecho expresamente por el usuario.
Luego de la instalación, se puede iniciar MySQL ejecutando los siguientes comandos en una ventana de terminal. Se deben tener privilegios de administrador para llevar a cabo esta tarea.
Si se ha instalado el Componente de Inicio:
shell> sudo /Library/StartupItems/MySQLCOM/MySQLCOM start (Enter your password, if necessary) (Press Control-D or enter "exit" to exit the shell)
Si no se ha instalado el Componente de Inicio, debe ingresarse la siguiente secuencia de comandos:
shell> cd /usr/local/mysql shell> sudo ./bin/mysqld_safe (Enter your password, if necessary) (Press Control-Z) shell> bg (Press Control-D or enter "exit" to exit the shell)
Se debería estar en condiciones de conectar con el servidor
MySQL, por ejemplo, ejecutando
/usr/local/mysql/bin/mysql
.
Nota: Las cuentas que se hallan en las tablas de permisos de MySQL, en principio no están protegidas con contraseñas. Después de iniciar el servidor se deben establecer contraseñas para esas cuentas siguiendo las instrucciones en Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
Se podría desear agregar alias al fichero de recursos del shell para facilitar el acceso a los programas más utilizados, como mysql y mysqladmin, desde la línea de comandos. La sintaxis para tcsh es:
alias mysql /usr/local/mysql/bin/mysql alias mysqladmin /usr/local/mysql/bin/mysqladmin
Para bash, debe usarse:
alias mysql=/usr/local/mysql/bin/mysql alias mysqladmin=/usr/local/mysql/bin/mysqladmin
Aún mejor, es agregar /usr/local/mysql/bin
a
la variable de entorno PATH
. Por ejemplo, si se
emplea el shell tcsh, agregando la siguiente
línea al fichero $HOME/.tcshrc
:
setenv PATH ${PATH}:/usr/local/mysql/bin
Si en el directorio home no existe el fichero
.tcshrc
, se lo deberá crear con un editor de
textos.
Si se está actualizando una instalación existente, hay que notar que instalar un nuevo PKG MySQL no borra el directorio de la instalación anterior. Desafortunadamente, el instalador de Mac OS X aún no ofrece la funcionalidad necesaria para actualizar apropiadamente los paquetes instalados con anterioridad.
Para utilizar en la nueva instalación las bases de datos
existentes, habrá que copiar el contenido del directorio de datos
antiguo dentro del nuevo. Hay que asegurarse que ni el antiguo
servidor ni el nuevo estén en funcionamiento cuando se haga esto.
Luego de que se hayan copiado las bases de datos desde la antigua
instalación hacia la nueva, y se haya iniciado exitosamente el
nuevo servidor, debe considerarse la eliminación de la
instalación anterior a fin de recuperar espacio en disco. Quizá
también se desee borrar versiones antiguas de los directorios
Receipt localizados en
/Library/Receipts/mysql-
.
VERSION
.pkg
MySQL fue portado a NetWare a través de un esfuerzo encabezado por Novell. Los clientes de Novell se sentirán gratificados al advertir que NetWare 6.5 incluye la distribución binaria de MySQL, con una licencia comercial para todos los servidores que ejecuten esa versión de NetWare.
MySQL para NetWare está compilado utilizando una combinación de Metrowerks CodeWarrior para NetWare y versiones especiales de compilación cruzada de las GNU autotools.
La última distribución binaria para NetWare puede obtenerse en http://dev.mysql.com/downloads/. Consulte Sección 2.1.3, “Cómo obtener MySQL”.
A fin de hospedar a MySQL, el servidor NetWare debe cumplir estos requisitos:
Debe ser NetWare 6.5 con Support Pack 2 instalado y actualizado con la última LibC, o NetWare 6.0 con Support Pack 4 instalado y actualizado con la última LibC. El Support Pack 2 de NetWare 6.5 y otras actualizaciones pueden descargarse de: http://support.novell.com/filefinder/18197/index.html. El Support Pack 4 de NetWare 6.0 y otras actualizaciones pueden descargarse de: http://support.novell.com/filefinder/13659/index.html. La última biblioteca LibC puede descargarse de: http://developer.novell.com/ndk/libc.htm. Las instrucciones para actualizar LibC se encuentran en: http://developer.novell.com/ndk/doc/libc/index.html?page=/ndk/doc/libc/libc_enu/data/ajjl0r0.html.
Para poder ejecutar la respectiva versión de NetWare, el sistema debe cumplir con los requisitos mínimos de Novell.
Tanto los datos como los ficheros binarios de MySQL deben instalarse en un volumen NSS; los volúmenes tradicionales no están soportados.
Debe emplearse el siguiente procedimiento para instalar MySQL para NetWare:
Si se está actualizando desde una versión anterior, debe detenerse el servidor MySQL. Esto se hace desde la consola del servidor, utilizando el siguiente comando:
SERVER: mysqladmin -u root shutdown
Debe iniciarse sesión en el servidor de destino desde un ordenador cliente que tenga acceso a la ubicación donde se instalará MySQL.
Extraer en el servidor el paquete binario contenido en el
fichero Zip. Hay que cerciorarse de habilitar las rutas en el
fichero Zip para que sea usado. Lo más seguro es simplemente
extraerlo en SYS:\
.
Si se está actualizando desde una instalación anterior,
puede ser necesario copiar el directorio de datos (por
ejemplo, SYS:MYSQL\DATA
), así como
my.cnf
, si se lo había modificado. Luego
puede borrarse la antigua copia de MySQL.
Posiblemente se desee renombrar el directorio de instalación
con una denominación más consistente y simple de usar. Se
recomienda emplear SYS:MYSQL
; los
ejemplos en este manual utilizan ese nombre para referirse al
directorio de instalación en general.
Desde la consola del servidor, debe agregarse una ruta de búsqueda para el directorio conteniendo los NLMs de MySQL. Por ejemplo:
SERVER: SEARCH ADD SYS:MYSQL\BIN
Inicializar el directorio de datos y las tablas de permisos, de ser necesario, a través de la ejecución de mysql_install_db desde la consola del servidor.
Iniciar el servidor MySQL con el comando mysqld_safe desde la consola del servidor.
Para finalizar la instalación, se deberían agregar los
siguientes comandos al autoexec.ncf
. Por
ejemplo, si la instalación de MySQL se encuentra en
SYS:MYSQL
y se desea iniciar MySQL
automáticamente, habría que agregar las siguientes líneas:
#Inicia el servidor de bases de datos MySQL 5.0.x SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE
Si se ejecutará MySQL en NetWare 6.0, es altamente
recomendable utilizar la opción
--skip-external-locking
en la línea de
comandos:
#Inicia el servidor de bases de datos MySQL 5.0.x SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE --skip-external-locking
En tal caso también será necesario utilizar CHECK
TABLE
y REPAIR TABLE
en lugar de
myisamchk, puesto que
myisamchk emplea bloqueo externo. Se sabe
que el bloqueo externo cauas problemas en NetWare 6.0; el
problema fue eliminado en NetWare 6.5.
mysqld_safe para NetWare despliega una pantalla. Cuando se descarga (finaliza) el NLM mysqld_safe, la pantalla no desaparece por defecto. En lugar de eso, espera por una entrada del usuario:
*<NLM has terminated; Press any key to close the screen>*
Si se desea que NetWare cierre la pantalla automáticamente,
debe agregarse la opción --autoclose
a
mysqld_safe. Por ejemplo:
#Inicia el servidor de bases de datos MySQL 5.0.x SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE --autoclose
Al instalar MySQL 5.0, ya sea por primera vez o como actualización de una versión anterior, se debe descargar e instalar el módulo Perl para MySQL 5.0 desde http://forge.novell.com/modules/xfcontent/downloads.php/perl/Modules/MySQL-5.0.3a-Beta-LIBC-Based/. Al instalar MySQL 5.0, ya sea por primera vez o como actualización de una versión previa a la 4.1, se debe descargar e instalar la Extensión de PHP5 para MySQL 4.1 desde http://forge.novell.com/modules/xfcontent/downloads.php/php/Modules/MySQL%204.1/. (Este módulo también debería funcionar con MySQL 5.0)
El funcionamiento de mysqld_safe en NetWare se describe más adelante en Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
Si ya había una instalación de MySQL en el servidor, hay que
cerciorarse de verificar el autoexec.ncf
en
busca de comandos de inicio de MySQL, y editarlos o borrarlos
según sea necesario.
Nota: Las cuentas que se hallan en las tablas de permisos de MySQL, en principio no están protegidas con contraseñas. Después de iniciar el servidor se deben establecer contraseñas para esas cuentas siguiendo las instrucciones en Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
Esta sección abarca la instalación de aquellas distribuciones
binarias que se proveen para varias plataformas en formato de
ficheros comprimidos tar (con extensión
.tar.gz
). Consulte
Sección 2.1.2.5, “Binarios de MySQL compilados por MySQL AB” para ver una lista detallada.
Para obtener MySQL, consulte Sección 2.1.3, “Cómo obtener MySQL”.
Las distribuciones binarias en ficheros tar
tienen nombres con la forma
mysql-
,
donde VERSION
-OS
.tar.gz
es un
número (por ejemplo, VERSION
5.0.9
), y
OS
indica el tipo de sistema operativo
al cual está dirigida la distribución. (Por ejemplo,
pc-linux-i686
).
Adicionalmente a estos paquetes genéricos, MySQL AB también ofrece, para plataformas seleccionadas, distribuciones binarias en paquetes con el formato específico de la plataforma. Consulte Sección 2.2, “Instalación MySQL estándar con una distribución binaria” para obtener información sobre cómo instalarlas.
Para instalar una distribución binaria de MySQL en fichero tar se requieren las siguientes herramientas:
GNU gunzip
para descomprimir la
distribución.
Un tar para expandir la distribución. GNU tar funciona correctamente. Algunos sistemas operativos vienen con una versión preinstalada de tar que tiene algunos problemas. Por ejemplo, el tar incluido con Mac OS X y el de Sun presentan problemas con nombres de fichero largos. En Mac OS X puede utilizarse el también preinstalado programa gnutar. En otros sistemas que tengan un tar deficiente, se debería instalar antes GNU tar.
Si ocurren problemas, siempre debe emplearse
mysqlbug para enviar consultas a la
lista de correo MySQL. Aún si no se trata de un error,
mysqlbug recoge información del sistema que
será de utilidad para quienes intenten resolver el problema. Al
no usar mysqlbug se reduce la probabilidad de
obtener una solución. mysqlbug se puede hallar
en el directorio bin
luego de expandir la
distribución. Consulte Sección 1.6.1.3, “Cómo informar de bugs y problemas”.
Los comandos básicos a ejecutarse para instalar y usar una distribución binaria de MySQL son:
shell> groupadd mysql shell> useradd -g mysql mysql shell> cd /usr/local shell> gunzip </path/to/mysql-VERSION-OS
.tar.gz | tar xvf - shell> ln -sfull-path-to-mysql-VERSION-OS
mysql shell> cd mysql shell> scripts/mysql_install_db --user=mysql shell> chown -R root . shell> chown -R mysql data shell> chgrp -R mysql . shell> bin/mysqld_safe --user=mysql &
Nota: Este procedimiento no establece ninguna contraseña para las cuentas MySQL. Después de completar el procedimiento debe continuarse con Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
Esta es una versión más detallada del procedimiento para instalar una distribución binaria:
Crear un usuario y un grupo para mysqld a fin de que pueda ejecutarse:
shell> groupadd mysql shell> useradd -g mysql mysql
Estos comandos agregan el grupo mysql
y el
usuario mysql
. La sintaxis para
useradd y groupadd puede
variar ligeramente entre las distintas versiones de Unix.
También pueden llamarse adduser y
addgroup.
Si se quisiera llamar al usuario y al grupo con otro nombre en
lugar de mysql
, habría que substituir por
el nombre apropiado en los siguientes pasos.
Posicionarse en el directorio en el cual se desea expandir la
distribución. En el siguiente ejemplo se expandirá bajo
/usr/local
. (Las instrucciones, sin
embargo, asumen que se tiene permisos suficientes para crear
ficheros y directorios en /usr/local
. Si
tal directorio se encuentra protegido, se deberá llevar a
cabo la instalación como usuario root
.)
shell> cd /usr/local
Obtener un fichero de distribución desde uno de los sitios listados en Sección 2.1.3, “Cómo obtener MySQL”. Dado un release, las distribuciones de todas las plataformas son generadas a partir del mismo código fuente.
Expandir la distribución, lo cual creará el directorio de instalación. Luego crear un vínculo simbólico a ese directorio:
shell> gunzip </path/to/mysql-VERSION-OS
.tar.gz | tar xvf - shell> ln -sfull-path-to-mysql-VERSION-OS
mysql
El comando tar crea un directorio
denominado
mysql-
.
El comando VERSION
-OS
ln
crea un vínculo simbólico a
ese directorio. Esto permite referirse a ese directorio de una
forma más sencilla: /usr/local/mysql
.
Con GNU tar no se necesita invocar
separadamente a gunzip
. Se puede reemplazar
la primera línea con el siguiente comando alternativo, para
descomprimir y extraer la distribución:
shell> tar zxvf /path/to/mysql-VERSION-OS
.tar.gz
Cambiar la ubicación dentro del directorio de instalación:
shell> cd mysql
Se pueden encontrar varios ficheros y subdirectorios en el
directorio mysql
. Los más importantes a
efectos de la instalación son los subdirectorios
bin
y scripts
.
bin
Este directorio contiene los programas cliente y el
servidor. Se debería agregar la ruta completa de este
directorio a la variable de entorno
PATH
, para que el shell encuentre los
programas de MySQL apropiadamente. Consulte
Apéndice E, Variables de entorno.
scripts
Este directorio contiene el script
mysql_install_db utilizado para
inicializar la base de datos mysql
, que
contiene las tablas que almacenan los permisos de acceso
al servidor.
Si no se ha instalado antes MySQL, se deben crear las tablas de permisos:
shell> scripts/mysql_install_db --user=mysql
Si se ejecuta el comando como usuario root
,
se debe emplear la opción --user
tal como
se muestra. El valor de la opción debe ser el nombre de la
cuenta de usuario creada en el primer paso, para permitir que
el servidor se ejecute. Si se ejecuta el comando habiendo
iniciado sesión como este último usuario, se puede omitir la
opción --user
.
Despues de crear o actualizar la tabla de permisos, habrá que reiniciar el servidor manualmente.
Se debe cambiar el propietario de los programas binarios a
root
y el propietario del directorio de
datos al que se creó para ejecutar mysqld.
Asumiendo que se está en el directorio de instalación
(/usr/local/mysql
), el comando sería
similar a este:
shell> chown -R root . shell> chown -R mysql data shell> chgrp -R mysql .
El primer comando cambia el atributo de propietario de los
ficheros y les asigna el usuario root
. El
segundo cambia el atributo de propietario del directorio de
datos y le asigna el usuario mysql
. El
tercero cambia el atributo de grupo, asignándolo al grupo
mysql
.
Si se desea que MySQL se inicie automáticamente durante el
arranque del ordenador, debe copiarse el fichero
support-files/mysql.server
a la ubicación
donde se encuentran los ficheros de inicio del sistema. Puede
hallarse más información dentro del mismo script
support-files/mysql.server
y en
Sección 2.9.2.2, “Arrancar y parar MySQL automáticamente”.
Pueden establecerse nuevas cuentas empleando el script
bin/mysql_setpermission si se instalan los
módulos de Perl DBI
y
DBD::mysql
. Para más instrucciones
consulte Sección 2.13, “Notas sobre la instalación de Perl”.
Si se desea utilizar mysqlaccess y la
distribución MySQL se ha instalado en una ubicación no
estándar, deberá cambiarse el valor de
$MYSQL
, la cual es la variable que
mysqlaccess utiliza para saber dónde se
encuentra el cliente mysql. Debe editarse
el script bin/mysqlaccess
aproximadamente
en la línea 18, que tiene este aspecto:
$MYSQL = '/usr/local/bin/mysql'; # ruta al ejecutable mysql
Debe modificarse la ruta para reflejar la ubicación del
sistema donde mysql se encuentra realmente.
Si no se hace así, se obtendrá un error Broken
pipe
cuando se ejecute
mysqlaccess.
Después de que todo ha sido expandido e instalado, se debería probar la distribución.
El siguiente comando inicia al servidor MySQL:
shell> bin/mysqld_safe --user=mysql &
Hay más información acerca de mysqld_safe en Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
Nota: Las cuentas que se hallan en las tablas de permisos de MySQL, en principio no están protegidas con contraseñas. Después de iniciar el servidor se deben establecer contraseñas para esas cuentas siguiendo las instrucciones en Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
Antes de proceder a una instalación de código fuente, se debería verificar si hay una distribución binaria disponible para la plataforma que se desea utilizar y si esta sirve adecuadamente al propósito del usuario. MySQL AB ha hecho grandes esfuerzos para asegurarse que las distribuciones binarias están realizadas con las mejores opciones posibles.
Para obtener una distribucion de código fuente de MySQL, Sección 2.1.3, “Cómo obtener MySQL”.
Las distribuciones de código fuente MySQL se proveen como
ficheros tar comprimidos y tienen nombres con
la forma
mysql-
,
donde VERSION
.tar.gzVERSION
es un número del tipo
5.0.9-beta
.
Se requieren las siguientes herramientas para generar e instalar MySQL a partir del código fuente:
GNU gunzip
para descomprimir la
distribución.
Un tar para expandir la distribución. GNU tar funciona correctamente. Algunos sistemas operativos vienen con una versión preinstalada de tar que tiene algunos problemas. Por ejemplo, el tar incluido con Mac OS X y el de Sun presentan problemas con nombres de fichero largos. En Mac OS X puede utilizarse el también preinstalado programa gnutar. En otros sistemas que tengan un tar deficiente, se debería instalar antes GNU tar.
Un compilador ANSI C++. gcc 2.95.2 o
posterior, egcs 1.0.2 o posterior o
egcs 2.91.66, SGI C++, y SunPro ++ son
algunos de los compiladores que funcionan correctamente. No se
necesitará libg++
si se emplea
gcc. gcc 2.7.x tiene un
error que imposibilita compilar algunos ficheros C++ a pesar
de que son correctos, como
sql/sql_base.cc
. Si solamente se dispone
de gcc 2.7.x, será necesario actualizarlo
para poder compilar MySQL. También se sabe que
gcc 2.8.1 tiene problemas en algunas
plataformas, de modo que debería evitarse su uso si hay un
compilador más actual para la plataforma.
Se recomienda gcc 2.95.2 para compilar MySQL 3.23.x.
Un buen programa make. GNU make siempre se recomienda y algunas veces es requerido. Si ocurriesen problemas, se aconseja intentar con GNU make 3.75 o posterior.
Si se dispone de una versión de gcc lo
suficientemente actualizada como para soportar la opción
-fno-exceptions
, es muy
importante que se utilice. De lo contrario, podría
obtenerse un binario que presente errores fatales aleatorios.
También se recomienda emplear
-felide-constructors
y
-fno-rtti
junto con
-fno-exceptions
. En caso de duda, debe
procederse así:
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors \ -fno-exceptions -fno-rtti" ./configure \ --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
En la mayoría de los sistemas, esto producirá un binario rápido y estable.
Si ocurren problemas, siempre debe emplearse
mysqlbug para enviar consultas a la
lista de correo MySQL. Aún si no se trata de un error,
mysqlbug recoge información del sistema que
será de utilidad para quienes intenten resolver el problema. Al
no usar mysqlbug se reduce la probabilidad de
obtener una solución. mysqlbug se puede hallar
en el directorio bin
luego de expandir la
distribución. Consulte Sección 1.6.1.3, “Cómo informar de bugs y problemas”.
Los comandos básicos para instalar una distribución MySQL de código fuente son:
shell> groupadd mysql shell> useradd -g mysql mysql shell> gunzip < mysql-VERSION
.tar.gz | tar -xvf - shell> cd mysql-VERSION
shell> ./configure --prefix=/usr/local/mysql shell> make shell> make install shell> cp support-files/my-medium.cnf /etc/my.cnf shell> cd /usr/local/mysql shell> bin/mysql_install_db --user=mysql shell> chown -R root . shell> chown -R mysql var shell> chgrp -R mysql . shell> bin/mysqld_safe --user=mysql &
Si se comienza desde un RPM fuente, debe procederse así:
shell> rpmbuild --rebuild --clean MySQL-VERSION
.src.rpm
Esto genera un binario RPM instalable. En versiones antiguas de RPM, podría ser necesario reemplazar el comando rpmbuild con rpm.
Nota: Este procedimiento no establece contraseñas para las cuentas de MySQL. Despues de concluirlo, hay que dirigirse a Sección 2.9, “Puesta en marcha y comprobación después de la instalación”, para la configuración y prueba posteriores a la instalación.
Esta es una versión más detallada del procedimiento para instalar una distribución de código fuente:
Crear un usuario y un grupo para mysqld a fin de que pueda ejecutarse:
shell> groupadd mysql shell> useradd -g mysql mysql
Estos comandos agregan el grupo mysql
y
el usuario mysql
. La sintaxis para
useradd y groupadd
puede variar ligeramente entre las distintas versiones de
Unix. También pueden llamarse adduser y
addgroup.
Si se quisiera llamar al usuario y al grupo con otro nombre
en lugar de mysql
, habría que substituir
por el nombre apropiado en los siguientes pasos.
Posicionarse en el directorio en el cual se desea expandir la distribución.
Obtener un fichero de distribución desde uno de los sitios listados en Sección 2.1.3, “Cómo obtener MySQL”.
Expandir la distribución dentro del directorio actual:
shell> gunzip < /path/to/mysql-VERSION
.tar.gz | tar xvf -
Este comando creará un directorio llamado
mysql-
.
VERSION
Con GNU tar no se necesita invocar
separadamente a gunzip
. Se puede usar el
siguiente comando alternativo, para descomprimir y extraer
la distribución:
shell> tar zxvf /path/to/mysql-VERSION-OS
.tar.gz
Posicionarse en el directorio de más alto nivel de la distribución expandida:
shell> cd mysql-VERSION
Actualmente debe configurarse y compilarse MySQL desde este directorio. No se puede compilar en un directorio diferente.
Configurar el release y compilar todo:
shell> ./configure --prefix=/usr/local/mysql shell> make
Al ejecutar configure, es posible que se deseen especificar algunas opciones. Ejecutar ./configure --help para obtener la lista de las opciones disponibles. Sección 2.8.2, “Opciones típicas de configure” trata acerca de alguans de las opciones más útiles.
Si configure fallara y se enviase un mail
a la lista de correo de MySQL para solicitar asistencia,
deben incluirse algunas líneas del fichero
config.log
que en apariencia sirvan
para resolver el problema. También, incluir el último par
de líneas emitidas por configure en la
pantalla. Para enviar el informe de error debe utilizarse el
script mysqlbug. Consulte
Sección 1.6.1.3, “Cómo informar de bugs y problemas”.
Si el compilador falla, consulte Sección 2.8.4, “Problemas en la compilación de MySQL”.
Instalar la distribución:
shell> make install
Si se desea crear un fichero de opciones, debe utilizarse
como plantilla uno de los presentes en el directorio
support-files
. Por ejemplo:
shell> cp support-files/my-medium.cnf /etc/my.cnf
Podría ser necesario iniciar sesión como
root
para ejecutar estos comandos.
Si se configurará el soporte para tablas
InnoDB
, habrá que editar el fichero
/etc/my.cnf
, quitar el carácter
#
al comienzo de las líneas de opciones
que comienzan con innodb_...
, y modificar
los valores según lo deseado. Consulte
Sección 4.3.2, “Usar ficheros de opciones” y
Sección 15.3, “Configuración de InnoDB
”.
Posicionarse en el directorio de instalación:
shell> cd /usr/local/mysql
Si no se ha instalado antes MySQL, se deben crear las tablas de permisos:
shell> bin/mysql_install_db --user=mysql
Si se ejecuta el comando como usuario
root
, se debe emplear la opción
--user
tal como se muestra. El valor de
la opción debe ser el nombre de la cuenta de usuario creada
en el primer paso, para permitir que el servidor se ejecute.
Si se ejecuta el comando habiendo iniciado sesión como este
último usuario, se puede omitir la opción
--user
.
Despues de crear o actualizar la tabla de permisos mediante mysql_install_db, habrá que reiniciar el servidor manualmente.
Se debe cambiar el propietario de los programas binarios a
root
y el propietario del directorio de
datos al que se creó para ejecutar
mysqld. Asumiendo que se está en el
directorio de instalación
(/usr/local/mysql
), el comando sería
similar a este:
shell> chown -R root . shell> chown -R mysql var shell> chgrp -R mysql .
El primer comando cambia el atributo de propietario de los
ficheros y les asigna el usuario root
. El
segundo cambia el atributo de propietario del directorio de
datos y le asigna el usuario mysql
. El
tercero cambia el atributo de grupo, asignándolo al grupo
mysql
.
Si se desea que MySQL se inicie automáticamente durante el
arranque del ordenador, debe copiarse el fichero
support-files/mysql.server
a la
ubicación donde se encuentran los ficheros de inicio del
sistema. Puede hallarse más información dentro del mismo
script support-files/mysql.server
y en
Sección 2.9.2.2, “Arrancar y parar MySQL automáticamente”.
Pueden establecerse nuevas cuentas empleando el script
bin/mysql_setpermission si se instalan
los módulos de Perl DBI
y
DBD::mysql
. Para más instrucciones
consulte Sección 2.13, “Notas sobre la instalación de Perl”.
Luego de que todo se ha instalado, se debería inicializar y probar la distribución por medio del siguiente comando:
shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &
Si este comando fallara inmediatamente y emitiera el mensaje
mysqld ended
, se podrá encontrar más
información en el fichero
,
localizado en el directorio de datos.
host_name
.err
Hay más información acerca de mysqld_safe en Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
Nota: Las cuentas que se hallan en las tablas de permisos de MySQL, en principio no están protegidas con contraseñas. Después de iniciar el servidor se deben establecer contraseñas para esas cuentas siguiendo las instrucciones en Sección 2.9, “Puesta en marcha y comprobación después de la instalación”.
El script configure brinda un gran control sobre la configuración de una distribución de código fuente. Generalmente esto se hace por medio de las opciones que siguen a configure en la línea de comandos, aunque configure también se ve afectado por ciertas variables de entorno. Consulte Apéndice E, Variables de entorno. Para obtener una lista de las opciones aceptadas por configure, debe ejecutarse este comando:
shell> ./configure --help
A continuación se describen algunas de las opciones de configure más comunes:
Para compilar solamente las bibliotecas cliente y los
programas cliente de MySQL, sin el servidor, debe emplearse
la opción --without-server
.
shell> ./configure --without-server
Si no se dispone de un compilador de C++, no se podrá
compilar mysql (es el único programa
cliente que necesita de C++). En este caso, se puede quitar
de configure el código que comprueba la
existencia del compilador C++ y luego ejecutar
./configure con la opción
--without-server
. El proceso de
compilación igualmente intentará generar
mysql, pero se puede ignorar cualquier
advertencia acerca de mysql.cc
. (Si
make se detiene, debe intentarse con
make -k, que continúa con el resto de la
generación aún si ocurren errores).
Si se deseara generar la biblioteca MySQL incrustada
(libmysqld.a
), debe utilizarse la opción
--with-embedded-server
.
Si no se desea que los archivos de registro (logs) y los
directorios de bases de datos se ubiquen dentro de
/usr/local/var
, se debe emplear un
comando de configure similar a este:
shell> ./configure --prefix=/usr/local/mysql shell> ./configure --prefix=/usr/local \ --localstatedir=/usr/local/mysql/data
El primer comando cambia el prefijo de instalación de modo
que todo sea instalado en
/usr/local/mysql
en lugar de
/usr/local
. Els egundo comando conserva
el prefijo de instalación por defecto, pero reemplaza la
ubicación predeterminada de los directorios de datos
(normalmente, /usr/local/var
) y lo
establece en /usr/local/mysql/data
.
Después de haber compilado MySQL, se pueden cambiar estas
opciones con ficheros de opciones. consulte
Sección 4.3.2, “Usar ficheros de opciones”.
Si se está utilizando Unix y se desea que el socket MySQL
se ubique en otro directorio que el preeterminado
(normalmente en /tmp
o
/var/run
), debe emplearse un comando
configure similar a este:
shell> ./configure \ --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock
El nombre de fichero para el socket debe ser una ruta
absoluta. También se puede modificar la ubicación de
mysql.sock
posteriormente, con un
fichero de opciones MySQL. Consulte
Sección A.4.5, “Cómo proteger o cambiar el fichero socket de MySQL /tmp/mysql.sock
”.
Se se desea compilar programas con enlazado estático (por ejemplo, para hacer una distribución binaria, incrementar la velocidad, o solucionar problemas que ocurren con algunas distribuciones de Red Hat Linux) debe ejecutarse configure de esta manera:
shell> ./configure --with-client-ldflags=-all-static \ --with-mysqld-ldflags=-all-static
Si se está usando gcc y no se han
instalado libg++
o
libstdc++
, se le puede indicar a
configure que utilice
gcc como compilador de C++:
shell> CC=gcc CXX=gcc ./configure
Cuando se emplea gcc como compilador de
C++, este no intenta enlazar con libg++
o
libstdc++
. Esta puede ser buena idea
incluso si se dispone de estas bibliotecas, ya que algunas
versiones de ellas causaron, en el pasado, problemas
extraños a usuarios de MySQL.
La siguiente lista presenta algunos compiladores y la configuración de variables de entorno comúnmente utilizada con cada uno.
gcc 2.7.2:
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
egcs 1.0.3a:
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors \ -fno-exceptions -fno-rtti"
gcc 2.95.2:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti"
pgcc
2.90.29 o posterior:
CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc \ CXXFLAGS="-O3 -mpentiumpro -mstack-align-double \ -felide-constructors -fno-exceptions -fno-rtti"
En la mayoría de los casos, podrá obtenerse un binario MySQL razonablemente optimizado usando las opciones de la lista anterior, con el añadido de las siguientes opciones en la línea de configure:
--prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
En otras palabras, la línea completa de configure tendría el siguiente aspecto para todas las versiones recientes de gcc:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti" ./configure \ --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
Los binarios provistos en el sitio Web de MySQL en http://www.mysql.com/ están, en su totalidad, compilados con la máxima optimización y deberían ajustarse perfectamente a la mayoría de los usuarios. Consulte Sección 2.1.2.5, “Binarios de MySQL compilados por MySQL AB”. Existen algunas configuraciones que se pueden manipular para hacer un binario más rápido aún, pero se reservan para los usuarios avanzados. Consulte Sección 7.5.4, “Efectos de la compilación y del enlace en la velocidad de MySQL”.
Si la generación falla y emite mensajes de error relativos
a que el compilador o el enlazador no son capaces de crear
la biblioteca compartida
libmysqlclient.so.#
(donde
'#
' es un número de versión), se puede
resolver el problema pasándole la opción
--disable-shared
a
configure. En este caso,
configure no generará una biblioteca
compartida libmysqlclient.so.#
.
Por defecto, MySQL emplea el conjunto de caracteres
latin1
(ISO-8859-1). Para cambiar el
conjunto de caracteres por defecto, se utiliza la opción
--with-charset
:
shell> ./configure --with-charset=CHARSET
CHARSET
puede ser cualquiera entre
los siguientes: big5
,
cp1251
, cp1257
,
czech
, danish
,
dec8
, dos
,
euc_kr
, gb2312
,
gbk
, german1
,
hebrew
, hp8
,
hungarian
, koi8_ru
,
koi8_ukr
, latin1
,
latin2
, sjis
,
swe7
, tis620
,
ujis
, usa7
, or
win1251ukr
. Consulte
Sección 5.9.1, “El conjunto de caracteres utilizado para datos y ordenación”.
En MySQL 5.0 también puede especificarse el tipo de
comparación (collation) estándar. MySQL utiliza la
comparación latin1_swedish_ci
por
defecto. Para cambiar esto se emplea la opción
--with-collation
:
shell> ./configure --with-collation=COLLATION
Para cambiar tanto el conjunto de caracteres como la forma
de comparación, se usan ambas opciones
--with-charset
y
--with-collation
. La forma de
comparación debe ser apropiada para el conjunto de
caracteres. (Para determinar qué tipos están disponibles
para cada conjunto de carcateres se usa la sentencia
SHOW COLLATION
).
Si se desean convertir caracteres entre el servidor y el
cliente, se debería revisar la sentencia SET
CHARACTER SET
. Consulte
Sección 13.5.3, “Sintaxis de SET
”.
Advertencia: si se cambia
el conjunto de caracteres luego de haber creado tablas, se
debe ejecutar myisamchk -r -q
--set-character-set=charset
en cada tabla. De otro modo, los
índices podrían quedar incorrectamente ordenados. (Esto
puede ocurrir si se instala MySQL, se crean algunas tablas,
se reconfigura MySQL para usar un conjunto de caracteres
diferente, y se lo reinstala).
Con la opción de configure
--with-extra-charsets=
,
pueden definirse conjuntos de caracteres adicionales para
ser compilados dentro del servidor.
LIST
LIST
debe ser uno de los
siguientes:
una lista de nombres de conjuntos de caracteres separados por espacios
complex
- para incluir todos los
conjuntos de caracteres que no pueden ser cargados
dinámicamente
all
- para incluir en los binarios
todos los conjuntos de caracteres.
Para configurar MySQL con código de depuración, debe
usarse la opción --with-debug
:
shell> ./configure --with-debug
Esto causa la inclusión de un asignador de memoria seguro que puede detectar algunos errores y brinda información de lo que está ocurriendo. Consulte Sección D.1, “Depurar un servidor MySQL”.
Si los programas cliente utilizan subprocesos (threads),
también se deberá compilar una versión a prueba de
subprocesos (thread-safe) de la biblioteca cliente de MySQL,
con la opción de configure
--enable-thread-safe-client
. Esto crea
una biblioteca libmysqlclient_r
con la
cual se podrán enlazar las aplicaciones que emplean
subprocesos. Consulte Sección 24.3.15, “Cómo hacer un cliente multihilo”.
Ahora, a partir de MySQL 5.0.4, es posible generar a MySQL
5.0 con soporte para tablas grandes, utilizando la opción
--with-big-tables
.
Esta opción tiene por efecto que las variables utilizadas
para llevar la cuenta de las filas de tablas se almacenen
empleando un tipo unsigned long long
en
lugar de unsigned long
. Esto permite
mantener tablas con hasta aproximadamente 1.844E+19
((232)2)
registros en vez de 232
(~4.295E+09). Antes se hacía necesario pasar al compilador
el argumento -DBIG_TABLES
en forma manual
con el fin de habilitar la misma característica.
Las opciones que pertenezcan a un sistema en particular se hallan en la sección de este manual dedicada específicamente a ese sistema. Consulte Sección 2.12, “Notas específicas sobre sistemas operativos”.
Atención: Se debe leer esta sección únicamente si se está interesado en colaborar con MySQL AB en la prueba de código nuevo. Si solamente se desea obtener MySQL para ejecutarlo en un sistema, se debe emplear una distribución estándar (ya sea binaria o de código fuente).
Para obtener el directorio de desarrollo más reciente, se deben seguir estas instrucciones:
Descargar el cliente gratuito BitKeeper desde http://www.bitmover.com/bk-client.shar.
En Unix, instalar el cliente gratuito de esta manera:
shell> sh bk-client.shar shell> cd bk_client-1.1 shell> make all shell> PATH=$PWD:$PATH
En Windows, instalarlo de esta manera:
Descargar e instalar Cygwin desde http://cygwin.com.
Asegurarse de que gcc
fue instalado
bajo Cygwin. Esto se comprueba emitiendo which
gcc
. Si no está instalado, ejecutar el gestor
de paquetes (package manager) de Cygwin, seleccionar
gcc
, e instalarlo.
Bajo Cygwin, llevar a cabo estos pasos:
shell> sh bk-client.shar shell> cd bk_client-1.1
Luego, editar el fichero Makefile
y
modificar la línea que lee $(CC) $(CFLAGS) -o
sfio -lz sfio.c
para que quede así:
$(CC) $(CFLAGS) -o sfio sfio.c -lz
Ejecutar el comando make y establecer la ruta:
shell> make all shell> PATH=$PWD:$PATH
Después que el cliente gratuito BitKeeper se haya instalado, dirigirse en primer lugar al directorio desde donde se desea trabajar y utilizar el siguiente comando para hacer una copia local de la rama de MySQL 5.0:
shell> sfioball -r+ bk://mysql.bkbits.net/mysql-5.0 mysql-5.0
Normalmente, no es necesario generar la documentación, dado
que ya es suministrada en una variedad de formatos en
http://dev.mysql.com/doc/. Los formatos que
pueden descargarse allí (HTML, PDF, etc.) están generados
diariamente, de modo que no se gana gran cosa generándola
en base a los documentos en formato XML DocBook que hay en
el directorio mysqldoc
. Si de todos modos
se deseara copiar el repositorio de documentación, debe
emplearse el siguiente comando:
shell> sfioball -r+ bk://mysql.bkbits.net/mysqldoc mysqldoc
En el ejemplo anterior, el árbol de código fuente se
establece dentro del subdirectorio
mysql-5.0/
dentro del
Si se está detrás de un firewall y solamente pueden iniciarse conexiones HTTP, BitKeeper también puede usarse sobre HTTP.
Si se necesita usar un servidor proxy, establecer la
variable de entorno http_proxy
para
apuntar al mismo:
shell> export http_proxy="http://your.proxy.server:8080/"
Reemplazar bk://
con
http://
cuando se copie un repositorio.
Ejemplo:
shell> sfioball -r+ http://mysql.bkbits.net/mysql-5.0 mysql-5.0
La descarga inicial del árbol de código fuente puede llevar un tiempo, dependiendo de la velocidad de la conexión. Si es así, habrá que tener paciencia hasta completar la descarga.
Para actualizar la copia local del repositorio MySQL 5.0, debe emplearse este comando:
shell> update bk://mysql.bkbits.net/mysql-5.0
Son necesarios: GNU make, autoconf 2.58 (o posterior), automake 1.8, libtool 1.5, y m4 para ejecutar la siguiente serie de comandos. Aún cuando muchos sistemas operativos vienen con su propia implementación de make, hay muchas posibilidades de que la compilación falle con extraños mensajes de error. Por consiguiente, es muy recomendable utilizar GNU make (a veces llamado gmake) en lugar de otros.
Afortunadamente, un gran número de sistemas operativos se distribuyen con las herramientas GNU preinstaladas o proveen paquetes instalables de las mismas. En cualquier caso, pueden descargarse de las siguientes direcciones:
Para configurar MySQL 5.0, también se necesitará GNU bison 1.75 o posterior. Las versiones antiguas de bison pueden producir este error:
sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded
Nota: El mensaje es: "Error fatal: se ha excedido el tamaño máximo para la tabla (32767)". El tamaño máximo de la tabla no está realmente excedido, el mensaje es consecuencia de errores en versiones antiguas de bison.
El siguiente ejemplo muestra los comandos típicamente
requeridos para configurar un árbol de código fuente. El
primer comando cd
es para posicionarse en
el directorio de más alto nivel en el árbol, debe
reemplazarse mysql-5.0
con el nombre de
directorio apropiado.
shell> cd mysql-5.0 shell> bk -r edit shell> aclocal; autoheader shell> libtoolize --automake --force shell> automake --force --add-missing; autoconf shell> (cd innobase; aclocal; autoheader; autoconf; automake) shell> (cd bdb/dist; sh s_all) shell> ./configure # Add your favorite options here shell> make
O bien puede usarse BUILD/autorun.sh como un atajo para la siguiente secuencia de comandos:
shell> aclocal; autoheader shell> libtoolize --automake --force shell> automake --force --add-missing; autoconf shell> (cd innobase; aclocal; autoheader; autoconf; automake) shell> (cd bdb/dist; sh s_all)
La línea de comandos que cambia el directorio dentro de
innobase
y
bdb/dist
se usa para configurar los
motores de almacenamiento InnoDB
y
Berkeley DB (BDB
). Pueden omitirse si no
se necesita soporte para InnoDB
o
BDB
.
Si se obtienen algunos mensajes de error extraños durante este paso, debe verificarse si verdaderamente se encuentra instalado libtool.
En el subdirectorio BUILD/
se encuentra
una colección de scripts de configuración estándar
utilizados por MySQL AB. Es posible que resulte más
conveniente utilizar el script
BUILD/compile-pentium-debug
que el
conjunto de comandos antes mencionado. Para compilar en una
arquitectura diferente, debe modificarse el script
eliminando los flags que son específicos de Pentium.
Cuando la generación esté concluida, debe ejcutarse
make install. Debe tenerse cuidado con
esto al aplicarlo en un ordenador en producción; los
comandos pueden sobreeescribir la instalación en uso. Si
hay otra instalación de MySQL, se recomienda ejecutar
./configure con valores diferentes para
las opciones --prefix
,
--with-tcp-port
, y
--unix-socket-path
que aquellos empleados
en el servidor en producción.
Ahora se debe "jugar" con la nueva instalación e intentar que las nuevas características colapsen con algún error. Debe comenzarse por ejecutar make test. Consulte Sección 27.1.2, “El paquete de pruebas MySQL Test”.
Si se ha llegado a la etapa de make y la
distribución no se compila, debe informarse en la base de
datos de errores en http://bugs.mysql.com/.
Si se han instalado las últimas versiones de las
herramientas GNU necesarias, y estas caen al intentar
procesar los ficheros de configuración provistos, también
debe informarse. Sin embargo, si se ejecuta
aclocal
y se obtiene un error
command not found
o similar, no debe
informarse. En su lugar, hay que asegurarse de que todas las
herramientas necesarias estén instaladas y que la variable
PATH
está correctamente establecida para
que el shell las pueda localizar.
Luego de la copia inicial del repositorio
(sfioball
) para obtener el árbol de
código fuente, se debe actualizar el repositorio
(update
) periódicamente para obtener
novedades.
Para examinar la historia de cambios del árbol, con todas
las diferencias, puede verse el fichero
BK/ChangeLog
localizado en el árbol de
código fuente y observar las descripciones
ChangeSet
listadas. Para examinar una
descripción changeset en particular, se utiliza el comando
sfioball para extraer dos revisiones del
árbol de código fuente, y luego se utiliza un comando
externo diff para compararlas. En caso de
hallar diferencias poco claras o tener preguntas acerca del
código, no debe dudarse en enviar un correo electrónico a
la lista de correo internals
de MySQL.
Consulte Sección 1.6.1.1, “Las listas de correo de MySQL”. Asimismo, si se
considera que se tiene una mejor idea sobre cómo realizar
algo, debe enviarse un mensaje de correo a la misma lista
con la corrección.
El cliente gratuito BitKeeper es ditribuido con su código fuente. La única documentación disponible para el cliente gratuito es el propio código fuente.
También pueden verse cambios, comentarios y código fuente a través de la Web. Para ver esta información en el caso de MySQL 5.0, dirigirse a http://mysql.bkbits.net:8080/mysql-5.0.
Todos los programas de MySQL se compilan en Solaris o Linux limpiamente, sin advertencias (warnings), utilizando gcc. En otros sistemas podrían emitirse advertencias debido a diferencias en los ficheros de cabecera del sistema. Consulte Sección 2.8.5, “Notas sobre MIT-pthreads” para advertencias que pueden emitirse al usar MIT-pthreads. Para otros problemas, debe verificarse la siguiente lista.
La solución a muchos problemas incluye la reconfiguración. Si se necesita reconfigurar, hay que tomar nota de lo siguiente:
Si se ejecuta configure después de
habérselo ejecutado anteriormente, éste puede emplear
información recogida durante la primera vez. Esta
información se almacena en
config.cache
. Cuando se inicia
configure, busca aquel fichero y lee su
contenido si existe, suponiendo que la información
continúa siendo válida. Esa suposición es incorrecta
cuando se ha reconfigurado.
Cada vez que se ejecuta configure, se debe ejecutar make nuevamente para recompilar. Sin embargo, primero se podría desear eliminar ficheros objeto antiguos, pertenecientes a procesos de generación anteriores, ya que fueron compilados utilizando diferentes opciones de configuración.
Para evitar que se utilicen información de configuración o ficheros objeto antiguos, deben ejecutarse estos comandos antes de volver a ejecutar configure:
shell> rm config.cache shell> make clean
Alternativamente, puede utilizarse make distclean.
La siguiente lista enumera los problemas más comunes al compilar MySQL:
Si se obtienen errores como los que se muestran cuando se
compila sql_yacc.cc
, probablemente se
trate de memoria insuficiente o espacio de intercambio
insuficiente:
Internal compiler error: program cc1plus got fatal signal 11 Out of virtual memory Virtual memory exhausted
El problema es que gcc necesita enormes
cantidades de memoria para compilar
sql_yacc.cc
con funciones "inline".
Inténtese ejecutar configure con la
opción --with-low-memory
:
shell> ./configure --with-low-memory
Esta opción causa que -fno-inline
se
agregue a los argumentos del compilador si se está
utilizando gcc, y -O0
si se está utilizando cualquier otro. Se debería probar la
opción --with-low-memory
aún si se
tiene tanta cantidad de memoria de espacio de intercambio
que no parece posible que sean insuficientes. Este problema
se ha observado inclusive en sistemas con configuraciones de
hardware generosas. y la opción
--with-low-memory
usualmente lo repara.
Por defecto, configure asume
c++ como nombre del compilador y GNU
c++ enlaza con -lg++
.
Si se está empleando gcc, tal
comportamiento puede causar problemas como este durante la
configuración:
configure: error: installation or configuration problem: C++ compiler cannot create executables.
También se podrían observar problemas durante la
compilacion relacionados con g++,
libg++
, o libstdc++
.
Una causa para estos problemas es que no se tenga
g++, o quizá se tenga
g++ pero no libg++
, o
libstdc++
. Se debe inspeccionar el
fichero config.log
. Este debería
contener el motivo exacto por el cual el compilador de C++
no está funcionando. Para eludir estos problemas, se puede
utilizar gcc como compilador de C++. Debe
ponerse en la variable de entorno CXX
el
valor "gcc -O3"
. Por ejemplo:
shell> CXX="gcc -O3" ./configure
Esto funciona porque gcc compila código
C++ tan bien como g++, pero no enlaza por
defecto con las bibliotecas libg++
o
libstdc++
.
Otra forma de solucionar el problema es instalar
g++, libg++
, y
libstdc++
. Sin embargo, se recomiendo no
emplear libg++
o
libstdc++
con MySQL porque sólo
incrementará el tamaño del ejecutable sin obtener ningún
beneficio. Algunas versiones de estas bibliotecas también
han causado en el pasado problemas extraños a los usuarios
de MySQL.
Si la compilación fallara por errores como cualquiera de los siguientes, se debe actualizar la versión de make a GNU make:
making all in mit-pthreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment
O bien:
make: file `Makefile' line 18: Must be a separator (:
O bien:
pthread.h: No such file or directory
Se sabe que los programas make de Solaris y FreeBSD son problemáticos.
La versión 3.75 de GNU make funciona correctamente.
Si se desean definir flags para ser usados por los
compiladores de C o C++, se debe hacer agregando los flags a
las variables de entorno CFLAGS
y
CXXFLAGS
. De este mismo modo pueden
especificarse los nombres del compilador utilizando
CC
y CXX
. Por ejemplo:
shell> CC=gcc shell> CFLAGS=-O3 shell> CXX=gcc shell> CXXFLAGS=-O3 shell> export CC CFLAGS CXX CXXFLAGS
Consulte Sección 2.1.2.5, “Binarios de MySQL compilados por MySQL AB” para una lista de definiciones de flags que han resultado útiles en varios sistemas.
Si se obtiene un mensaje de error como este, se necesitará actualizar el compilador gcc:
client/libmysql.c:273: parse error before `__attribute__'
gcc 2.8.1 funciona correctamente, pero se recomienda utilizar gcc 2.95.2 o egcs 1.0.3a en su lugar.
Si se obtienen errores como los siguientes al compilar
mysqld, configure no
está detectando correctamente el tipo del último argumento
pasado a accept()
,
getsockname()
, o
getpeername()
:
cxx: Error: mysqld.cc, line 645: In this statement, the referenced type of the pointer value ''length'' is ''unsigned long'', which is not compatible with ''int''. new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
Para corregir esto, debe modificarse el fichero
config.h
(el cual es generado por
configure). Deben buscarse estas líneas:
/* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXX
Hay que cambiar XXX
por
size_t
o int
,
dependiendo del sistema operativo. (Tener en cuenta que esto
debe hacerse cada vez que se ejecuta
configure, porque este regenera el
fichero config.h
.)
El fichero sql_yacc.cc
se genera a
partir de sql_yacc.yy
. Normalmente el
proceso de compilación no necesita crear
sql_yacc.cc
, porque MySQL viene con una
copia ya generada. Sin embargo, si se necesita crearlo de
nuevo, se podría hallar este error:
"sql_yacc.yy", line xxx
fatal: default action causes potential...
Este es un síntoma de que se posee una versión deficiente de yacc. Posiblemente se necesite instalar en su lugar bison (la versión GNU de yacc).
En Linux Debian 3.0, se necesita instalar
gawk
en lugar del predeterminado
mawk
si se desea compilar MySQL 5.0 con
soporte para Bases de Datos Berkeley.
Si se necesita depurar mysqld o un
cliente MySQL, ejecutar configure con la
opción --with-debug
, luego recompilar y
enlazar los clientes con la nueva biblioteca. Consulte
Sección D.2, “Depuración de un cliente MySQL”.
Si se obtiene un error de compilación en Linux (por ejemplo, en Linux SuSE 8.1 o Linux RedHat 7.2) similar a los siguientes:
libmysql.c:1329: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type libmysql.c:1329: too few arguments to function `gethostbyname_r' libmysql.c:1329: warning: assignment makes pointer from integer without a cast make[2]: *** [libmysql.lo] Error 1
Por defecto, el script configure intenta determinar el número correcto de argumentos empleando g++, el compilador C++ GNU. Este proceso arroja resultados incorrectos si no está instalado g++. Hay dos formas de solucionar esto:
Asegurarse de que GNU C++ g++ está
instalado. En algunas distribuciones de Linux, el
paquete que se necesita se llama gpp
;
en otras, se llama gcc-c++.
Para utilizar gcc como compilador de
C++ se debe poner en la variable de entorno
CXX
el valor gcc:
export CXX="gcc"
Después debe volver a ejecutarse configure.
Esta sección describe alguno de los probleas que pueden ocurrir al utilizar MIT-pthreads.
En Linux, no se deberían utilizar MIT-pthreads. En su lugar, utilizar la implementación de LinuxThreads instalada. Consulte Sección 2.12.1, “Notas sobre Linux”.
Si el sistema no provee soporte nativo para subprocesos, se necesita compilar MySQL utilizando el paquete MIT-pthreads. Esto incluye a antiguos sistemas FreeBSD, SunOS 4.x, Solaris 2.4 y anteriores, y algunos otros. Consulte Sección 2.1.1, “Sistemas operativos que MySQL soporta”.
El paquete MIT-pthreads no es parte de la distribución de código fuente de MySQL 5.0. Si se lo necesita, habrá que descargarlo desde http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz.
Luego de la descarga, debe expandirse dentro del más alto nivel
del directorio de código fuente de MySQL. Creará un nuevo
subdirectorio llamado mit-pthreads
.
En la mayoría de los sistemas, para forzar el uso de
MIT-pthreads se debe ejecutar configure
con la opción --with-mit-threads
.
shell> ./configure --with-mit-threads
La generación (building) en un directorio que no sea de código fuente no está soportada cuando se usan MIT-pthreads porque se desea minimizar los cambios al código.
La comprobación que determina si se utilizará MIT-pthreads
sucede únicamente durante la parte del proceso de
configuración que tiene que ver con el código del
servidor. Si se ha configurado la distribución empleando
--without-server
para generar solamente
el código del cliente, los clientes no saben si se está
utilizando MIT-pthreads y emplean conexiones socket Unix por
defecto. Dado que los ficheros socket de Unix no funcionan
bajo MIT-pthreads en algunas plataformas, esto significa que
se deberá utilizar -h
o
--host
cuando se ejecuten programas
cliente.
Cuando se compila MySQL empleado MIT-pthreads, el bloqueo de
sistema se deshabilita por defecto por razones de
rendimiento. Se le puede indicar al servidor que emplee
bloqueo de sistema con la opción
--external-locking
. Esto es necesario
solamente si se desea poder ejecutar dos servidores MySQL
sobre los mismos ficheros de datos, lo cual no es
recomendable.
Algunas veces, el comando bind()
de
pthread falla al adosarse a un socket sin emitir mensajes de
error (al menos en Solaris). El resultado es que todas las
conexiones al servidor fallan. Por ejemplo:
shell> mysqladmin version mysqladmin: connect to server at '' failed; error: 'Can't connect to mysql server on localhost (146)'
La solución a esto es finalizar el servidor mysqld y reiniciarlo. Esto ha ocurrido solamente cuando se ha detenido el servidor por la fuerza y se lo ha reiniciado inmediatamente.
Con MIT-pthreads, la llamada de sistema
sleep()
no es interrumpida con
SIGINT
(interrupción). Esto solamente es
perceptible cuando se ejecuta mysqladmin
--sleep. Se debe esperar a que la llamada
sleep()
termine antes de que el pedido de
interrupción sea atendido y el proceso se detenga.
Durante el enlazado, se pueden recibir mensajes de advertencia como los siguientes (al menos en Solaris); deben ser ignorados.
ld: warning: symbol `_iob' has differing sizes: (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken ld: warning: symbol `__iob' has differing sizes: (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
Algunas otras advertencias también deben ignorarse:
implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
No se ha podido hacer funcionar readline
con MIT-pthreads. (Esto no es necesario, pero podría ser de
interés para alguien).
Estas instrucciones describen como generar los binarios de MySQL a partir del código fuente de la versión 5.0 en Windows. Las instrucciones que se proveen sirven para generar los binarios a partir de una distribución estándar de código fuente o a partir del árbol de BitKeeper que contiene el último código fuente en desarrollo.
Nota: Las instrucciones en este documento son estrictamente para usuarios que deseen probar MySQL en Windows a partir de la última distribución en código fuente o proveniente del árbol BitKeeper. Para usos en producción, MySQL AB no aconseja utilizar un servidor MySQL generado por el usuario a partir del código fuente. Normalmente, es mejor emplear distribuciones binarias precompiladas de MySQL las cuales MySQL AB genera específicamente para un rendimiento óptimo en Windows. Las instrucciones para instalar distribuciones binarias se enecuentran en Sección 2.3, “Instalar MySQL en Windows”.
Para generar MySQL en Windows a partir del código fuente, se necesita que el siguiente compilador y recursos estén disponibles en el sistema:
Compilador VC++ 6.0 (actualizado con SP4 o SP5 y paquete pre-procesador). El paquete pre-procesador se necesita para el macro assembler. Para más detalles consulte http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/faq.aspx.
Aproximadamente 45MB de espacio en disco.
64MB de RAM.
También se necesitará una distribución MySQL de código fuente para Windows. Hay dos formas de obtener una distribución de código fuente de MySQL 5.0:
Obtener una distribución de código fuente preparada por MySQL AB desde http://dev.mysql.com/downloads/.
Preparar una distribución de código fuente a partir del último arbol BitKeeper de código en desarrollo. Si se planea hacer esto, habrá que crear el paquete en un sistema Unix y luego transferirlo al sistema Windows. (La razón para esto es que algunas de las configuraciones y etapas de la generación requieren herramientas que funcionan solamente en Unix.) El uso de BitKeeper requiere:
Un sistema ejecutando Unix o un sistema operativo similar, como Linux.
Bitkeeper 3.0 instalado en ese sistema. Consulte Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo” para instrucciones sobre la descarga e instalación de BitKeeper.
si se está empleando una distribución de código fuente Windows, se puede ir directamente a Sección 2.8.6.1, “Generar MySQL usando VC++”. Para generar a partir del árbol de BitKeeper, proceder según Sección 2.8.6.2, “Crear un paquete de código fuente Windows a partir de la última fuente de desarrollo”.
Si algo no funciona como se esperaba, o se tienen sugerencias
para hacer respecto a formas de mejorar el actual proceso de
compilación en Windows, debe enviarse un mensaje a la lista de
correo win32
. Consulte
Sección 1.6.1.1, “Las listas de correo de MySQL”.
Note: Los ficheros de espacio de trabajo (workspace) de VC++ para MySQL 5.0 son compatibles con Microsoft Visual Studio 6.0 y ediciones posteriores (7.0 / .NET); estos ficheros son probados por el personal de MySQL AB antes de cada release.
Debe seguirse este procedimiento para generar MySQL:
Crear un directorio de trabajo (por ejemplo
C:\workdir
).
Expandir la distribución de código fuente en el
mencionado directorio, utilizando
WinZip u otra herramienta para Windows
que pueda leer ficheros .zip
.
Ejecutar Visual Studio
En el menú
.
Abrir el espacio de trabajo mysql.dsw
que se hallará en el directorio de trabajo.
En el menú
, seleccionar el menú .Seleccionar
y hacer click en .Presionar F7 para comenzar la compilación del servidor de depuración, bibliotecas, y algunas aplicaciones cliente.
Del mismo modo se compila la versión release.
Las versiones de depuración de los programas y las
bibliotecas se encuentran en los directorios
client_debug
y
lib_debug
. Las versiones release de
los programas y las bibliotecas se encuentran en los
directorios client_release
y
lib_release
. Si se desean generar
tanto la versión de depuración como la de release, se
puede seleccionar la opción
del menú .
Probar el servidor. El servidor generado mediante las
instrucciones anteriores espera que el directorio de MySQL
y el directorio de datos sean
C:\mysql
y
C:\mysql\data
por defecto. Si se
desea probar el servidor empleado el directorio raíz del
árbol de código fuente como directorio base y de datos,
se le deben indicar sus rutas al servidor. Esto puede
hacerse desde la línea de ocmandos con las opciones
--basedir
y
--datadir
, o colocando las opciones
apropiadas en un fichero de opciones (el fichero
my.ini
dentro del directorio Windows
o bien C:\my.cnf
). También podría
especificarse la ruta a un directorio de datos existente
con anterioridad.
Iniciar el servidor desde el directorio
client_release
o
client_debug
dependiendo de cuál se
quiera utilizar. Las instrucciones generales para el
inicio del servidor se encuentran en
Sección 2.3, “Instalar MySQL en Windows”. Las instrucciones
deberán adaptarse si se desea utilizar un directorio base
o directorio de datos diferente.
Cuando el servidor se esté ejecutando en modo autónomo o
como un servicio basado en la configuración establecida,
intentar conectarse a él desde la utilidad interactiva de
línea de comandos mysql, que se
encuentra en el directorio
client_release
o
client_debug
.
Cuando se esté satisfecho con el funcionamiento de los programas compilados, detener el servidor. Entonces, instalar MySQL de la siguiente manera:
Crear los directorios donde se desea instalar MySQL. Por
ejemplo, para instalarlo en C:\mysql
,
emplear estos comandos:
C:\> mkdir C:\mysql C:\> mkdir C:\mysql\bin C:\> mkdir C:\mysql\data C:\> mkdir C:\mysql\share C:\> mkdir C:\mysql\scripts
Si se desean compilar otros clientes y enlazarlos con MySQL, se deberían también crear varios directorios adicionales:
C:\> mkdir C:\mysql\include C:\> mkdir C:\mysql\lib C:\> mkdir C:\mysql\lib\debug C:\> mkdir C:\mysql\lib\opt
Si se desean efectuar pruebas de rendimiento de MySQL, crear este directorio:
C:\> mkdir C:\mysql\sql-bench
Las pruebas de rendimiento requieren soporte para Perl. Consulte Sección 2.13, “Notas sobre la instalación de Perl”.
Desde el directorio workdir
, deben
copiarse dentro de C:\mysql
los
siguientes directorios:
C:\> cd \workdir C:\workdir> copy client_release\*.exe C:\mysql\bin C:\workdir> copy client_debug\mysqld.exe C:\mysql\bin\mysqld-debug.exe C:\workdir> xcopy scripts\*.* C:\mysql\scripts /E C:\workdir> xcopy share\*.* C:\mysql\share /E
Si se desean compilar otros clientes y enlazarlos a MySQL, también se deberían copiar varias bibliotecas y ficheros de cabecera:
C:\workdir> copy lib_debug\mysqlclient.lib C:\mysql\lib\debug C:\workdir> copy lib_debug\libmysql.* C:\mysql\lib\debug C:\workdir> copy lib_debug\zlib.* C:\mysql\lib\debug C:\workdir> copy lib_release\mysqlclient.lib C:\mysql\lib\opt C:\workdir> copy lib_release\libmysql.* C:\mysql\lib\opt C:\workdir> copy lib_release\zlib.* C:\mysql\lib\opt C:\workdir> copy include\*.h C:\mysql\include C:\workdir> copy libmysql\libmysql.def C:\mysql\include
Si se desean efectuar pruebas de rendimiento de MySQL, también debe hacerse lo siguiente:
C:\workdir> xcopy sql-bench\*.* C:\mysql\bench /E
Configurar e iniciar el servidor del mismo modo que para la distribución binaria para Windows. Consulte Sección 2.3, “Instalar MySQL en Windows”.
Para crear un paquete de código fuente Windows a partir del árbol BitKeeper actual, deben seguirse las siguientes instrucciones. Este procedimiento debe llevarse a cabo en un sistema con Unix o un sistema operativo estilo Unix. Por ejemplo, este procedimiento funciona bien en Linux.
Copiar el árbol de código fuente BitKeeper para MySQL 5.0. Para más información sobre cómo copiar el árbol de código fuente, consulte las instrucciones en Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”.
Configurar y generar la distribución de modo que se tenga un servidor ejecutable para trabajar con él. Una forma de lograr esto es ejecutar el siguiente comando en el directorio de más alto nivel del árbol de código fuente:
shell> ./BUILD/compile-pentium-max
Luego de asegurarse que el proceso de generación se completó con éxito, ejecutar el siguiente script en el directorio de más alto nivel del árbol de código fuente:
shell> ./scripts/make_win_src_distribution
Este script crea un paquete de código fuente Windows para ser usado en un sistema Windows. Se le pueden pasar diferentes opciones al script según las necesidades que se tengan. El script acepta las siguientes opciones:
--help
Muestra un mensaje de ayuda.
--debug
Imprime información acerca de las operaciones que realiza el script, sin crear el paquete.
--tmp
Especifica una ubicación temporal.
--suffix
Sufijo para el nombre del paquete.
--dirname
Nombre del directorio (intermedio) para copiar ficheros.
--silent
No imprime la lista de ficheros procesados.
--tar
Crea un paquete tar.gz
en lugar
de uno .zip
.
Por defecto, make_win_src_distribution
crea un fichero en formato Zip con el nombre
mysql-
,
donde VERSION
-win-src.zipVERSION
es la versión
del árbol de código fuente.
Copiar o subir al ordenador Windows el paquete de código fuente Windows que se acaba de crear. Para compilarlo, utilizar las instrucciones en Sección 2.8.6.1, “Generar MySQL usando VC++”.
En los ficheros de código fuente, se debería incluir
my_global.h
antes de
mysql.h
:
#include <my_global.h> #include <mysql.h>
my_global.h
incluye cualquier otro fichero
necesario para compatibilidad con Windows (como
windows.h
) si el programa se compilará en
Windows.
Se puede enlazar el código con la biblioteca dinámica
libmysql.lib
, la cual es solamente un
wrapper para cargar libmysql.dll
sobre
demanda, o con la biblioteca estática
mysqlclient.lib
.
Las bibliotecas cliente de MySQL están compiladas como bibliotecas con uso de subprocesos, por lo tanto el código del usuario también debería ser multi-hilo.
Luego de instalar MySQL, hay algunos temas a los que hay que dirigir la atención. Por ejemplo, en Unix, se debería inicializar el directorio de datos y crear las tablas de permisos MySQL. En todas las plataformas, una cuestión importante de seguridad es que, inicialmente, las cuentas en las tablas de permisos no tienen contraseñas. Se deberían asignar contraseñas para evitar accesos no autorizados al servidor MySQL. Se pueden crear tablas de zonas horarias (time zone) para habilitar el reconocimiento de zonas horarias con nombre. (Actualmente, estas tablas solamente pueden llenarse en Unix. Este problema será revisado pronto en Windows).
Las siguientes secciones incluyen procedimientos de pos-instalación que son específicos de sistemas Windows y Unix. Otra sección, Sección 2.9.2.3, “Arrancar y resolver problemas del servidor MySQL”, se aplica a todas las plataformas; describe que hacer si ocurren problemas al tratar de iniciar el servidor. Sección 2.9.3, “Hacer seguras las cuentas iniciales de MySQL” también se aplica a todas las plataformas. Se deberían seguir estas instrucciones para asegurarse de que las cuentas MySQL están correctamente protegidas mediante contraseñas.
Cuando se esté listo para crear cuentas de usuario adicioniales, se podrá encontrar información sobre el sistema de control de acceso de MySQL y administración de cuentas en Sección 5.6, “El sistema de privilegios de acceso de MySQL” y Sección 5.7, “Gestión de la cuenta de usuario MySQL”.
En Windows, el directorio de datos y la tabla de permisos no
necesitan ser creados. MySQL para Windows incluye la tabla de
permisos con un conjunto de cuentas ya inicializadas en la base
de datos mysql
, dentro del directorio de
datos. Al contrario que en Unix, no se debe ejecutar el script
mysql_install_db. Sin embargo, si no se
instala MySQL utilizando el ASistente de Instalación, se
deberían establecer contraseñas para proteger las cuentas.
Consulte Sección 2.3.4.1, “Introducción”. El
procedimiento para hacerlo está en
Sección 2.9.3, “Hacer seguras las cuentas iniciales de MySQL”.
Antes de establecer passwords, se podría desear ejecutar algunos programas cliente para asegurarse de que hay conexión con el servidor y que éste se encuentra funcionando correctamente. Tras cerciorarse de que el servidor está ejecutándose (consultar Sección 2.3.10, “Arrancar el servidor la primera vez”), se utilizarían los siguientes comandos para verificar que se puede traer información desde el mismo. La salida por pantalla debe ser similar a esto:
C:\> C:\mysql\bin\mysqlshow +-----------+ | Databases | +-----------+ | mysql | | test | +-----------+ C:\> C:\mysql\bin\mysqlshow mysql Database: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ C:\> C:\mysql\bin\mysql -e "SELECT Host,Db,User FROM db" mysql +------+-------+------+ | host | db | user | +------+-------+------+ | % | test% | | +------+-------+------+
Si se está empleando una versión de Windows que soporta servicios, y se desea que el servidor se ejecute automáticamente al iniciarse Windows, consulte Sección 2.3.12, “Arrancar MySQL como un servicio de Windows”.
Luego de instalar MySQL en Unix, se necesita inicializar las tablas de permisos, ejecutar el servidor, y asegurarse de que éste funciona correctamente. También se podría desear que el servidor se inicie y detenga automáticamente cuando lo haga el sistema. Se deben asignar contraseñas a las cuentas en las tablas de permisos.
En Unix, las tablas de permisos se configuran mediante el programa mysql_install_db. En algunos métodos de instalación, este programa se ejecuta automáticamente.
Si se instala MySQL en Linux a partir de una distribución RPM, el servidor RPM ejecuta mysql_install_db.
Si se instala MySQL en Mac OS X a partir de una distribución PKG, el instalador ejecuta mysql_install_db.
En otro caso, será necesario ejecutar manualmente mysql_install_db.
El siguiente procedimiento describe cómo inicializar las tablas de permisos (si no se hizo anteriormente) y luego iniciar el servidor. También sugiere posibles comandos a utilizar para verificar que el servidor está accesible y en correcto funcionamiento. Para información relativa a iniciar y detener el servidor automáticamente, consulte Sección 2.9.2.2, “Arrancar y parar MySQL automáticamente”.
Luego de completar el procedimiento y tener el servidor en funcionamiento, se deberían asignar contraseñas a las cuentas creadas por mysql_install_db. Las instrucciones para hacerlo se hallan en Sección 2.9.3, “Hacer seguras las cuentas iniciales de MySQL”.
En los ejemplos mostrados, el servidor se ejecuta bajo el
identificador de usuario de la cuenta de inicio de sesión
mysql
. Se asume que dicha cuenta existe. La
cuenta mysql
puede haber sido creda
especialmente o bien originarse al cambiar el nombre de una
cuenta existente.
Posicionarse en el nivel más alto del directorio de
instalación de MySQL, representado por
BASEDIR
:
shell> cd BASEDIR
BASEDIR
muy probablemente se
reemplace por algo similar a
/usr/local/mysql
o
/usr/local
. Los siguientes pasos asumen
que se está en este directorio.
De ser necesario, ejecutar el programa mysql_install_db para establecer las tablas de permisos MySQL iniciales, las que contienen los privilegios que determinan qué usuarios están autorizados a conectarse al servidor. Habrá que ejecutarlo si se utilizó una distribución que no lo hace automáticamente.
Por lo general, mysql_install_db sólo requiere ser ejecutado la primera vez que se instala MySQL, de modo que este paso puede obviarse si se está actualizando una instalación existente. No obstante, mysql_install_db no sobreescribe ninguna tabla, por lo tanto, es seguro utilizarlo en cualquier circunstancia.
Para inicializar las tablas de permisos se utilizará uno de
los siguientes comandos, dependiendo de si
mysql_install_db se encuentra en el
directorio bin
o
scripts
:
shell> bin/mysql_install_db --user=mysql shell> scripts/mysql_install_db --user=mysql
El script mysql_install_db crea el
directorio de datos, la base de datos
mysql
que almacena todos los privilegios
para el servidor, y la base de datos test
que puede emplearse para probar MySQL. El script también
crea entradas en la tabla de permisos para la cuenta
root
y la cuenta de usuario anónimo. Las
cuentas no están protegidas por contraseña en un
principio. Una descripción de los permisos que tienen se
encuentra en Sección 2.9.3, “Hacer seguras las cuentas iniciales de MySQL”.
Brevemente, estos privilegios le permiten al usuario
root
de MySQL hacer cualquier cosa, y le
permiten a cualquier usuario de MySQL crear o utilizar bases
de datos cuyo nombre sea test
o comience
con test_
.
Es importante asegurarse de que los directorios y ficheros
de bases de datos tienen como propietario a la cuenta de
inicio de sesión mysql
, para que el
servidor tenga acceso de lectura y escritura a los mismos.
Para cerciorarse de esto, si
mysql_install_db se ejecuta mientras se
está como root
del sistema operativo,
hay que usar la opción --user
como se
muestra. En otro caso, el script se deberá ejecutar
mientras se está como usuario mysql
del
sistema operativo, en cuyo caso se puede omitir la opción
--user
.
mysql_install_db crea varias tablas en la
base de datos mysql
, incluyendo
user
, db
,
host
, tables_priv
,
columns_priv
, y func
,
entre otras. Consulte Sección 5.6, “El sistema de privilegios de acceso de MySQL”
para una descripción completa.
Si no se desea tener la base de datos
test
, se la puede eliminar con
mysqladmin -u root drop test luego de
iniciar el servidor.
Si ocurren problemas con mysql_install_db, consulte Sección 2.9.2.1, “Problemas en la ejecución de mysql_install_db”.
Hay algunas alternativas para ejecutar el script mysql_install_db que se provee con la distribución de MySQL:
Si se desea que los privilegios iniciales sean
diferentes de los establecidos por defecto, se puede
modificar mysql_install_db antes de
ejecutarlo. Sin embargo, es preferible utilizar
GRANT
y REVOKE
para modificar los privilegios
después que las tablas de permisos
se hayan creado. En otras palabras, se puede ejecutar
mysql_install_db, y posteriormente
emplear mysql -u root mysql
para
conectarse al servidor como usuario
root
de MySQL y aplicar las
sentencias GRANT
y
REVOKE
que sean necesarias.
Si se desea instalar MySQL en varios ordenadores con los
mismos privilegios, se pueden colocar las sentencias
GRANT
y REVOKE
en
un fichero y ejecutarlo como un script utilizando
mysql
después de ejecutar
mysql_install_db. Por ejemplo:
shell> bin/mysql_install_db --user=mysql shell> bin/mysql -u root < your_script_file
De este modo se evita tipear las sentencias en cada ordenador.
Es posible regenerar las tablas de permisos
completamente aunque ya estén creadas. Se puede
necesitar esto si se está aprendiendo a usar
GRANT
y REVOKE
y
se han hecho tantas modificaciones tras la ejecución de
mysql_install_db que se desea vaciar
las tablas de permisos y comenzar de nuevo.
Para regenerar las tablas de permisos, eliminar todos
los ficheros .frm
,
.MYI
, y .MYD
en el directorio que contiene la base de datos
mysql
. (Este es el directorio llamado
mysql
dentro del directorio de
datos, el cual aparece listado como el valor
datadir
cuando se ejecuta
mysqld --help.) Luego debe ejecutarse
nuevamente el script mysql_install_db
Se puede iniciar mysqld manualmente
utilizando la opción
--skip-grant-tables
e ingresar los
permisos manualmente utilizando
mysql:
shell> bin/mysqld_safe --user=mysql --skip-grant-tables & shell> bin/mysql mysql
Desde mysql, ejecutar manualmente los comandos contenidos en mysql_install_db. Al finalizar hay que asegurarse de ejecutar mysqladmin flush-privileges o mysqladmin reload para indicarle al servidor que lea nuevamente las tablas de permisos.
Nótese que al no utilizar mysql_install_db, no solamente hay que cargar manualmente el contenido de las tablas de permisos, sino que también hay que crearlas primero.
Iniciar el servidor MySQL:
shell> bin/mysqld_safe --user=mysql &
Es importante que el servidor MySQL sea ejecutado utilizando
una cuenta de sistema operativo sin privilegios (distinta a
root
). Para cerciorarse de esto, se debe
usar la opción --user
si se ejecuta
mysql_safe
habiendo iniciado sesión del
sistema operativo como root
. En otro
caso, se debería ejecutar el script mientras se ha iniciado
sesión como mysql
, en cuyo caso se puede
omitir la opción --user
.
Mayores instrucciones para ejecutar MySQL como un usuario sin privilegios se encuentran en Sección A.3.2, “Cómo ejecutar MySQL como usuario normal”.
Si se omite la creación de las tablas de permisos antes de llegar a este paso, aparecerá el siguiente mensaje en el fichero de registro de error cuando se inicie el servidor:
mysqld: Can't find file: 'host.frm'
Si ocurren otros problemas al iniciar el servidor, consulte Sección 2.9.2.3, “Arrancar y resolver problemas del servidor MySQL”.
Utilizar mysqladmin para verificar que el servidor se encuentra en ejecución. Los siguientes comandos proporcionan formas simples de saber si el servidor está activo y responde a conexiones:
shell> bin/mysqladmin version shell> bin/mysqladmin variables
La salida producida por mysqladmin version varía dependiendo de la plataforma y la versión de MySQL, pero debería ser similar a esto:
shell> bin/mysqladmin version mysqladmin Ver 8.41 Distrib 5.0.9-beta, for pc-linux-gnu on i686 Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license Server version 5.0.9-beta-Max Protocol version 10 Connection Localhost via UNIX socket UNIX socket /var/lib/mysql/mysql.sock Uptime: 14 days 5 hours 5 min 21 sec Threads: 1 Questions: 366 Slow queries: 0 Opens: 0 Flush tables: 1 Open tables: 19 Queries per second avg: 0.000
Para ver qué otras tareas pueden hacerse con
mysqladmin, se lo debe invocar con la
opción --help
.
Verificar que se pueda detener el servidor:
shell> bin/mysqladmin -u root shutdown
Verificar que se pueda reiniciar el servidor. Hacerlo mediante mysqld_safe o invocando directamente a mysqld. Por ejemplo:
shell> bin/mysqld_safe --user=mysql --log &
Si mysqld_safe fallara, consultar Sección 2.9.2.3, “Arrancar y resolver problemas del servidor MySQL”.
Ejecutar algunas pruebas sencillas para comprobar que se puede traer información desde el servidor. La salida debería ser similar a lo que se muestra aquí:
shell> bin/mysqlshow +-----------+ | Databases | +-----------+ | mysql | | test | +-----------+ shell> bin/mysqlshow mysql Database: mysql +---------------------------+ | Tables | +---------------------------+ | columns_priv | | db | | func | | help_category | | help_keyword | | help_relation | | help_topic | | host | | proc | | procs_priv | | tables_priv | | time_zone | | time_zone_leap_second | | time_zone_name | | time_zone_transition | | time_zone_transition_type | | user | +---------------------------+ shell> bin/mysql -e "SELECT Host,Db,User FROM db" mysql +------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+
Hay un conjunto de pruebas de rendimiento en el directorio
sql-bench
(dentro del directorio de
instalación de MySQL) que puede utilizarse para comparar el
desempeño de MySQL en distintas plataformas. Este conjunto
de pruebas está escrito en Perl. Utiliza el módulo Perl
DBI para proporcionar una interface independiente de la base
de datos a varias bases de datos, y algunos otros módulos
adicionales de Perl también son requeridos para ejecutar
las pruebas. Se deben tener los siguientes módulos
instalados:
DBI DBD::mysql Data::Dumper Data::ShowTable
Estos módulos pueden ser obtenidos desde CPAN (http://www.cpan.org/). También, consulte Sección 2.13.1, “Instalación de Perl en Unix”.
El directorio sql-bench/Results
contiene los resultados de muchas ejecuciones a través de
diferentes bases de datos y plataformas. Para ejecutar todos
los tests, deben introducirse estos comandos:
shell> cd sql-bench shell> perl run-all-tests
Si no se encuentra el directorio
sql-bench
, probablemente se ha
instalado MySQL empleando otros ficheros RPM que no son el
RPM de código fuente (El RPM de código fuente incluye el
directorio de pruebas de rendimiento
sql-bench
) En este caso, se deberá
primero instalar el conjunto de pruebas de rendimiento antes
de poder utilizarlo. Para MySQL 5.0, hay un RPM separado con
pruebas de rendimiento llamado
mysql-bench-
que contiene el código de prueba y los datos.
VERSION
-i386.rpm
Si se posee una distribución de código fuente, también
hay pruebas en su subdirectorio tests
.
Por ejemplo, para ejecutar
auto_increment.tst
, debe ejecutarse
este comando desde el directorio de más alto nivel en la
distribución de código fuente:
shell> mysql -vvf test < ./tests/auto_increment.tst
El resultado esperado del test se encuentra en el fichero
./tests/auto_increment.res
.
En este punto, se debería tener el servidor en funcionamiento. Sin embargo, ninguna de las cuentas iniciales de MySQL tiene una contraseña, así que se les debe asignar empleando las instrucciones halladas en Sección 2.9.3, “Hacer seguras las cuentas iniciales de MySQL”.
En MySQL 5.0, el procedimiento de instalación crea zonas
horarias en la base de datos mysql
. No
obstante, se deben llenar las tablas en forma manual. Las
instrucciones para hacerlo se encuentran en
Sección 5.9.8, “Soporte de zonas horarias en el servidor MySQL”.
El propósito del script mysql_install_db es generar tablas de permisos MySQL nuevas. No sobreescribe las tablas de permisos existentes ni afecta a otros datos.
Para crear nuevamente las tablas de privilegios, primero debe
detenerse el servidor mysqld si está
ejecutándose. Luego se renombra -para preservarlo- el
directorio mysql
que está dentro del
directorio de datos, y se ejecuta
mysql_install_db. Por ejemplo:
shell> mv mysql-data-directory/mysql mysql-data-directory/mysql-old shell> mysql_install_db --user=mysql
Esta sección detalla problemas que podrían hallarse cuando se ejecute mysql_install_db:
mysql_install_db falla al instalar las tablas de permisos
mysql_install_db puede fallar al instalar las tablas de permisos y finalizar despues de mostrar los siguientes mensajes:
Starting mysqld daemon with databases from XXXXXX mysqld ended
En tal caso, se debe examinar el fichero de registro de
errores muy cuidadosamente. El registro podría hallarse
en el directorio XXXXXX
con un nombre
similar al mensaje de error, y debería indicar el motivo
por el que mysqld no se inició. Si no
fuera de ayuda, habrá que enviar un informe de error
incluyendo el texto del registro. Consulte
Sección 1.6.1.3, “Cómo informar de bugs y problemas”.
Ya hay un proceso mysqld en ejecución
Esto indica que el servidor se está ejecutando, en cuyo caso las tablas de permisos probablemente ya se crearon. De ser así, no es necesario ejecutar mysql_install_db en absoluto, porque sólo se hace una vez (cuando se instala MySQL la primera vez).
No es posible instalar un segundo servidor mysqld cuando hay uno en ejecución.
Esto puede ocurrir cuando se tiene una instalación de MySQL y se desea realizar una nueva instalación en una ubicación diferente. Por ejemplo, se podría tener una instalación en producción y crear una segunda instalación con fines de prueba. Generalmente, el problema es que el segundo servidor intenta utilizar una interfaz de red que está siendo usada por el primero. En este caso se debería ver uno de los siguientes mensajes de error:
Can't start server: Bind on TCP/IP port: Address already in use Can't start server: Bind on unix socket...
Consulte Sección 5.11, “Ejecutar más de un servidor MySQL en la misma máquina” para ver instrucciones sobre la instalación de múltiples servidores.
No se tiene acceso de escritura a
/tmp
Si no se tiene acceso de escritura para crear ficheros
temporales o un fichero de socket Unix en la ubicación
por defecto (el directorio /tmp
),
ocurrirá un error al ejecutar
mysql_install_db o el servidor
mysqld.
Se pueden especificar distintos directorios temporales y ubicaciones para ficheros socket de Unix ejecutando los siguientes comandos antes de iniciar mysql_install_db o mysqld:
shell> TMPDIR=/some_tmp_dir
/ shell> MYSQL_UNIX_PORT=/some_tmp_dir
/mysql.sock shell> export TMPDIR MYSQL_UNIX_PORT
debería ser la ruta completa a algún directorio para el
cual se tenga permiso de escritura.
some_tmp_dir
Luego de hacer esto se debería estar en condiciones de ejecutar mysql_install_db e iniciar el servidor con estos comandos:
shell> bin/mysql_install_db --user=mysql shell> bin/mysqld_safe --user=mysql &
Si mysql_install_db está ubicado en el
directorio scripts
, debe modificarse
el primer comando para que diga
scripts/mysql_install_db
.
Consulte Sección A.4.5, “Cómo proteger o cambiar el fichero socket de MySQL /tmp/mysql.sock
”.
Consulte Apéndice E, Variables de entorno.
Generalmente, el servidor mysqld se inicia de alguna de estas formas:
Invocando mysqld directamente. Esto funciona en cualquier plataforma.
Ejecutando el servidor MySQL como un servicio de Windows. Esto puede hacerse en versiones de Windows que soporten servicios (como NT, 2000, XP, y 2003). El servicio se puede configurar para que inicie el servidor automáticamente cuando arranca Windows, o como un servicio manual que se inicia a pedido. Para instrucciones, consulte: Sección 2.3.12, “Arrancar MySQL como un servicio de Windows”.
Invocando mysqld_safe, el cual intenta determinar las opciones apropiadas para mysqld y entonces lo ejecuta con dichas opciones. Este script se usa en sistemas basados en BSD Unix. Consulte Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
Invocando mysql.server. Este script se
usa principalmente al iniciar y detener el sistema en
sistemas que emplean directorios de ejecución al estilo
System V, donde usualmente se instala bajo el nombre
mysql
. El script
mysql.server inicia el servidor
mediante la ejecución de Sección 5.1.4, “El script mysql.server para el arranque del servidor”.
En Mac OS X, se instala paquete separado llamado MySQL Startup Item para habilitar el inicio automático de MySQL junto con el sistema. El Startup Item inicia el servidor invocando a mysql.server. Consulte Sección 2.5, “Instalar MySQL en Mac OS X” para más detalles.
Los scripts mysql.server y mysqld_safe y el Mac OS X Startup Item se pueden utilizar para iniciar el servidor manualmente, o en forma automática al inicio del sistema. mysql.server y el Startup Item también se emplean para detener el servidor.
Para iniciar o detener el servidor manualmente empleando el
script mysql.server, se lo debe invocar con
los argumentos start
o
stop
:
shell> mysql.server start shell> mysql.server stop
Antes de que mysql.server inicie el
sevidor, se posiciona en el directorio de instalación de
MySQL, y luego ejecuta mysqld_safe. Si se
desea que el servidor se ejecute como un usuario específico,
debe agregarse la correspondiente opción
user
al grupo [mysqld]
del fichero de opciones /etc/my.cnf
, como
se muestra más adelante en esta sección. (Es posible que
haya que editar mysql.server si se instaló
una distribución binaria de MySQL en una ubicación no
estándar. La modificación consiste en hacer
cd
al directorio apropiado antes de
ejecutar mysqld_safe. En caso de hacer
esto, tener en cuenta que la versión modificada de
mysql.server puede ser sobreescrita si se
actualiza MySQL en el futuro; se debería hacer una copia de
la versión modificada para restaurarla.)
mysql.server stop detiene el servidor mediante el envío de una señal. También se lo puede detener manualmente ejecutando mysqladmin shutdown.
Para iniciar y detener MySQL automáticamente, se necesita
agregar los comandos de inicio y detención en los sitios
apropiados de los ficheros /etc/rc*
.
Si se emplea el paquete RPM de servidor para Linux
(MySQL-server-
),
el script mysql.server se instala en el
directorio VERSION
.rpm/etc/init.d
con el nombre
mysql
. No se necesita instalarlo
manualmente. Consulte Sección 2.4, “Instalar MySQL en Linux” para más
información sobre los paquetes Linux RPM.
Algunos vendedores proveen paquetes RPM que instalan un script de inicio con un nombre distinto, como mysqld.
Si se instala MySQL desde una distribución de código fuente
o mediante una distribución binaria que no instala
mysql.server automáticamente, se lo puede
instalar manualmente. El script se encuentra en el directorio
support-files
dentro del directorio de
instalación de MySQL o en el árbol de código fuente de
MySQL.
Para instalar mysql.server manualmente, se
los debe copiar en el directorio
/etc/init.d
con el nombre
mysql, y luego hacerlo ejecutable. Esto se
hace posicionándose dentro del directorio donde está
mysql.server y ejecutando estos comandos:
shell> cp mysql.server /etc/init.d/mysql shell> chmod +x /etc/init.d/mysql
Los sistemas Red Hat antiguos utilizan el directorio
/etc/rc.d/init.d
en lugar de
/etc/init.d
. Los comandos anteriores
deben modificarse de acuerdo a esto. Alternativamente, puede
crearse primero /etc/init.d
como un
vínculo simbólico que apunte a
/etc/rc.d/init.d
:
shell> cd /etc shell> ln -s rc.d/init.d .
Luego de instalar el script, los comandos necesarios para
activarlo en el arranque del sistema dependen del sistema
operativo. En Linux, puede utilizarse
chkconfig
:
shell> chkconfig --add mysql
En algunos sistemas Linux, el siguiente comando tmabién parece ser necesario para habilitar completamente al script mysql:
shell> chkconfig --level 345 mysql on
En FreeBSD, los scripts de inicio generalmente se encuentran
en /usr/local/etc/rc.d/
. La página de
manual rc(8)
establece que los scripts en
dicho directorio se ejecutan solamente si su nombre base
concuerda con el patrón de nombre de fichero shell
*.sh
. Cualquier otro fichero o directorio
presente dentro del directorio es ignorado sin advertencias.
En otras palabras, en FreeBSD, se debería instalar el script
mysql.server
como
/usr/local/etc/rc.d/mysql.server.sh
para
habilitar el inicio automático.
Como una alternativa a la configuración anterior, algunos
sistemas operativos también emplean
/etc/rc.local
o
/etc/init.d/boot.local
para iniciar
servicios adicionales en el arranque del sistema. Para iniciar
MySQL utilizando este método, se puede agregar un comando
como el siguiente al fichero de inicio apropiado:
/bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'
En otros sistemas operativos, consultar la documentación para ver cómo instalar scripts de inicio.
Se pueden agregar opciones a mysql.server
en un fichero global /etc/my.cnf
. Un
típico fichero /etc/my.cnf
podría verse
como este:
[mysqld] datadir=/usr/local/mysql/var socket=/var/tmp/mysql.sock port=3306 user=mysql [mysql.server] basedir=/usr/local/mysql
El script mysql.server acepta las
siguientes opciones: basedir
,
datadir
, y pid-file
. Si
se utilizan, deben estar en un fichero de
opciones, no en la línea de comandos.
mysql.server sólo acepta en la línea de
comandos las opciones start
y
stop
.
La siguiente tabla indica los grupos del fichero de opciones que son leidos por el servidor y por cada script de inicio.
Script | Grupos de opciones |
mysqld | [mysqld] , [server] ,
[mysqld-versión principal] |
mysql.server | [mysqld] , [mysql.server] ,
[server] |
mysqld_safe | [mysqld] , [server] ,
[mysqld_safe] |
[mysqld-versión principal]
significa que
los grupos con nombres como [mysqld-4.0]
,
[mysqld-4.1]
, y
[mysqld-5.0]
son leídos por servidores con
números de versión 4.0.x, 4.1.x, 5.0.x y así sucesivamente.
Esta característica sirve para especificar opciones que
serán leídas solamente por servidores pertenecientes a
releases de una determinada serie.
Por razones de compatibilidad hacia atrás,
mysql.server también lee el grupo
[mysql_server]
y
mysqld_safe también lee el grupo
[safe_mysqld]
. No obstante, cuando se
emplee MySQL 5.0, se debería actualizar el fichero de
opciones para que contenga los grupos
[mysql.server]
y
[mysqld_safe]
.
Si ocurren problemas durante el inicio del servidor, inténtese lo siguiente:
Especificar cualquier opción especial necesaria para el motor de almacenamiento en uso.
Asegurarse de que el servidor conoce dónde se encuentra el directorio de datos.
Cerciorarse de que el servidor pueda utilizar el directorio de datos. El propietario y los permisos sobre el directorio de datos y su contenido deben establecerse de forma que el servidor sea capaz de acceder a ellos y modificarlos.
Inspeccionar el registro de errores para ver porqué el servidor no se inicia.
Verificar que están disponibles las interfaces de red que el servidor intenta utilizar.
Algunos motores de almacenamiento tienen opciones que
controlan su comportamiento. Se puede crear un fichero
my.cnf
y establecer opciones de inicio
para el motor que se planea utilizar. Si se van a usar motores
de almacenamiento con soporte para tablas transaccionales
(InnoDB
, BDB
), hay que
asegurarse de que se han configurado según lo deseado antes
de iniciar el servidor:
Si se están empleando tablas InnoDB
,
hay que remitirse a las opciones de inicio específicas.
En MySQL 5.0, InnoDB
utiliza valores
por defecto para sus opciones de configuración si no se
indica ninguna. Consulte
Sección 15.3, “Configuración de InnoDB
”.
Si se están usando tablas BDB
(Berkeley DB), será necesario familiarizarse con las
diferentes opciones de inicio específicas de
BDB
. Consulte
Sección 14.4.3, “Opciones de arranque de BDB
”.
Cuando el servidor mysqld se inicia, se posiciona en el directorio de datos. Aquí es donde espera encontrar bases de datos y donde grabará sus ficheros de registro. En Unix, también grabará aquí el fichero pid (process ID, o identificador de proceso).
La ubicación del directorio de datos se establece en forma
fija cuando se compila el servidor. Aquí es donde, por
defecto, buscará el directorio de datos. Si el mismo se
encuentra en otra parte del sistema, el servidor no
funcionará correctamente. Se puede conocer la ubicación por
defecto ejecutando mysqld con las opciones
--verbose
y --help
.
Si los valores por defecto no coinciden con la instalación realizada en el sistema, se los puede sustituir especificando opciones para mysqld o mysqld_safe en la linea de comandos. También se pueden colocar en un fichero de opciones.
Para especificar explícitamente la ubicación del directorio
de datos, se emplea la opción --datadir
.
Sin embargo, normalmente se le puede indicar a
mysqld la ubicación del directorio base
donde está instalado MySQL, y el servidor buscará allí el
directorio de datos. Esto se hace con la opción
--basedir
option.
Para verificar los efectos de especificar opciones de ruta,
hay que invocar mysqld con dichas opciones
seguidas de --verbose
y
--help
. Por ejemplo, posicionándose donde
mysqld está instalado, y ejecutando los
siguientes comandos, se verán los efectos de iniciar el
servidor en el directorio base
/usr/local
:
shell> ./mysqld --basedir=/usr/local --verbose --help
Se pueden suministrar otras opciones, como
--datadir
, pero hay que tener en cuenta que
--verbose
y --help
deben
aparecer en último lugar.
Una vez que se haya logrado determinar la configuración de
ruta deseada, iniciar el servidor sin
--verbose
y --help
.
Si mysqld ya está ejecutándose, se puede conocer la configuración de rutas que está usando mediante la ejecución de este comando:
shell> mysqladmin variables
O bien:
shell> mysqladmin -h host_name
variables
host_name
es el nombre del host del
servidor MySQL.
Si se obtuviera el Errcode 13
(que
significa Permission denied (permiso
denegado)
) al iniciar mysqld,
indica que los permisos de acceso al directorio de datos o a
su contenido no permiten el acceso del servidor. En este caso,
hay que cambiar los permisos sobre los directorios y ficheros
involucrados para que el servidor tenga derecho a usarlos.
También se puede iniciar el servidor bajo el usuario de
sistema operativo root
, pero esto puede
traer aparejados problemas de seguridad y debería ser
evitado.
En Unix, hay que posicionarse en el directorio de datos y
verificar el propietario del directorio y su contenido para
asegurarse de que el servidor tiene acceso. Por ejemplo, si el
directorio de datos es
/usr/local/mysql/var
, usar este comando:
shell> ls -la /usr/local/mysql/var
Si el directorio de datos o sus ficheros o subdirectorios no tienen como propietario a la cuenta empleada para ejecutar el servidor, cambiar el propietario para que sea esa cuenta:
shell> chown -R mysql /usr/local/mysql/var shell> chgrp -R mysql /usr/local/mysql/var
Si el servidor falla en iniciarse correctamente, verificar el
fichero de registro de errores para ver si se puede encontrar
la causa. Los ficheros de registro se localizan en el
directorio de datos (generalmente, C:\Program
Files\MySQL\MySQL Server 5.0\data
en Windows,
/usr/local/mysql/data
en una
distribución binaria de Linux, y
/usr/local/var
en una distribución de
código fuente de Linux). Se buscan en el directorio de datos
los ficheros con un nombre con la forma
y
host_name
.err
,
donde host_name
.loghost_name
es el nombre del
host del servidor. Luego, examinar las últimas líneas de
estos ficheros. En Unix, puede utilizarse
tail
para mostrarlas:
shell> tailhost_name
.err shell> tailhost_name
.log
El registro de errores contiene información que indica el motivo por el cual el servidor no ha podido iniciarse. Por ejemplo, es posible ver algo como esto al examinarlo:
000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed 000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory 000729 14:50:10 Can't init databases
Esto significa que no se inició mysqld con
la opción --bdb-no-recover
y Berkeley DB
halló algo incorrecto con sus propios ficheros de registro
cuando intentó recuperar las bases de datos. Para que sea
posible continuar, habría que mover los ficheros de registro
Berkeley DB antiguos desde el directorio de bases de datos a
alguna otra ubicación, donde puedan examinarse
posteriormente. Los ficheros de registro
BDB
reciben nombres en secuencia comenzando
en log.0000000001
, donde el número se
incrementa cada vez.
Si se está ejecutando mysqld con soporte
para tablas BDB
y mysqld
realiza un volcado del núcleo al inicio, podría deberse a
problemas con el registro de recuperación de
BDB
. En este caso, se puede intentar el
inicio de mysqld con
--bdb-no-recover
. Si esto ayuda, entonces
se deberían eliminar todos los ficheros de registro
BDB
del directorio de datos e intentar el
inicio de mysqld nuevamente, sin la opción
--bdb-no-recover
.
Si ocurriese cualquiera de los siguientes errores, significa que algún otro programa (quizá otro servidor mysqld) está utilizando el puerto TCP/IP o socket Unix que mysqld intenta emplear:
Can't start server: Bind on TCP/IP port: Address already in use Can't start server: Bind on unix socket...
Utilizar ps para determinar si se tiene otro servidor mysqld en ejecución. Si es así, detener el servidor antes de iniciar mysqld de nuevo. (si hay otro servidor ejecutándose, y realmente se desea tener múltiples servidores, se puede hallar información sobre cómo hacerlo en Sección 5.11, “Ejecutar más de un servidor MySQL en la misma máquina”.)
Si no hay otro servidor ejecutándose, inténtese ejecutar el
comando telnet nombre-de-host
número-puerto-TCP-IP
. (El número de puerto MySQL
por defecto es 3306). Luego presionar Enter un par de veces.
Si no se obtiene un mensaje de error como telnet:
Unable to connect to remote host: Connection
refused
, algún otro programa está ocupando el
puerto TCP/IP que mysqld está intentando
utilizar. Se necesitará determinar qué programa es y
desactivarlo, o bien indicar a mysqld que
escuche en un puerto diferente mediante la opción
--port
. En este caso, también se
necesitará especificar el número de puerto en los programas
cliente cuando se conecten al servidor a través de TCP/IP.
Otra razón por la que el puerto podría ser inaccesible es que se tenga un firewall que bloquee las conexiones a él. Si es así, modificar la configuración del firewall para permitir el acceso a ese puerto.
Si el servidor se inicia pero no es posible conectarse a él,
habría que cerciorarse de que se tiene una entrada en
/etc/hosts
que se vea así:
127.0.0.1 localhost
Estre problema ocurre solamente en sistemas que no tienen una biblioteca para trabajo con subprocesos y para los cuales MySQL debe configurarse para usar MIT-pthreads.
Si no es posible iniciar mysqld, se puede
generar un fichero de seguimiento para hallar el problema
utilizando la opción --debug
. Consulte
Sección D.1.2, “Crear ficheros de traza”.
Consulte Sección 2.3.14, “Resolución de problemas en la instalación de MySQL bajo Windows” para obtener mayor información sobre la resolución de problemas en instalaciones Windows.
Una parte del proceso de instalación de MySQL es configurar la
base de datos mysql
, que contiene las tablas
de permisos:
Las distribuciones para Windows contiene tablas de permisos preinicializadas que se instalan automáticamente.
En Unix, las tablas de permisos se llenan mediante el programa mysql_install_db. Algunos métodos de instalación ejecutan este programa en forma automática. Otros necesitan que sea ejecutado manualmente. Para más detalles, consulte Sección 2.9.2, “Pasos a seguir después de la instalación en Unix”.
Las tablas de permisos definen las cuentas de usuario MySQL iniciales y sus permisos de acceso. Estas cuentas tienen la siguiente configuración:
Se crean dos cuentas con el nombre de usuario
root
. Son cuentas de superusuario que
pueden realizar cualquier tarea. Inicialmente las cuentas
root
no tienen contraseñas, de forma que
cualquier persona puede conectarse al servidor MySQL como
root
sin una
contraseña y recibirá todos los privilegios.
En Windows, una cuenta root
sirve
para conectarse desde el ordenador local (localhost) y
la otra permite conectarse desde cualquier ordenador.
En Unix, ambas cuentas root
son para
conexiones desde el ordenador local (localhost). Las
conexiones deben establecerse desde el ordenador local
especificando el nombre de host
localhost
para una de las cuentas, o
el nombre propiamente dicho del host o número de IP
para la otra.
Se crean dos cuentas de usuario anónimo, cada una con un nombre de usuario vacío. Los usuarios anónimos no tienen contraseña, de modo que cualquier persona puede usarlos para conectarse al servidor MySQL.
En Windows, una cuenta anónima es para conexiones desde
el ordenador local. Tiene todos los privilegios,
exactamente como la cuenta root
. La
otra sirve para conectarse desde cualquier ordenador y
tiene todos los permisos sobre la base de datos
test
u otras cuyo nombre comience con
test
.
En Unix, ambas cuentas anónimas son para conexiones
desde el ordenador local (localhost). Las conexiones
deben establecerse desde el ordenador local
especificando el nombre de host
localhost
para una de las cuentas, o
el nombre propiamente dicho del host o número de IP
para la otra. Estas cuentas tienen todos los permisos
sobre la base de datos test
u otras
cuyo nombre comience con test
.
Como se advierte, ninguna de las cuentas iniciales tiene contraseña. Esto significa que la instalación de MySQL estará desprotegida hasta que:
Si se desea evitar que los clientes se conecten como anónimos sin una contraseña, se les puede establecer contraseñas o bien eliminar las cuentas anónimas.
Se deberían establecer contraseñas para las cuentas
root
de MySQL.
Las siguientes instrucciones describen cómo establecer
contraseñas para las cuentas iniciales de MySQL, primero para
las cuentas anónimas y luego para las cuentas
root
. En los ejemplos se debe reemplazar
“newpwd
” con el password
que realmente se utilizará. También se instruye cómo eliminar
las cuentas anónimas, si se prefiriera impedir completamente el
acceso de usuarios anónimos.
Podría desearse posponer la aplicación de contraseñas hasta más tarde, para que no sea necesario ingresarlas mientras se desarrollan tareas adicionales de configuración o prueba. Sin embargo, hay que asegurarse de establecerlas antes de poner la instalación en trabajo de producción real.
Para 1800 proteger con contraseña las cuentas anónimas, puede
emplearse tanto SET PASSWORD
como
UPDATE
. En ambos casos, hay que asegurarse de
encriptar el password utilizando la función
PASSWORD()
.
Para emplear SET PASSWORD
en Windows, hacer
lo siguiente:
shell> mysql -u root mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd
'); mysql> SET PASSWORD FOR ''@'%' = PASSWORD('newpwd
');
Para emplear SET PASSWORD
en Unix, hacer lo
siguiente:
shell> mysql -u root mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd
'); mysql> SET PASSWORD FOR ''@'host_name
' = PASSWORD('newpwd
');
En la segunda sentencia SET PASSWORD
, debe
reemplazarse host_name
con el nombre
del host del servidor. Este es el nombre que aparece en la
columna Host
del registro correspondiente a
root
que no es localhost
en la tabla user
. Si no se puede determinar
el nombre de este host, utilizar la siguiente sentencia antes
que SET PASSWORD
:
mysql> SELECT Host, User FROM mysql.user;
Localizar el registro que tiene a root
en la
columna User
y cualquier otro excepto
localhost
en la columna
Host
. Entonces, utilizar ese valor de
Host
en la segunda sentencia SET
PASSWORD
.
La otra forma de asignar contraseñas a las cuentas anónimas es
utilizando UPDATE
para modificar directamente
la tabla user
. Hay que conectarse al servidor
como root
y emitir una sentencia
UPDATE
que asigne un valor a la columna
Password
en los registros apropiados de la
tabla user
. El procedimiento es igual en
Windows y en Unix. La siguiente sentencia
UPDATE
asigna una contraseña a las dos
cuentas anónimas de una sola vez:
shell> mysql -u root
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd
')
-> WHERE User = '';
mysql> FLUSH PRIVILEGES;
Luego de actualizar las contraseñas directamente en la tabla
user
empleando UPDATE
, se
le debe indicar al servidor que relea las tablas de privilegios
con FLUSH PRIVILEGES
. De otro modo, los
cambios no tendrán efecto hasta que se reinicie el servidor.
Si en lugar de lo anterior se prefiere eliminar las cuentas anónimas, hay que hacer lo siguiente:
shell> mysql -u root mysql> DELETE FROM mysql.user WHERE User = ''; mysql> FLUSH PRIVILEGES;
La sentencia DELETE
se aplica tanto en
Windows como en Unix. En Windows, si solamente se desean remover
las cuentas anónimas que tengan los mismos privilegios que
root
, debe hacerse lo siguiente:
shell> mysql -u root mysql> DELETE FROM mysql.user WHERE Host='localhost' AND User=''; mysql> FLUSH PRIVILEGES;
Esta cuenta permite el acceso anónimo con todos los privilegios, por lo tanto, al removerla se refuerza la seguridad.
A la cuenta root
se le pueden asignar
contraseñas en varias formas. En el tratamiento del tema que se
hace a continuación se muestran tres métodos:
Usar la sentencia SET PASSWORD
Usar el programa cliente de línea de comandos mysqladmin
Usar la sentencia UPDATE
Para asignar contraseñas empleando SET
PASSWORD
, hay que conectarse al servidor como
root
y emitir dos sentencias SET
PASSWORD
, asegurándose de encriptar la contraseña
con la función PASSWORD()
.
En Windows se hace así:
shell> mysql -u root mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd
'); mysql> SET PASSWORD FOR 'root'@'%' = PASSWORD('newpwd
');
En Unix, así:
shell> mysql -u root mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd
'); mysql> SET PASSWORD FOR 'root'@'host_name
' = PASSWORD('newpwd
');
En la segunda sentencia SET PASSWORD
, se debe
reemplazar host_name
con el nombre
del host del servidor. Es el mismo nombre de host que se
utilizó al asignar contraseñas a las cuentas anónimas.
Para establecer contraseñas en las cuentas
root
empleando mysqladmin,
ejecutar los siguientes comandos:
shell> mysqladmin -u root password "newpwd
" shell> mysqladmin -u root -hhost_name
password "newpwd
"
Estos comandos se aplican tanto a Windows como a Unix. En el
segundo comando, host_name
debe
reemplazarse con el nombre del host del servidor. Las comillas
dobles que encierran la contraseña no son siempre necesarias,
pero se las debe usar si la contraseña contiene espacios u
otros caracteres que sean especiales para el intérprete de
comandos.
También puede usarse UPDATE
para modificar
directamente la tabla user
. La siguiente
sentencia UPDATE
establece una contraseña
para ambas cuentas root
de una sola vez:
shell> mysql -u root
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd
')
-> WHERE User = 'root';
mysql> FLUSH PRIVILEGES;
La sentencia UPDATE
se aplica tanto a Windows
como a Unix.
Luego de establecer las contraseñas, se las deberá suministrar en cada conexión al servidor. Por ejemplo, si se desea emplear mysqladmin para detener el servidor, se debería hacer mediante este comando:
shell> mysqladmin -u root -p shutdown
Enter password: (enter root password here)
Nota: En caso de olvidar la
contraseña de root
despues de establecerla,
el procedimiento para reinicializarla se cubre en
Sección A.4.1, “Cómo reiniciar la contraseña de root”.
Para configurar nuevas cuentas, se debe usar la sentencia
GRANT
. Para instrucciones consulte
Sección 5.7.2, “Añadir nuevas cuentas de usuario a 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.
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 TABLE
para crear una
nueva tabla a partir de la tabla new_tbl
... SELECT
raid_tbl
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).
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.
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
' createnombre_bd
shell> mysqldump --optnombre_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 createnombre_bd
shell> mysqldump -h 'otro_ordenador
' --opt --compressnombre_bd
| mysqlnombre_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 --quicknombre_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 createnombre_bd
shell> gunzip <nombre_bd.contenidos
.gz | mysqlnombre_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 createnombre_bd
# crea la base de datos shell> cat DUMPDIR/*.sql | mysqlnombre_bd
# crea las tablas en la base de datos shell> mysqlimportnombre_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.
Esta sección describe los pasos a seguir si se está regresando a una versión previa de MySQL (downgrading), en el improbable caso de que la versión anterior funcione mejor que la nueva.
Si el downgrading se produce dentro de la misma serie de releases (por ejemplo, de 4.1.13 a 4.1.12) la regla general es que simplemente hay que instalar los nuevos binarios sobre los anteriores. No es necesario hacer nada con las bases de datos. Sin embargo, como siempre, es mejor hacer una copia de respaldo.
La siguiente lista enumera los pasos que se deberían seguir cada vez que se lleva a cabo un downgrading:
Leer la sección de actualización de la versión desde la que se hará el downgrading, para asegurarse de que no tenga ninguna característica realmente necesaria. Sección 2.10, “Aumentar la versión de MySQL”.
También debería leerse, si existe, la sección que explique el downgrading desde esa versión.
En la mayoría de los casos se pueden mover los ficheros de formato y de datos entre diferentes versiones de la misma arquitectura y en la medida que no cambie la serie de releases de MySQL, que actualmente es 5.0.
Si se regresa de una serie a otro, pueden surgir
incompatibilidades en los formatos de almacenamiento de las
tablas. En este caso, se utiliza mysqldump para
obtener un volcado de las tablas antes de hacer el downgrading.
Despues de hacerlo, se carga el fichero de volcado empleando
mysql o mysqlimport
para
volver a crear las tablas. Consulte
Sección 2.10.3, “Copiar bases de datos MySQL a otra máquina” para ver ejemplos.
Normalmente, el síntoma de que un cambio en el formato de las tablas era incompatible con el downgrading es que no se pueden abrir las tablas. En tal caso, utilizar el siguiente procedimiento:
Detener el antiguo servidor MySQL, hacia el que se está tratando de hacer el downgrading.
Reiniciar el nuevo servidor MySQL, desde el cual se está tratando de hacer el downgrading.
Volcar las tablas que aparecen inaccesibles para el antiguo servidor, empleando mysqldump para crear un fichero de volcado.
Detener el nuevo servidor MySQL y reiniciar el antiguo.
Cargar el fichero de volcado en el viejo servidor. Las tablas deberían ser accesibles.
Luego de hacer un downgrading desde MySQL 5.0, es posible
encontrar la siguiente información en el fichero
mysql.err
:
Incorrect information in file: './mysql/user.frm'
En tal caso, hacer lo siguiente:
Iniciar MySQL 5.0.4 (o posterior)
Ejecutar mysql_fix_privilege_tables, el
cual cambiará la tabla mysql.user
a un
formato que puedan entender tanto MySQL 4.1 como 5.0.
Detener el servidor MySQL.
Iniciar MySQL 4.1
Si el procedimiento anterior falla, el siguiente debería funcionar:
Iniciar MySQL 5.0.4 (o posterior).
Ejecutar mysqldump --opt --add-drop-table mysql > /tmp/mysql.dump.
Detener el servidor MySQL.
Iniciar MySQL 4.1 con la opción
--skip-grant
.
Ejecutar mysql mysql < /tmp/mysql.dump.
Ejecutar mysqladmin flush-privileges.
Esta sección se ocupa de problemas que han ocurrido bajo Linux. Las primeras subsecciones describen dificultades relacionadas con el sistema operativo en general, problemas que pueden ocurrir al emplear distribuciones binarias o de código fuente, y problemas posteriores a la instalación. Las restantes subsecciones se ocupan de problemas que se dan en plataformas Linux específicas.
Nótese que la mayoría de estos problemas ocurren en versiones antiguas de Linux. Si se está ejecutando una versión reciente, es probable que no se vea ninguno de ellos.
MySQL requiere por lo menos Linux Versión 2.0.
Advertencia: Se detectaron algunos problemas extraños con Linux 2.2.14 y MySQL sobre sistemas SMP (multiprocesamiento simétrico). También se tiene información de algunos usuarios que encontraron serios problemas de estabilidad al ejecutar MySQL con el kernel 2.2.14. Si se está empleando este kernel, se debería actualizar a la versión 2.2.19 (o posterior) o 2.4. Si se cuenta con un ordenador con múltiples CPUs, habría que considerar seriamente el uso del kernel 2.4, ya que representa un notable incremento de velocidad. También es más estable.
Al emplear LinuxThreads, se debería ver un mínimo de tres procesos mysqld en ejecución. De hecho, son hebras (threads). Uno corresponde al gestor de LinuxThreads, otro es para manejar conexiones, y uno más para manejar advertencias y señales.
El binario para Linux-Intel y los releases RPM de MySQL están configurados para funcionar a la mayor velocidad posible. Quienes desarrollan MySQL siempre tratan de emplear el compilador estable más rápido disponible.
El release binario se enlaza con -static
,
lo cual significa que normalmente no habrá que preocuparse
por la versión de las bibliotecas del sistema que se tenga.
Un programa enlazado con -static
es
ligeramente más rápido (3-5%). Sin embargo, un problema con
los programas enlazados estáticamente es que no se pueden
emplear funciones definidas por el usuario (FDU o UDF, por sus
siglas en inglés). Si se van a escribir o emplear FDUs (esto
es sólo para programadores de C o C++), habría que
recompilar MySQL empleando enlazado dinámico.
Un problema con las distribuciones binarias es que en sistemas
Linux antiguos que utilizan libc
(tal como
Red Hat 4.x o Slackware), se tendrán algunos problemas (no
fatales) con la resolución del nombre de host. Si el sistema
emplea libc
en lugar de
glibc2
, probablemente se encontrarán
algunas dificultades con la resolución de nombres de host y
getpwnam()
. Esto ocurre porque
glibc
(desafortunadamente) depende de
algunas bibliotecas externas para implementar la resolución
de nombres de host y getpwent()
, incluso
cuando se compila con -static
. Estos
problemas se manifiestan de dos maneras:
Ver el siguiente mensaje de error al ejecutar mysql_install_db:
Sorry, the host 'xxxx
' could not be looked up
Esto puede solventarse mediante la ejecución de
mysql_install_db --force, lo cual evita
que se ejecute la prueba de resolveip
en mysql_install_db. La contraparte de
esto es que no se pueden utilizar nombres de host en las
tablas de permisos: excepto localhost
,
se deben usar números d eIP en su lugar. Si se está
utilizando una versión de MySQL que no soporta la opción
--force
, se debe quitar manualmente la
prueba resolveip
de
mysql_install
empleando un editor de
textos.
También se puede hallar el siguiente error cuando se
ejecuta mysqld con la opción
--user
:
getpwnam: No such file or directory
Para resolver esto, iniciar mysqld
mediante el comando su
en lugar de
especificar la opción --user
. Esto
provoca que el sistema cambie el ID de usuario del proceso
mysqld, así no debe hacerlo
mysqld.
Otra solución, que resuelve ambos problemas, es no usar una
distribución binaria. En su lugar se debe obtener una
distribución de código fuente de MySQL (en formatos RPM o
tar.gz
).
En algunas versiones 2.2 de Linux puede producirse el error
Resource temporarily unavailable
cuando los
clientes establezcan un número elevado de nuevas conexiones
TCP/IP al servidor mysqld. La razón es que
Linux tiene un retraso entre el momento en que se cierra un
socket TCP/IP y el momento en que el sistema lo libera
realmente. Sólo hay capacidad para una cantidad limitada de
conexiones, por eso se produce el error de recursos no
disponibles (resource-unavailable) si los clientes intentan
realizar demasiadas conexiones TCP/IP en un período corto de
tiempo. Por ejemplo, este error puede verse cuando se ejecuta
la prueba de rendimiento test-connect
sobre TCP/IP.
Se ha indagado sobre este problema en diferentes listas de correo de Linux pero nunca se ha obtenido una solución convincente. El único “fix” conocido es para clientes que emplean conexiones persistentes, o, si se están ejecutando el servidor y los clientes en el mismo ordenador, emplear conexiones a través de ficheros socket de Unix en lugar de conexiones TCP/IP.
Las siguientes notas relativas a glibc
son
aplicables únicamente en el caso que se desee compilar el
código de MySQL. Si se está ejecutando Linux en un ordenador
x86, en la mayoría de los casos será mucho mejor utilizar el
binario. Quienes hacen MySQL enlazan los binarios utilizando
la mejor y más actual versión de glibc
que tienen disponible y con las opciones de compilación más
apropiadas a fin de hacerlo apto para un servidor de uso
intensivo o high-load. Para un usuario típico, o incluso en
configuraciones con muchas conexiones concurrentes o tablas
excediendo el límite de 2Gb, el binario provisto por MySQL AB
es en la mayoría de los casos la mejor elección. Luego de
leer el siguiente texto, si aún persiste la duda, hay que
probar el binario para determinar si cubre las necesidades del
usuario. Si no es suficiente, entonces puede intentarse una
compilación propia. En tal caso MySQL AB apreciará que se le
comuniquen los detalles para crear mejores binarios en el
futuro.
MySQL emplea LinuxThreads en Linux. Si se utiliza una versión
antigua de Linux que no tiene glibc2
, se
deberá instalar LinuxThreads antes de compilar MySQL.
LinuxThreads puede descargarse de
http://dev.mysql.com/downloads/os-linux.html.
Notar que las versiones de glibc
hasta la
2.1.1 inclusive tienen un error fatal en el manejo de
pthread_mutex_timedwait()
, el cual es
utilizado al emitir sentencias INSERT
DELAYED
. Se recomienda que no se use INSERT
DELAYED
sin antes haber actualizado
glibc
.
El kernel de Linux y la biblioteca LinuxThreads pueden manejar por defecto un máximo de 1024 subprocesos. Si se planea gestionar más de 1000 conexiones simultáneas, se necesitarán algunos cambios en LinuxThreads:
Incrementar PTHREAD_THREADS_MAX
en el
fichero
sysdeps/unix/sysv/linux/bits/local_lim.h
a un valor de 4096 y reducir STACK_SIZE
en el fichero
linuxthreads/internals.h
a un valor
de 256KB. Las rutas son relativas a la raíz de
glibc
. (Tener en cuenta que MySQL no es
estable con 600 a 1000 conexiones si
STACK_SIZE
se deja en el valor por
defecto de 2MB).
Recompilar LinuxThreads para producir una nueva biblioteca
libpthread.a
, y volver a enlazarla
con MySQL.
Hay otro problema que afecta enormemente el rendimiento de
MySQL, especialmente en sistemas SMP (multiprocesamiento
simétrico, por sus siglas en inglés). La implementación de
mutex en LinuxThreads en glibc
2.1 es muy
pobre para programas con muchos subprocesos que mantengan el
mutex sólo por un corto tiempo. Esto produce un resultado
paradójico: si se enlaza MySQL con LinuxThreads sin
modificar, el quitar procesadores de un sistema SMP realmente
mejora el rendimiento de MySQL en muchos casos. MySQL AB ha
creado un parche disponible para glibc
2.1.3 para corregir este comportamiento
(http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).
Con glibc
2.2.2, MySQL utiliza el mutex
adaptable, lo cual es mucho mejor inclusive que
glibc
2.1.3 con parche y todo. Hay que
estar al tanto, sin embargo, de que bajo ciertas condiciones,
el código de exclusión mutua (mutex) actual emplea con
demasiada frecuencia los spinlocks (bucles de programa que
ciclan constantemente esperando por una condición), lo cual
repercute en las prestaciones de MySQL. La probabilidad de que
esto ocurra se puede reducir dando al proceso
mysqld la máxima prioridad. MySQL AB
también ha logrado corregir el comportamiento relativo a los
spinlocks con un parche, que puede descargarse desde
http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch.
Este combina la corrección del uso excesivo de spinlocks,
máximo número de procesos, y la capacidad de la pila, todo
en uno. Se lo deberá aplicar en el directorio
linuxthreads
con patch -p0
</tmp/linuxthreads-2.2.2.patch
. Es de esperar que
sea incluido de alguna forma en futuras versiones de
glibc
2.2. De cualquier modo, si enlaza con
glibc
2.2.2, aún será necesario corregir
STACK_SIZE
y
PTHREAD_THREADS_MAX
. Es de esperar que los
valores por defecto de éstos sean llevados en el futuro a un
número más aceptable para configuraciones MySQL de altas
prestaciones, de modo que los comandos necesarios para
recompilarlo se reduzcan a ./configure; make; make
install.
Se recomienda que se usen estos parches para producir una
versión estática, especial, de
libpthread.a
y emplearla solamente para
enlazado dinámico con MySQL. Se sabe que los mencionados
parches son seguros para MySQL y mejoran significativamente su
rendimiento, pero no se puede decir nada acerca de sus efectos
sobre otras aplicaciones. Enlazar otras aplicaciones que
requieran LinuxThreads con la versión estática parcheada o
hacer una versión mixta e instalarla en el sistema, es por
cuenta del usuario y a su riesgo.
Si se experimenta cualquier problema extraño durante la instalación de MySQL, o algunas utilidades comunes se congelan, es muy probable que esté relacionado con las bibliotecas o el compilador. Si este es el caso, utilizar el binario de MySQL AB resolverá el problema.
Si el usuario compila sus propios programas cliente, es posible que vea los siguientes errores en tiempo de ejecución:
ld.so.1: fatal: libmysqlclient.so.#: open failed: No such file or directory
Este problema puede evitarse de alguna de estas maneras:
Si se emplea el compilador Fujitsu
(fcc/FCC
), se puede tener algún problema
al compilar MySQL porque los ficheros de cabecera de Linux
están muy orientados a gcc. La siguiente
línea de configure debería funcionar con
fcc/FCC:
CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \ -DCONST=const -DNO_STRTOLL_PROTO" \ CXX=FCC CXXFLAGS="-O -K fast -K lib \ -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE \ -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \ '-D_EXTERN_INLINE=static __inline'" \ ./configure \ --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static --disable-shared \ --with-low-memory
mysql.server es un fichero que puede
hallarse en el directorio support-files
bajo el directorio de instalación de MySQL o en un árbol de
código fuente MySQL. Se instala como
/etc/init.d/mysql
para conseguir que
MySQL inicie y se detenga automáticamente. Consulte
Sección 2.9.2.2, “Arrancar y parar MySQL automáticamente”.
Si MySQL no puede abrir suficiente ficheros o conexiones, es posible que Linux no se haya configurado para gestionar suficientes ficheros.
En Linux 2.2 y posteriores, se puede verificar la cantidad de manejadores de ficheros asignados de esta forma:
shell> cat /proc/sys/fs/file-max shell> cat /proc/sys/fs/dquot-max shell> cat /proc/sys/fs/super-max
Si se poseen más de 16 MB de ram, se debería agregar a los scripts de inicio algo como lo siguiente (por ejemplo, mysql.server en SuSE Linux):
echo 65536 > /proc/sys/fs/file-max echo 8192 > /proc/sys/fs/dquot-max echo 1024 > /proc/sys/fs/super-max
Los comandos echo
también pueden
ejecutarse como root
,desde la línea de
comandos, pero los valores establecidos se perderán la
próxima vez que se reinicie el ordenador.
De manera alternativa, estos parámetros pueden configurarse
al inicio usando la herramienta sysctl
, la
cual es usada por muchas distribuciones de Linux (incluyendo
SuSE Linux 8.0 y posteriores). Colocar los siguientes valores
en un fichero llamado /etc/sysctl.conf
:
# Incrementa algunos valores para MySQL fs.file-max = 65536 fs.dquot-max = 8192 fs.super-max = 1024
También se debería agregar lo siguiente a
/etc/my.cnf
:
[mysqld_safe] open-files-limit=8192
Esto elevará a 8192 el límite del servidor para el número total de conexiones y ficheros abiertos.
La constante STACK_SIZE
de Linuxthreads
controla el espacio de la pila de subprocesos en el espacio de
direcciones. Necesita ser lo suficientemente grande como para
brindar bastante lugar para cada pila individual de
subprocesos, pero lo suficientemente pequeña para mantener la
pila de algunos subprocesos ejecutándose fuera de los datos
globales de mysqld. Desafortunadamente, la
experiencia demostró que la implementación Linux de
mmap()
desasigna una región previamente
asignada (mapped), si se solicita asignar (map) una dirección
actualmente en uso, poniendo a cero los datos de toda la
página en lugar de retornar un error. De modo que la
seguridad de mysqld o cualquier otra
aplicación hebrada depende de la "caballerosidad" del código
que crea los subprocesos. El usuario debe tomar medidas para
cerciorarse que el número de procesos en ejecución en
cualquier momento dado es lo suficientemente bajo como para
que las pilas de procesos se mantengan lejos del montón
(heap) global. Con mysqld esto debería
hacerse, estableciendo un valor razonable para la variable
max_connections
.
Si el usuario compila por sí mismo a MySQL, puede aplicar un
parche a LinuxThreads para un mejor uso de la pila. Consulte
Sección 2.12.1.3, “Notas sobre la distribución de código fuente para Linux”. Si no se desea aplicar
un parche a LinuxThreads, se deberá establecer
max_connections
a un valor no mayor de 500,
o incluso menos si se tienen un gran buffer de claves, grandes
tablas de montón (heap tables) o alguna otra cosa que obligue
a mysqld a reservar gran cantidad de
memoria,o si se está ejecutando un kernel 2.2 con un parche
de 2Gb. Si se está empleando la versión binaria en RPM, se
puede establecer en forma segura
max_connections
a un valor de 1500,
asumiendo que no hay grandes buffers de claves, o grandes
tablas de montón (heap tables) con muchos datos. Mientras
más se reduzca STACK_SIZE
en LinuxThreads,
más subprocesos podrán crearse sin problemas. Se recomiendan
valores ente 128KB y 256KB.
Si se utilizan muchas conexiones simultáneas, puede sufrirse una “característica” del kernel 2.2, que intenta prevenir ataques de bomba de bifurcación (fork bomb) penalizando los procesos que bifurcan o clonan un proceso hijo. Esto provoca que MySQL no escale bien a medida que se incrementa el número de clientes simultáneos. En sistemas con una única CPU, esto se manifiesta a través de lentitud en la creación de procesos; puede llevar largo tiempo conectarse a MySQL (hasta un minuto) y puede llevar lo mismo para detenerlo. En sistemas con múltiples CPUs, se observó una caída gradual en la velocidad de las consultas a medida que aumenta el número de clientes. En la búsqueda de una solución, se recibió un parche para el kernel de parte de un usuario que lo necesitó para su sitio web. Este parche puede descargarse de http://www.mysql.com/Downloads/Patches/linux-fork.patch. MySQL AB probó ampliamente este parche tanto en sistemas en desarrollo como en producción. Funcionó incrementando notablemente el rendimiento de MySQL sin causas problemas, por lo tanto se lo recomienda a los usuario que aún ejecuten servidores de altas prestaciones en kernels 2.2.
Este problema se resolvió en el kernel 2.4, de modo que si no se está satisfecho con el rendimiento actual del sistema, en lugar de aplicar un parche al kernel 2.2, podría ser más sencillo actualizarlo a 2.4. En sistemas SMP (multiprocesamiento simétrico), la actualización también favorecerá el desempeño de SMP además de corregir el error.
Al probar MySQL con un kernel 2.4 en un ordenador de dos procesadores, se halló que MySQL escala mucho mejor. Hasta 1,000 clientes prácticamente no se producen retrasos en el rendimiento de las consultas, y el factor de escalado de MySQL (calculado como el máximo rendimiento respecto al rendimiento de un cliente) fue 180%. Se observaron resultados similares en un ordenador de cuatro procesadores: hasta 1,000 clientes prácticamente no se producen retrasos en el rendimiento de las consultas, y el factor de escalado de MySQL fue de 300%. Al basarse en estos resultados, definitivamente se recomienda que los servidores de alta prestación ejecutando un kernel 2.2 se actualicen a 2.4.
A fin de obtener el máximo rendimiento, es esencial ejecutar
el proceso mysqld con la prioridad más
alta posible en kernel 2.4. Esto puede lograrse agregando un
comando renice -20 $$
a
mysqld_safe. En las pruebas sobre un
ordenador de 4 procesadores, el aumento de la prioridad
produjo un 60% de incremento en el rendimiento con 400
clientes.
En la actualidad, MySQL AB se halla recolectando información
sobre el desempeño de MySQL sobre un kernel 2.4 en sistemas
de cuatro y ocho procesadores. Si se tiene acceso a tales
sistemas, y se han hecho algunas pruebas de rendimiento, por
favor envíese un mensaje de correo electrónico a
<benchmarks@mysql.com>
con los resultados. Estos
serán revisados para su inclusión en este manual.
Si con ps se advierte un proceso mysqld muerto, generalmente significa un error en MySQL o una tabla corrupta. Consulte Sección A.4.2, “Qué hacer si MySQL sigue fallando (crashing)”.
Para que se genere un volcado de núcleo en Linux cuando
mysqld finalice imprevistamente con una
señal SIGSEGV
, debe iniciarse
mysqld con la opción
--core-file
. También es probable que se
necesite aumentar el espacio para el fichero de volcado de
núcleo mediante el agregado de ulimit -c
1000000 a mysqld_safe o iniciando
mysqld_safe con
--core-file-size=1000000
. Consulte
Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
MySQL necesita la versión 5.4.12 o posterior de
libc
. Se sabe que trabaja correctamente con
libc
5.4.46. glibc
versión 2.0.6 y posterior también debería funcionar. Han
ocurrido algunos problemas con los RPMs de
glibc
para Red Hat, de modo que si sucede,
se deberá buscar cualquier actualización disponible. Los
RPMs de las versiones glibc
2.0.7-19 y
2.0.7-29 funcionan adecuadamente.
Si se está empleando Red Hat 8.0 o una nueva biblioteca
glibc
2.2.x, se puede ver una finalización
imprevista de mysqld en
gethostbyaddr()
. Esto sucede porque la
nueva biblioteca glibc
requiere un tamaño
de pila mayor a 128Kb para esta llamada. Para solucionar el
problema, se debe iniciar mysqld con la
opción --thread-stack=192K
. (Use
-O thread_stack=192K
si está utilizando
una versión de MySQL anterior a MySQL 4). Este tamaño de
pila es el predeterminado en MySQL 4.0.10 y posteriores, de
modo que el problema mencionado no existirá.
Si se está empleando gcc 3.0 o posterior
para compilar MySQL, se deberá instalar la biblioteca
libstdc++v3
antes de compilar MySQL; si no
se hace de esta forma, se obtendrá un error relativo a un
símbolo inexistente __cxa_pure_virtual
durante el enlazado.
En algunas distribuciones de Linux antiguas, configure puede producir un error como este:
Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file. See the Installation chapter in the Reference Manual.
Simplemente hay que hacer lo que el mensaje dice (Error de
sintaxis en sched.h. Cambie _P a __P en el fichero
/usr/include/sched.h) Agregar un carácter de subrayado
adicional al nombre de macro _P
que tiene
solamente uno, y reintentar.
Pueden aparecer algunas advertencias durante la compilación. Las que se listan a continuación, pueden ignorarse:
mysqld.cc -o objs-thread/mysqld.o mysqld.cc: In function `void init_signals()': mysqld.cc:315: warning: assignment of negative value `-1' to `long unsigned int' mysqld.cc: In function `void * signal_hand(void *)': mysqld.cc:346: warning: assignment of negative value `-1' to `long unsigned int'
Si mysqld realiza siempre un volcado de
núcleo al iniciarse, el problema puede estar en una versión
antigua de /lib/libc.a
. Debe intentarse
renombrando el fichero, luego borrar
sql/mysqld
y ejecutar nuevamente el
comando make install. Luego reintentar.
Este problema se informó en algunas instalaciones de
Slackware.
Si se obtiene el siguiente error al enlazar
mysqld, significa que la biblioteca
libg++.a
no se instaló correctamente:
/usr/lib/libc.a(putc.o): In function `_IO_putc': putc.o(.text+0x0): multiple definition of `_IO_putc'
Se puede evitar el uso de libg++.a
ejecutando configure de esta manera:
shell> CXX=gcc ./configure
En algunas implementaciones, readdir_r()
no
funciona correctamente. El síntoma es que la sentencia
SHOW DATABASES
devuelve una respuesta
vacía. Esto puede solucionarse eliminando
HAVE_READDIR_R
del fichero
config.h
después de configurar y antes
de compilar.
Se hicieron pruebas de rendimiento y funcionamiento con MySQL 5.0 sobre Alpha, y parece funcionar correctamente.
Actualmente, los paquetes binarios de MysQL se crean sobre SuSE Linux 7.0 para AXP, kernel 2.4.4-SMP, Compiladores Compaq C (V6.2-505) y Compaq C++ (V6.3-006) sobre un ordenador Compaq DS20 con procesador Alpha EV6.
Los compiladores mencionados pueden descargarse de http://www.support.compaq.com/alpha-tools/. Usando éstos en lugar de gcc, se ha obtenido una mejora del 9% al 14% en el rendimiento de MySQL.
Para MySQL 5.0 sobre Alpha, se utiliza el flag -arch
generic
en las opciones del compilador, lo cual
garantiza que el binario se ejecute en todos los procesadores
Alpha. También se compila estáticamente para evitar
problemas con bibliotecas. El comando
configure se ve así:
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \ CXXFLAGS="-fast -arch generic -noexceptions -nortti" \ ./configure --prefix=/usr/local/mysql --disable-shared \ --with-extra-charsets=complex --enable-thread-safe-client \ --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared
Si se desea emplear egcs, la siguiente linea en configure ha funcionado bien:
CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --disable-shared
Algunos problemas conocidos al ejecutar MySQL en Linux-Alpha:
La depuración de aplicaciones multihilo como MySQL no
funciona en gdb 4.18
. Debe emplearse
gdb 5.1 en su lugar.
Si se intenta enlazar estáticamente
mysqld cuando se utiliza
gcc, la imagen resultante realiza un
volcado de núcleo al iniciarse. Esto significa que
no se debe emplear
--with-mysqld-ldflags=-all-static
con
gcc.
MySQL debería funcionar en MkLinux con el paquete más nuevo
de glibc
(se lo probó con
glibc
2.0.7).
Para lograr que MySQL funcione en Qube2 (Linux Mips), se
necesita la verseón más nueva de las bibliotecas
glibc
. glibc-2.0.7-29C2
funciona correctamente. También es necesario emplear el
compilador de C++ egcs
(egcs 1.0.2-9, gcc
2.95.2 o posterior).
Para lograr que MySQL se compile en Linux IA-64, se los desarrolladores de MySQL utilizaron el siguiente comando configure para compilar con gcc 2.96:
CC=gcc \ CFLAGS="-O3 -fno-omit-frame-pointer" \ CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql \ "--with-comment=Official MySQL binary" \ --with-extra-charsets=complex
En IA-64, los clientes binarios de MySQL utilizan bibliotecas
compartidas. Esto significa que si se instala la distribución
binaria provista por MySQL AB en otra ubicación que no sea
/usr/local/mysql
, se deberá agregar la
ruta donde está instalado
libmysqlclient.so
, ya sea en el fichero
/etc/ld.so.conf
o en la variable de
entorno LD_LIBRARY_PATH
.
Consulte Sección A.3.1, “Problemas al enlazar a la biblioteca de clientes MySQL”.
En Mac OS X, tar no puede manejar nombres
largos de fichero. Si se necesita descomprimir una distribución
.tar.gz
, se deberá emplear
gnutar.
MySQL debería funcionar sin mayores problemas en Mac OS X 10.x (Darwin).
Los problemas conocidos son:
Los valores de tiempo de conexión
(wait_timeout
,
interactive_timeout
y
net_read_timeout
) no se respetan.
Probablemente esto sea indicio de un problema de manejo en la biblioteca de subprocesos, donde la señal no interrumpe una lectura pendiente. Es de esperar que una futura actualización de la biblioteca de subprocesos lo corrija.
El binario provisto por MySQL para Mac OS X está compilado sobre Darwin 6.3 con la siguiente línea en configure:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql \ --with-extra-charsets=complex --enable-thread-safe-client \ --enable-local-infile --disable-shared
En versiones actuales de Mac OS X Server no se requieren cambios al sistema operativo antes de compilar MySQL. La compilación para la plataforma Server es lo mismo que para la versión cliente de MySQL.
En versiones antiguas (Mac OS X Server 1.2, también conocido como Rhapsody), se debe instalar un paquete pthread antes de intentar configurar MySQL.
En Solaris pueden experimentarse problemas aún antes de lograr descomprimir la distribución de MySQL, ya que tar no puede manejar nombres de fichero largos en Solaris. Esto significa que pueden verse errores cuando se intente expandir MySQL.
Si esto ocurre, habrá que emplear el GNU tar (gtar) para expandir la distribución. Se puede hallar una copia precompilada para Solaris en http://dev.mysql.com/downloads/os-solaris.html.
Los procesos nativos de Sun solamente funcionan en Solaris 2.5 y posteriores. Para la versión 2.4 y anteriores, MySQL utilizará MIT-pthreads automáticamente. Consulte Sección 2.8.5, “Notas sobre MIT-pthreads”.
Si se obtienen el siguiente error en configure, significa que algo falló en la instalación del compilador:
checking for restartable system calls... configure: error can not run test programs while cross compiling
En este caso se debería actualizar a una versión más reciente
del compilador. También podría resolverse este problema
insertando la siguiente línea en el fichero
config.cache
:
ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
Si se esta empleando Solaris en una SPARC, el compilador recomendado es gcc 2.95.2 o 3.2. Se lo puede descargar de http://gcc.gnu.org/. Hay que notar que egcs 1.1.1 y gcc 2.8.1 no funcionan confiablemente en SPARC.
La línea recomendada en configure al utilizar gcc 2.95.2 es:
CC=gcc CFLAGS="-O3" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory \ --enable-assembler
Si se tiene un sistema UltraSPARC, se puede mejorar el
rendimiento en un 4% agregando -mcpu=v8
-Wa,-xarch=v8plusa
a las variables de entorno
CFLAGS
y CXXFLAGS
.
Si se tiene el compilador Forte 5.0 (o posterior) de Sun, se puede ejecutar configure de esta manera:
CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -mt" \ ./configure --prefix=/usr/local/mysql --enable-assembler
Para crear un binario de 64 bits con el compilador Forte de Sun, deben utilizarse las siguientes opciones de configuración:
CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \ CXX=CC CXXFLAGS="-noex -mt -xarch=v9" ASFLAGS="-xarch=v9" \ ./configure --prefix=/usr/local/mysql --enable-assembler
Para crear un binario de 64 bits para Solarios utilizando
gcc, debe agregarse -m64
a
CFLAGS
y CXXFLAGS
y quitar
--enable-assembler
de la linea de
configure.
En las pruebas de rendimiento MySQL, se obtuvo un incremento del
4% en la velocidad en una UltraSPARC cuando se utilizó Forte
5.0 en modo de 32 bits, comparado con gcc 3.2
con el flag -mcpu
.
Si se crea un binario mysqld de 64 bits, es un 4% más lento que el binario de 32 bits, pero puede manejar más subprocesos y memoria.
Al utilizar Solaris 10 para x86_64, cualquier sistema de
ficheros (filesystem) donde se deseen almacenar ficheros InnoDB
debería ser montado con la opción
forcedirectio
. (Por defecto, el montaje se
realiza sin esta opción) Si no se hace de este modo, el
rendimiento caerá significativamente al usar el motor de
almacenamiento InnoDB en dicha plataforma.
Si se tienen problemas con fdatasync
o
sched_yield
, se podrán solucionar agregando
LIBS=-lrt
en la línea de
configure.
Para compiladores anteriores a WorkShop 5.3, se podría tener que editar el script configure, cambiando esta línea:
#if !defined(__STDC__) || __STDC__ != 1
Poniendo esta en su lugar:
#if !defined(__STDC__)
Si se inicia __STDC__
con la opción
-Xc
, el compilador de Sun no podrá compilar
con el fichero de cabecera pthread.h
de
Solaris. Esto es un error de Sun (en el compilador o en el
fichero).
Si mysqld emite el siguiente mensaje de error
cuando se lo ejecuta, es porque se lo ha compilado con el
compilador de Sun sin habilitar la opción de multihilo
-mt
:
libc internal error: _rmutex_unlock: rmutex not held
Agregar -mt
a CFLAGS
y
CXXFLAGS
y recompilar.
Si se está utilizando la versión SFW de gcc
(que viene con Solaris 8), se debe agregar
/opt/sfw/lib
a la variable de entorno
LD_LIBRARY_PATH
antes de ejecutar
configure.
Si se está empleando el gcc disponible en
sunfreeware.com
, pueden tenerse muchos
problemas. Para evitarlo, se debería recompilar
gcc y GNU binutils
en el
ordenador donde se los ejecutará.
Si se obtiene el siguiente mensaje de error al compilar MySQL con gcc, significa que gcc no está configurado para la versión en uso de Solaris:
shell> gcc -O3 -g -O2 -DDBUG_OFF -o thr_alarm ... ./thr_alarm.c: In function `signal_hand': ./thr_alarm.c:556: too many arguments to function `sigwait'
Lo más apropiado para hacer en este caso es conseguir la versión más nueva de gcc y compilarlo con el gcc que se tiene. Al menos en Solaris 2.5, casi todas las versiones binarias de gcc tienen ficheros de cabecera antiguos e inutilizables que hacen caer a todos los programas que usan subprocesos y posiblemente también a otros programas.
Solaris no provee versiones estáticas de todas las bibliotecas
del sistema (libpthreads
y
libdl
), de modo que no se puede compilar
MySQL con --static
. Si se intenta hacer tal
cosa, se obtendrá uno de los siguientes errores:
ld: fatal: library -ldl: not found undefined reference to `dlopen' cannot find -lrt
Si se enlaza con los programas cliente MySQL del usuario, se puede ver el siguiente error en tiempo de ejecución:
ld.so.1: fatal: libmysqlclient.so.#: open failed: No such file or directory
Este problema puede evitarse por medio de alguno de estos métodos:
Si ocurren problemas con configure al
intentar enlazar con -lz
cuando no se tiene
instalado zlib
, hay dos opciones:
Si se desea tener la capacidad de usar el protocolo de
comunicación comprimido, se deberá conseguir
zlib
desde ftp.gnu.org
e instalarlo.
Ejecutar configure con la opción
--with-named-z-libs=no
cuando se compile
MySQL.
Si se está utilizando gcc y se tienen
problemas con la carga de funciones definidas por el usuario
(UDFs) en MySQL, hay que intentar agregar
-lgcc
a la línea donde se enlaza la UDF.
Si se desea que MySQL inicie automáticamente, se debe copiar
support-files/mysql.server
a
/etc/init.d
y crear un vínculo simbólico
hacia él, llamado
/etc/rc3.d/S99mysql.server
.
Si demasiados procesos intentan conectarse muy rápidamente a mysqld, se verá este error en el log de MySQL:
Error in accept: Protocol error
Se puede intentar iniciar el servidor con la opción
--back_log=50
como una forma de solución.
(Utilizar -O back_log=50
en versiones
anteriores a MySQL 4).
Solaris no soporta ficheros de núcleo para aplicaciones
setuid()
, de forma que no se logrará un
fichero de núcleo a partir de mysqld si se
está empleando la opción --user
.
Generalmente se puede utilizar un binario de Solaris 2.6 en Solaris 2.7 y 2.8. La mayoría de los problemas mencionados bajo Solaris 2.6 también se aplican a Solaris 2.7 y 2.8.
MySQL debería detectar automáticamente nuevas vesiones de Solaris y habilitar soluciones específicas para los siguientes problemas.
Solaris 2.7/2.8 tiene algunos errores en los ficheros de inclusión. Se obtiene el siguiente error al usar gcc:
/usr/include/widec.h:42: warning: `getwc' redefined /usr/include/wchar.h:326: warning: this is the location of the previous definition
Si ocurre eso, puede solucionarse copiando
/usr/include/widec.h
a
.../lib/gcc-lib/os/gcc-version/include
y
cambiando la línea 41:
#if !defined(lint) && !defined(__lint)
Colocando esta:
#if !defined(lint) && !defined(__lint) && !defined(getwc)
Como alternativa, puede editarse directamente el fichero
/usr/include/widec.h
. En cualquiera de
las dos formas, se debe eliminar
config.cache
y ejecutar
configure nuevamente.
Si se obtienen los siguientes errores al ejecutar
make, es debido a que
configure no detectó correctamente el
fichero curses.h
(probablemente a causa
del error en /usr/include/widec.h
):
In file included from mysql.cc:50: /usr/include/term.h:1060: syntax error before `,' /usr/include/term.h:1081: syntax error before `;'
La solución es hacer algo de lo siguiente:
Configure con CFLAGS=-DHAVE_CURSES_H
CXXFLAGS=-DHAVE_CURSES_H ./configure
.
Editar /usr/include/widec.h
como se
indicó anteriormente y ejecutar de nuevo
configure.
Quitar la línea #define HAVE_TERM
del
fichero config.h
y ejecutar de nuevo
make.
Si el enlazador no puede hallar -lz
cuando
enlaza programas cliente, probablemente el problema sea que el
fichero libz.so
se instaló en
/usr/local/lib
. Este problema puede
resolverse con alguno de los siguientes métodos:
Agregar /usr/local/lib
a
LD_LIBRARY_PATH
.
Agregar un vínculo a libz.so
desde
/lib
.
Si se está utilizando Solaris 8, se puede instalar el
opcional zlib
desde el CD de
distribución del sistema operativo.
Ejecutar configure con la opción
--with-named-z-libs=no
cuando se
compila MySQL.
En Solaris 8 sobre x86, mysqld realiza un
volcado de núcleo si se quitan los símbolos de depuración
utilizando strip
.
Si se emplea gcc o egcs en Solaris x86 y se experimentan problemas con volcados de núcleo bajo carga, se debería usar el siguiente comando configure:
CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \ CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti -DHAVE_CURSES_H" \ ./configure --prefix=/usr/local/mysql
Esto evita inconvenientes con la biblioteca
libstdc++
y con excepciones de C++.
Si esto no funciona, se deberá compilar una versión de depuración y ejecutarla con un fichero de seguimiento (trace) o bajo gdb. Consulte Sección D.1.3, “Depurar mysqld con gdb”.
Esta sección proporciona información sobre el uso de MySQL en variantes de BSD Unix.
Para ejecutar MySQL se recomienda FreeBSD 4.x o posterior,
porque el paquete de subprocesos está mucho más integrado.
Para lograr un sistema seguro y estable, se deberían emplear
solamente kernels de FreeBSD marcados con
-RELEASE
.
La forma más fácil (y más empleada) de instalar MySQL es
utilizar los ports (herramientas para crear, actualizar, y
quitar paquetes de aplicaciones) de
mysql-server y
mysql-client
disponibles en
http://www.freebsd.org/. Utilizar estos ports
conlleva los siguiente benficios:
Un servidor MySQL funcional, con todas las optimizaciones conocidas para la versión de FreeBSD donde se instala.
Configuración y compilación automáticas.
Scripts de inicio instalados en
/usr/local/etc/rc.d
.
Es posible emplear pkg_info -L
para ver
los ficheros que hay instalados.
Es posible emplear pkg_delete
para
quitar MySQL del ordenador.
Se recomienda utilizar MIT-pthreads en FreeBSD 2.x, y los subprocesos (threads) nativos en la Versión 3 en adelante. En algunas versiones 2.2.x es posible utilizar subprocesos nativos, pero pueden aparecer problemas al finalizar mysqld.
Desafortunadamente, ciertas llamadas a funciones en FreeBSD no
son todavía totalmente aptas para subprocesos. Sobre todo,
esto incluye a la función gethostbyname()
,
la cual es utilizada por MySQL para convertir nombres de host
en direcciones IP. Bajo ciertas circunstancias, el proceso
mysqld de repente absorbe el 100% de la
capacidad de la CPU y deja de responder. Si ocurre este
problema, inténtese iniciar MySQL usando la opción
--skip-name-resolve
.
Alternativamente puede enlazarse MySQL en FreeBSD 4.x empleando la biblioteca LinuxThreads, la cual evita algunos problemas que tiene la implementación de subprocesos nativa de FreeBSD. Puede encontrarse una muy buena comparación entre LinuxThreads y la implementación nativa en el artículo de Jeremy Zawodny FreeBSD or Linux for your MySQL Server? (FreeBSD o Linux para su Servidor MySQL?) en http://jeremy.zawodny.com/blog/archives/000697.html.
Los problemas conocidos al utilizar LinuxThreads en FreeBSD son:
Los valores de tiempos de conexión
(wait_timeout
,
interactive_timeout
y
net_read_timeout
) no se respetan. El
síntoma es que las conexiones persistentes se congelan
por un tiempo muy largo, sin cerrarse, y matar ('kill') el
subproceso no tendrá efecto hasta que éste pase al
siguiente comando.
Esto probablemente sea un indicio de un problema en el manejo de señales en la biblioteca de procesos, donde la señal no interrumpe una lectura pendiente. Se supone que esto se resolvió en FreeBSD 5.0
El proceso de compilación de MySQL necesita GNU make (gmake) para llevarse a cabo. Si no está disponible GNU make, habrá que instalarlo antes de compilar MySQL.
La forma recomendada de compilar e instalar MySQL en FreeBSD con gcc (2.95.2 y superior) es:
CC=gcc CFLAGS="-O2 -fno-strength-reduce" \ CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions \ -felide-constructors -fno-strength-reduce" \ ./configure --prefix=/usr/local/mysql --enable-assembler gmake gmake install cd /usr/local/mysql bin/mysql_install_db --user=mysql bin/mysqld_safe &
Si se tiene conocimiento de que configure utiliza MIT-pthreads, se debería leer las notas para MIT-pthreads. Consulte Sección 2.8.5, “Notas sobre MIT-pthreads”.
Si se obtiene un error de make install
donde anuncia que no se puede hallar el fichero
/usr/include/pthreads
, es porque
configure no detectó que se necesitan
MIT-pthreads. Para solucionar este problema, debe eliminarse
config.cache
, y luego ejecutar nuevamente
configure con la opción
--with-mit-threads
.
Se debe estar seguro de que la configuración de resolución
de nombres es la correcta. De otras maneras, se pueden
experimentar demoras o fallas al conectarse a
mysqld. También hay que verificar que sea
correcta la entrada para localhost
en el
fichero /etc/hosts
. El fichero debería
comenzar con una línea similar a esta:
127.0.0.1 localhost localhost.your.domain
Se sabe que FreeBSD tiene en forma predeterminada un límite
de manejadores de ficheros muy bajo. Consulte
Sección A.2.17, “No se encontró el fichero”. Hay que iniciar el
servidor utilizando la opción
--open-files-limit
para
mysqld_safe, o elevar en el fichero
/etc/login.conf
el límite para el
usuario mysqld y recompilarlo con
cap_mkdb /etc/login.conf
. También hay que
asegurarse de establecer la clase apropiada de usuario en el
fichero de contraseñas si no se está empleando el
predeterminado (utilizar chpass
mysqld-user-name
). Consulte
Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
Si se dispone de mucha memoria,se podría considerar la
recompilación del kernel para permitirle a MySQL utilizar
más de 512Mb de RAM. Para más información, ver la
opción MAXDSIZ
en el fichero de
configuración LINT.
Si se tienen problemas con la fecha actual en MySQL, podría
ser de ayuda establecer al valor de la variable
TZ
. Consulte
Apéndice E, Variables de entorno.
Para compilar en NetBSD, se necesitará GNU
make. De otro modo, el proceso fallará
cuando make intente ejecutar
lint
en ficheros de C++.
En OpenBSD versión 2.5, se puede compilar MySQL con subprocesos nativos empleando las siguientes opciones:
CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no
Si se obtiene un error como Error in accept:: Bad
file descriptor
o el error 9 al intentar abrir
tablas o directorios, el problema podría ser que no se tienen
asignados suficientes descriptores de fichero para MySQL.
En este caso, hay que intentar iniciar
mysqld_safe como root
con las siguientes opciones:
mysqld_safe --user=mysql --open-files-limit=2048 &
Si se obtiene el siguiente error al compilar con MySQL, es porque el valor de ulimit para la memoria virtual es muy bajo:
item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)': item_func.h:28: virtual memory exhausted make[2]: *** [item_func.o] Error 1
Debe intentarse emplear ulimit -v 80000 y ejecutar make nuevamente. Si esto no funciona y se está utilizando bash, cambiar a csh o sh; algunos usuarios de BSDI han informado problemas con bash y el comando ulimit.
Si se está empleando gcc, también se
tendrá que utilizar el flag
--with-low-memory
para
configure para poder compilar
sql_yacc.cc
.
Si se tienen problemas con la fecha actual en MySQL, podría
ser de ayuda establecer al valor de la variable
TZ
. Consulte
Apéndice E, Variables de entorno.
Se debe actualizar a BSD/OS Versión 3.1. Si no es posible, instalar el parche BSDI M300-038.
Utilizar el siguiente comando al configurar MySQL:
env CXX=shlicc++ CC=shlicc2 \ ./configure \ --prefix=/usr/local/mysql \ --localstatedir=/var/mysql \ --without-perl \ --with-unix-socket-path=/var/mysql/mysql.sock
También la siguiente manera funciona:
env CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure \ --prefix=/usr/local/mysql \ --with-unix-socket-path=/var/mysql/mysql.sock
Si se desea se puede cambiar la ubicación de los directorios, o no especificar ninguna opción para que se usen los valores predeterminados.
Si se tienen problemas de rendimiento bajo un uso intensivo,
inténtese usar la opción
--skip-thread-priority
con
mysqld. Esto ejecuta todos los subprocesos
con la misma prioridad. En BSDI Versión 3.1, esto dará mejor
rendimiento al menos hasta que BSDI mejore su programador de
subprocesos.
Si se obtiene el error virtual memory
exhausted
al compilar, se debería intentar con
ulimit -v 80000 y ejecutar
make nuevamente. Si esto no funciona y se
está utilizando bash, cambiar a
csh o sh; algunos
usuarios de BSDI han informado problemas con
bash y el comando
ulimit.
BSDI versión 4.x tiene algunos errores relacionados con los subprocesos. Si se desea usar MySQL en esta versión, se debería instalar todos los parches relacionados con subprocesos. Al menos se debería instalar el parche M400-023.
En algunos sistemas BSDI versión 4.x, se pueden tener
problemas con las bibliotecas compartidas. El síntoma es que
no se pueden ejecutar programas cliente, por ejemplo,
mysqladmin. En este caso, se necesitará
reconfigurar con la opción
--disable-shared
para que no se usen
bibliotecas compartidas.
Algunos clientes han tenido problemas con BSDI 4.0.1 donde el binario mysqld no puede abrir tablas pasado un tiempo. Es debido a algunos errores relacionados con el sistema y las bibliotecas que provocan que mysqld cambie el directorio actual sin habérselo solicitado.
La solución puede ser actualizar MySQL a la versión 3.23.34
o posterior o bien, después de ejecutar
configure, quitar la línea
#define HAVE_REALPATH
del fichero
config.h
antes de ejecutar
make.
Nótese que esto significa que en BSDI no se puede enlazar simbólicamente los directorios de una base de datos a otra base de datos o una tabla a otra base de datos. (Sí es posible establecer un vínculo simbólico a otro disco).
Hay un par de pequeños problemas al compilar MySQL en HP-UX. Se recomienda que se utilice gcc en lugar del compilador nativo de HP-UX, ya que gcc produce mejor código.
Se recomienda utilizar gcc 2.95 en HP-UX.
No hay que utilizar flags de optimización intensiva (como
-O6
) porque pueden no ser seguros en HP-UX.
La siguiente línea de configure debería funcionar con gcc 2.95:
CFLAGS="-I/opt/dce/include -fpic" \ CXXFLAGS="-I/opt/dce/include -felide-constructors -fno-exceptions \ -fno-rtti" \ CXX=gcc \ ./configure --with-pthread \ --with-named-thread-libs='-ldce' \ --prefix=/usr/local/mysql --disable-shared
La siguiente línea de configure debería funcionar con gcc 3.1:
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc \ CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors \ -fno-exceptions -fno-rtti -O3 -fPIC" \ ./configure --prefix=/usr/local/mysql \ --with-extra-charsets=complex --enable-thread-safe-client \ --enable-local-infile --with-pthread \ --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC --disable-shared
Debido a algunos errores críticos en las bibliotecas estándar de HP-UX, se deberían instalar los siguientes parches antes de ejecutar MySQL en HP-UX 11.0:
PHKL_22840 Streams cumulative PHNE_22397 ARPA cumulative
Esto soluciona el problema de obtener
EWOULDBLOCK
EWOULDBLOCK
de recv()
y EBADF
de
accept()
en aplicaciones con subprocesos o
hebradas (threaded).
Si se está empleando gcc 2.95.1 en un sistema HP-UX 11.x sin parches, se podría obtener el siguiente error:
In file included from /usr/include/unistd.h:11, from ../include/global.h:125, from mysql_priv.h:15, from item.cc:19: /usr/include/sys/unistd.h:184: declaration of C function ... /usr/include/sys/pthread.h:440: previous declaration ... In file included from item.h:306, from mysql_priv.h:158, from item.cc:19:
El problema es que HP-UX no define
pthreads_atfork()
en forma consistente.
Tiene prototipos conflictivos en
/usr/include/sys/unistd.h
:184 y
/usr/include/sys/pthread.h
:440.
Una solución es copiar
/usr/include/sys/unistd.h
dentro de
mysql/include
y editar
unistd.h
y cambiarlo para que coincida
con la definición en pthread.h
. Hay que
hallar esta línea:
extern int pthread_atfork(void (*prepare)(), void (*parent)(), void (*child)());
Y cambiarla para que sea así:
extern int pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void));
Después de realizar el cambio, la siguiente línea de configure debería funcionar:
CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \ ./configure --prefix=/usr/local/mysql --disable-shared
Si se está empleando el compilador HP-UX, se puede utilizar el siguiente comando (el cual fue probado con cc B.11.11.04):
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure \ --with-extra-character-set=complex
Se podrá ignorar cualquier error de este tipo:
aCC: warning 901: unknown option: `-3': use +help for online documentation
Si se obtiene el siguiente error desde configure, verificar si no se tiene la ruta al compilador K&R antes que la ruta al compilador HP-UX para C y C++:
checking for cc option to accept ANSI C... no configure: error: MySQL requires an ANSI C compiler (and a C++ compiler). Try gcc. See the Installation chapter in the Reference Manual.
Otra razón que puee impedir la compilación es que no se
hayan definido los flags +DD64
tal como se
ha descripto.
Otra posibilidad para HP-UX 11 es emplear los binarios MySQL provistos en http://dev.mysql.com/downloads, los cuales fueron compilados y probados por MySQL AB. También se han recibido informes de que los binarios de MySQL provistos con HP-UX 10.20 se ejecutan correctamente en HP-UX 11. Si se encuentran problemas, se debería verificar si HP-UX tiene todos los parches necesarios.
La detección automática de xlC
no se
encuentra presente en Autoconf, de modo que habrá que
inicializar una cantidad de variables antes de ejecutar
configure. El siguiente ejemplo utiliza el
compilador de IBM:
export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 " export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192" export CFLAGS="-I /usr/local/include" export LDFLAGS="-L /usr/local/lib" export CPPFLAGS=$CFLAGS export CXXFLAGS=$CFLAGS ./configure --prefix=/usr/local \ --localstatedir=/var/mysql \ --sbindir='/usr/local/bin' \ --libexecdir='/usr/local/bin' \ --enable-thread-safe-client \ --enable-large-files
Estas opciones se emplean para compilar la distribución MySQL que se encuentra en http://www-frec.bull.com/.
Si se cambia el -O3
por
-O2
en la linea de
configure anterior, también habrá que
quitar la opción -qstrict
. Esto es una
limitación en el compilador de C de IBM.
Si se está empleando gcc o
egcs para compilar MySQL, se
debe utilizar el flag
-fno-exceptions
, porque la gestión de
excepciones en gcc/egcs
no es apta para subprocesos. (Esto se probó con
egcs 1.1.) También hay algunos problemas
conocidos con el ensamblador de IBM, el cual puede generar
código defectuoso cuando se lo usa con
gcc.
Se recomienda usar la siguiente línea de configure con egcs y gcc 2.95 en AIX:
CC="gcc -pipe -mcpu=power -Wa,-many" \ CXX="gcc -pipe -mcpu=power -Wa,-many" \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory
La opción -Wa,-many
se necesita para que
el proceso de compilación tenga éxito. IBM está al tanto de
este problema pero no tiene urgencia por resolverlo porque hay
disponible una solución alternativa. No se sabe si
-fno-exceptions
se requiere con
gcc 2.95, pero como MySQL no utiliza
excepciones y la opción genera código más rápido, se
recomienda usarlo siempre con egcs /
gcc.
Si se obtiene un problema con el código ensamblador, hay que
cambiar la opción
-mcpu=
para
que concuerde con la CPU del usuario. Generalmente puede
necesitarse xxx
power2
,
power
, o powerpc
. O bien
podría necesitarse 604
o
604e
. No está confirmado, pero se sospecha
que power
puede muy bien ser seguro la
mayoría de las veces, incluso en un ordenador de 2
procesadores.
Si se desconoce el tipo de CPU que se posee, ejecutar un
comando uname -m
. Este produce una cadena
con un aspecto similar a 000514676700
, con
el formato xxyyyyyymmss
, donde
xx
y ss
son siempre
00
, yyyyyy
es un
identificador único de sistema, y mm
es el
identificar de la arquitectura de la CPU. La tabla con estos
valores se encuentra en
http://www16.boulder.ibm.com/pseries/en_US/cmds/aixcmds5/uname.htm.
Esto proporciona el tipo y modelo del ordenador que se está usando.
Si se tienen problemas con señales (MySQL termina abruptamente al someterlo a carga intensiva), puede tratarse de un error del SO relacionado con subprocesos y señales. En este caso, hay que indicarle a MySQL que no utilice señales, configurándolo como sigue:
CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti \ -DDONT_USE_THR_ALARM" \ ./configure --prefix=/usr/local/mysql --with-debug \ --with-low-memory
Esto no afecta el rendimiento de MySQL, pero tiene el efecto secundario de que no se pueden terminar procesos de clientes que están “durmiendo” (“sleeping”) en una conexión usando mysqladmin kill o mysqladmin shutdown. El cliente terminará cuando emita su siguiente comando.
En algunas versiones de AIX, el enlazado con
libbind.a
provoca que
getservbyname()
haga un volcado de núcleo.
Este es un error en AIX y debería informarse a IBM.
Para AIX 4.2.1 y gcc, se deben hacer los siguientes cambios.
Después de configurar, editar config.h
y
include/my_config.h
y cambiar la línea
que dice:
#define HAVE_SNPRINTF 1
a esto:
#undef HAVE_SNPRINTF
Y, finalmente, en mysqld.cc
, se
necesitará agregar un prototipo para
initgroups()
.
#ifdef _AIX41 extern "C" int initgroups(const char *,int); #endif
Si se necesita asginar mucha memoria para el proceso mysqld, no basta con utilizar ulimit -d unlimited. También habrá que modificar mysqld_safe agregando una línea como la siguiente:
export LDR_CNTRL='MAXDATA=0x80000000'
Se puede encontrar más información acerca de usar grandes cantidades de memoria en http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.
En SunOS 4, se necesita MIT-pthreads para compilar MySQL. Esto a su vez significa que que se necesitará GNU make.
Algunos sistemas SunOS 4 tienen problemas con las bibliotecas dinámicas y libtool. Se puede usar la siguiente línea en configure para evitar este problema:
./configure --disable-shared --with-mysqld-ldflags=-all-static
Al compilar readline
, se pueden obtener
advertencias sobre definiciones duplicadas. Estas pueden
ignorarse.
Al compilar mysqld, se producen algunas
advertencias del tipo implicit declaration of
function
que pueden ignorarse.
Si se está utilizando egcs 1.1.2 en Unix Digital, se debería actualizar a gcc 2.95.2, porque egcs tiene algunos errores serios en DEC.
Al compilar programas hebrados (threaded) en Unix Digital, la
documentación recomienda utilizar la opción
-pthread
con cc y
cxx y las bibliotecas -lmach
-lexc
(adicionalmente a
-lpthread
). Se debería ejecutar
configure de una forma parecida a esta:
CC="cc -pthread" CXX="cxx -pthread -O" \ ./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"
Cuando se compila mysqld, se podrían ver un par de advertencias similares a estas:
mysqld.cc: In function void handle_connections()': mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockadddr *, int *)'
Pueden ser ignoradas sin problemas. Ocurren porque configure sólo puede detectar errores y no advertencias.
Si se inicia el servidor directamente desde la línea de
comandos, se podría tener el problema de que finalice al
terminar la sesión de usuario en el SO. (Cuando se termina la
sesión, los procesos pendientes reciben una señal
SIGHUP
). Si eso sucede, debe intentarse
iniciar el servidor de esta manera:
nohup mysqld [options
] &
nohup
provoca que el comando a
continuación ignore cualquier señal
SIGHUP
enviada desde la terminal.
Alternativamente, se puede iniciar el servidor ejecutando
mysqld_safe, lo cual invoca a
mysqld usando nohup.
Consulte Sección 5.1.3, “El script de arranque del servidor mysqld_safe”.
Si se tiene un problema al compilar
mysys/get_opt.c
, quítese la linea
#define _NO_PROTO
del comienzo de dicho
fichero.
Si se está empleando el compilador CC de Compaq, la siguiente línea de configure debería funcionar:
CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all \ -arch host -noexceptions -nortti" export CC CFLAGS CXX CXXFLAGS ./configure \ --prefix=/usr/local/mysql \ --with-low-memory \ --enable-large-files \ --enable-shared=yes \ --with-named-thread-libs="-lpthread -lmach -lexc -lc" gnumake
Si al compilar mysql se tienen problemas con libtool usando bibliotecas compartidas como se indicó, se puede evitar el problema empleando estos comandos:
cd mysql /bin/sh ../libtool --mode=link cxx -pthread -O3 -DDBUG_OFF \ -O4 -ansi_alias -ansi_args -fast -inline speed \ -speculate all \ -arch host -DUNDEF_HAVE_GETHOSTBYNAME_R \ -o mysql mysql.o readline.o sql_string.o completion_hash.o \ ../readline/libreadline.a -lcurses \ ../libmysql/.libs/libmysqlclient.so -lm cd .. gnumake gnumake install scripts/mysql_install_db
Si ocurren problemas al compilar y se tienen instalados DEC CC y gcc, se debe intentar ejecutar configure de este modo:
CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Si ocurren problemas con el fichero
c_asm.h
, se puede crear y utilizar un
fichero c_asm.h
"silencioso" con:
touch include/c_asm.h CC=gcc CFLAGS=-I./include \ CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Tener en cuenta que los siguientes problemas con el programa ld pueden ser corregidos descargando el último conjunto de parches para DEC (Compaq) desde: http://ftp.support.compaq.com/public/unix/.
En OSF/1 V4.0D y el compilador "DEC C V5.6-071 on Digital Unix
V4.0 (Rev. 878)", el compilador tiene algún comportamiento
extraño (símbolos asm
indefinidos)
/bin/ld
también parece estar defectuoso
(durante el enlazado de mysqld ocurren
errores del tipo _exit undefined
). En estos
sistemas se optó por compilar MySQL con la siguiente línea
de configure, reemplazando
/bin/ld
con la versión para OSF 4.OC.
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
Con el compilador Digital "C++ V6.1-029", se debería hacer lo siguiente:
CC=cc -pthread CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed \ -speculate all -arch host CXX=cxx -pthread CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed \ -speculate all -arch host -noexceptions -nortti export CC CFLAGS CXX CXXFLAGS ./configure --prefix=/usr/mysql/mysql \ --with-mysqld-ldflags=-all-static --disable-shared \ --with-named-thread-libs="-lmach -lexc -lc"
En algunas versiones OSF/1, la función
alloca()
está defectuosa. Esto se
soluciona quitando la línea de config.h
que define 'HAVE_ALLOCA'
.
La función alloca()
puede tener también
un prototipo incorrecto en
/usr/include/alloca.h
. Esta advertencia
resultante de esa situación puede ignorarse.
configure utiliza automáticamente la
siguiente libreria de subprocesos:
--with-named-thread-libs="-lpthread -lmach -lexc
-lc"
.
Al utilizar gcc, se debería ejecutar configure de este modo:
CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ...
Si se tienen problemas con señales (MySQL termina abruptamente al someterlo a carga intensiva), puede tratarse de un error del SO relacionado con subprocesos y señales. En este caso, hay que indicarle a MySQL que no utilice señales, configurándolo como sigue:
CFLAGS=-DDONT_USE_THR_ALARM \ CXXFLAGS=-DDONT_USE_THR_ALARM \ ./configure ...
Esto no afecta el rendimiento de MySQL, pero tiene el efecto secundario de que no se pueden terminar procesos de clientes que están “durmiendo” (“sleeping”) en una conexión usando mysqladmin kill o mysqladmin shutdown. El cliente terminará cuando emita su siguiente comando.
Con gcc 2.95.2, se puede encontrar el siguiente error de compilación:
sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566 Please submit a full bug report.
Para solucionar esto, habría que posicionarse en el
directorio sql
, y cortar y pegar la última
línea de gcc, pero cambiando
-O3
por -O0
(o agregando
-O0
inmediatamente después de
gcc si no se tiene ninguna opción
-O
en la línea de compilación). Luego de
hacer esto, se puede volver al directorio principal
(top-level) y ejecutar nuevamente make.
Si se está utilizando Irix Versión 6.5.3 o posterior,
mysqld será capaz de crear procesos
únicamente si se lo ejecutó como un usuario con privilegios
CAP_SCHED_MGT
(como el usuario
root
) o bien darle este privilegio al
servidor mysqld con el siguiente comando
del shell:
chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld
Es posible que haya que quitar la definición de algunos
símbolos en config.h
luego de ejecutar
configure y antes de compilar.
En algunas implementaciones de Irix, la función
alloca()
está defectuosa. Si el servidor
mysqld termina abruptamente en algunas
sentencias SELECT
, deberán quitarse de
config.h
las líneas que definen
HAVE_ALLOC
y
HAVE_ALLOCA_H
. Si mysqladmin
create no funciona, habrá que quitar de
config.h
la línea que define
HAVE_READDIR_R
. También es posible que
haya que quitar la línea HAVE_TERM_H
.
SGI recomienda que se instalen en conjunto todos los parches de esta página: http://support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html
Como mínimo, se deberían instalar las últimas versiones del
kernel, de rld
, y de
libc
.
Definitivamente serán necesarios todos los parches POSIX de esta página, para dar soporte a pthreads:
http://support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html
Si se obtiene el siguiente error al compilar
mysql.cc
:
"/usr/include/curses.h", line 82: error(1084): invalid combination of type
Habrá que tipear lo siguiente en el directorio principal del árbol de código fuente de MySQL:
extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h make
También se informaron problemas de sincronización (scheduling). Si sólo se está ejecutando un proceso, el rendimiento es bajo. Esto se evita iniciando otro cliente. Esto puede conducir a un incremento en la velocidad de dos a diez veces de ese momento en adelante para el otro hilo. Es este un problema difícil de entender con los suprocesos de Irix; habrá que improvisar para hallar soluciones hasta que sea arreglado.
Si se está compilando con gcc, se puede usar el siguiente comando de configure:
CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql --enable-thread-safe-client \ --with-named-thread-libs=-lpthread
Lo siguiente funciona en Irix 6.5.11 con compiladores nativos Irix C y C++ versión 7.3.1.2.
CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \ -L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \ -I/usr/local/include -L/usr/local/lib' \ ./configure --prefix=/usr/local/mysql --with-innodb --with-berkeley-db \ --with-libwrap=/usr/local \ --with-named-curses-libs=/usr/local/lib/libncurses.a
El port actual se probó solamente en sistemas sco3.2V5.0.5, sco3.2v5.0.6, y sco3.2v5.0.7. También está en desarrollo un port para sco3.2v4.2. Open Server 5.0.8 (Legend) tiene soporte nativo para subprocesos y permite ficheros de más de 2GB. Actualmente el máximo tamaño de fichero permitido es 2GB.
En MySQL AB se pudo compilar MySQL con el siguiente comando de configure en OpenServer con gcc 2.95.3.
CC=gcc CXX=gcc ./configure --prefix=/usr/local/mysql \ --enable-thread-safe-client --with-innodb \ --with-openssl --with-vio --with-extra-charsets=complex
gcc puede descargarse de ftp://ftp.sco.com/pub/openserver5/opensrc/gnutools-5.0.7Kj.
Este sistema de desarrollo requiere el Suplemento del Entorno
de Ejecución de OpenServer (OpenServer Execution Environment
Supplement) oss646B en OpenServer 5.0.6 y oss656B y las
bibliotecas OpenSource halladas en gwxlibs. Todas las
herramientas OpenSource están en el directorio
opensrc
, en
ftp://ftp.sco.com/pub/openserver5/opensrc/.
MySQL AB recomienda utilizar el último release en producción de MySQL.
SCO proporciona parches del sistema operativo en ftp://ftp.sco.com/pub/openserver5 para OpenServer 5.0.[0-6] y ftp://ftp.sco.com/pub/openserverv5/507 para OpenServer 5.0.7.
SCO proporciona información sobre problemas de seguridad solucionados en ftp://ftp.sco.com/pub/security/OpenServer para OpenServer 5.0.x.
El máximo tamaño de fichero en un sistema OpenServer 5.0.x es 2GB.
La memoria total que puede direccionarse para buffers de streams, clists, y bloqueo de registros, no puede exceder de 60MB en OpenServer 5.0.x.
Los buffers de streams son direccionados en páginas de 4096 bytes, los clists en páginas de 70 bytes, y los bloqueos de registros en páginas de 64 bytes, de modo que:
(NSTRPAGES * 4096) + (NCLIST * 70) + (MAX_FLCKREC * 64) <= 62914560
Seguir este procedimiento para configurar la opción Servicios de Base de Datos (Database Services). Si no se está seguro si una aplicación requiere esto, ver la documentación de la aplicación.
Iniciar sesión como root
.
Habilitar el driver SUDS mediante la edición del fichero
/etc/conf/sdevice.d/suds
. Cambiar la
N
del segundo párrafo por una
Y
.
Utilizar mkdev aio
o el Gestor de
Hardware/Kernel (Hardware/Kernel Manager) para habilitar
el soporte de entrada/salida asincrónica, y enlazar
nuevamente el kernel. Para permitir a los usuarios
reservar memoria para usar con este tipo de E/S,
actualizar el fichero aiomemlock(F). Este fichero debería
actualizarse para que incluya los nombre de los usuarios
que pueden utilizar ESA (Entrada Salida Asincrónica, o
AIO, Asynchronoys I/O) y las máximas cantidades de
memoria que pueden reservar.
Muchas aplicaciones usan binarios setuid de forma que solamente se necesita especificar un único usuario. Ver la documentación provista con la aplicación para ver si este es su caso.
Después de completar este proceso, reiniciar el sistema para crear un nuevo kernel que incorpore estos cambios.
Por defecto, las entradas en
/etc/conf/cf.d/mtune
están configuradas
así:
Value Default Min Max ----- ------- --- --- NBUF 0 24 450000 NHBUF 0 32 524288 NMPBUF 0 12 512 MAX_INODE 0 100 64000 MAX_FILE 0 100 64000 CTBUFSIZE 128 0 256 MAX_PROC 0 50 16000 MAX_REGION 0 500 160000 NCLIST 170 120 16640 MAXUP 100 15 16000 NOFILES 110 60 11000 NHINODE 128 64 8192 NAUTOUP 10 0 60 NGROUPS 8 0 128 BDFLUSHR 30 1 300 MAX_FLCKREC 0 50 16000 PUTBUFSZ 8000 2000 20000 MAXSLICE 100 25 100 ULIMIT 4194303 2048 4194303 * Streams Parameters NSTREAM 64 1 32768 NSTRPUSH 9 9 9 NMUXLINK 192 1 4096 STRMSGSZ 16384 4096 524288 STRCTLSZ 1024 1024 1024 STRMAXBLK 524288 4096 524288 NSTRPAGES 500 0 8000 STRSPLITFRAC 80 50 100 NLOG 3 3 3 NUMSP 64 1 256 NUMTIM 16 1 8192 NUMTRW 16 1 8192 * Semaphore Parameters SEMMAP 10 10 8192 SEMMNI 10 10 8192 SEMMNS 60 60 8192 SEMMNU 30 10 8192 SEMMSL 25 25 150 SEMOPM 10 10 1024 SEMUME 10 10 25 SEMVMX 32767 32767 32767 SEMAEM 16384 16384 16384 * Shared Memory Parameters SHMMAX 524288 131072 2147483647 SHMMIN 1 1 1 SHMMNI 100 100 2000 FILE 0 100 64000 NMOUNT 0 4 256 NPROC 0 50 16000 NREGION 0 500 160000
Se recomienda establecer estos valores de la siguiente manera:
NOFILES
debería ser 4096 o 2048.
MAXUP
debería ser 2048.
Para hacer cambios al kernel, posicionarse con
cd
en el directorio
/etc/conf/bin
y utilizar
./idtune nombre
parámetro
para realizar los cambios. Por
ejemplo, para cambiar SEMMS
a un valor de
200
, ejecutar estos comandos como usuario
root
:
# cd /etc/conf/bin # ./idtune SEMMNS 200
Se recomienda optimizar el sistema, pero los valores a
utilizar dependerán del número de usuarios que acceden a la
aplicación o base de datos y el tamaño de la base de datos
(esto es, el pool de buffer utilizado). Lo siguiente modifica
los parámetros de kernel definidos en
/etc/conf/cf.d/stune
:
SHMMAX
(valor recomendado: 128MB) and
SHMSEG
(valor recomendado: 15). Estos
parámetros inciden en el motor de base de datos MySQL para la
creación de pools de buffers de usuario).
NOFILES
y MAXUP
deberían establecerse en por lo menos 2048.
MAXPROC
debería establecerse al menos en
3000/4000 (dependiendo del número de usuarios) o más.
También se recomienda el empleo de la siguiente fórmula para
calcular el valor para SEMMSL
,
SEMMNS
y SEMMNU
:
SEMMSL = 13
El 13 es lo que se halló como el mejor valor para Progress y MySQL.
SEMMNS
= SEMMSL
*
cantidad de servidores de bases de datos a ejecutarse en el
sistema.
Establecer SEMMNS
al valor de
SEMMSL
multiplicado por la cantidad de
servidores de bases de datos (máximo) que se ejecutan en el
sistema al mismo tiempo.
SEMMNU = SEMMNS
Establecer el valor de SEMMNU
al mismo
valor que tiene SEMMNS
. Posiblemente se
pueda establecer a un 75% del valor de
SEMMNS
, pero esta es una estimación
conservadora.
Se necesitará instalar al menos las "Bibliotecas de Desarrollo de Aplicaciones y Enlazador OpenServer de SCO" ("SCO OpenServer Linker and Application Development Libraries") o el Sistema de Desarrollo de OpenServer (OpenServer Development System) para ejecutar gcc. No se puede simplemente emplear el sistema de desarrollo GCC sin instalar alguno de los mencionados.
Antes se deberá obtener el paquete FSU Pthreads e instalarlo. Puede descargarse de http://moss.csc.ncsu.edu/~mueller/ftp/pub/PART/pthreads.tar.gz. También puede descargarse un paquete precompilado en ftp://ftp.zenez.com/pub/zenez/prgms/FSU-threads-3.14.tar.gz.
FSU Pthreads puede compilarse con SCO Unix 4.2 con tcpip, o
utilizando OpenServer 3.0 u OpenDesktop 3.0 (OS 3.0 ODT 3.0)
con el SCO Development System instalado utilizando un buen
port de GCC 2.5.x. Hay muchos problemas que ocurren sin un
buen port. El port para este producto necesita el SCO Unix
Development System. Sin él, no se tendrán las bibliotecas y
el enlazador que se necesitan. También se requiere el fichero
SCO-3.2v4.2-includes.tar.gz
. Este fichero
contiene los cambios a los ficheros de inclusión de SCO
Development que se necesitan para lograr compilar MySQL.
Habrá que reemplazar los ficheros de inclusión existentes en
el sistema con estos ficheros de cabecera modificados. Pueden
descargarse de
ftp://ftp.zenez.com/pub/zenez/prgms/SCO-3.2v4.2-includes.tar.gz.
Todo lo que se debería necesitar para compilar FSU Pthreads
es ejecutar GNU make. El
Makefile
en FSU-threads-3.14.tar.gz está
configurado para crear FSU-threads.
Se puede ejecutar ./configure en el
directorio threads/src
y seleccionar la
opción SCO OpenServer. Este comando copia
Makefile.SCO5
a
Makefile
. Luego, se ejecuta
make.
Para instalar en el directorio predeterminado
/usr/include
, iniciar sesión como
root
, luego posicionarse con
cd
en el directorio
thread/src
y ejecutar make
install.
Recordar que debe usarse GNU make para crear MySQL.
Nota: Si no se inicia
mysqld_safe como usuario
root
, se deberían obtener solamente por
defecto los 110 ficheros abiertos por proceso.
mysqld deja constancia de esto en el
fichero de registro (log).
Con SCO 3.2V4.2, se debería usar FSU Pthreads versión 3.14 o posterior. El siguiente comando configure debería funcionar:
CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \ ./configure \ --prefix=/usr/local/mysql \ --with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \ --with-named-curses-libs="-lcurses"
Se pueden tener problemas con algunos ficheros de inclusión. En este caso, pueden hallarse nuevos ficheros de inclusión específicos para SCO en ftp://ftp.zenez.com/pub/zenez/prgms/SCO-3.2v4.2-includes.tar.gz.
Se debería descompactar este fichero en el directorio
include
del árbol de código fuente de
MySQL.
Notas relativas a SCO development:
MySQL debería detectar automáticamente FSU Pthreads y
enlazar mysqld con -lgthreads
-lsocket -lgthreads
.
Las bibliotecas de desarrollo SCO son reentrantes (compartidas por varios usuarios o procesos, una condición indispensable en la programación de multitarea) en FSU Pthreads. SCO afirma que sus bibliotecas de funciones son reentrantes, por lo tanto deben ser reentrantes con FSU Pthreads. FSU Pthreads en OpenServer intenta utilizar el esquema de SCO para hacer bibliotecas reentrantes.
FSU Pthreads (al menos la versión en
ftp::/ftp.zenez.com) viene enlazada con GNU
malloc
. Si ocurren problemas con el uso
de memoria, asegurarse de que
gmalloc.o
está incluido en
libgthreads.a
y
libgthreads.so
.
En FSU Pthreads, las siguientes llamadas de sistema son
compatibles con pthreads: read()
,
write()
, getmsg()
,
connect()
, accept(),
select()
, y wait()
.
El parche CSSA-2001-SCO.35.2 (habitualmente listado como erg711905-dscr_remap security patch (version 2.0.0)) interrumpe los subprocesos FSU y deja inestable a mysqld. Hay que removerlo si se desea ejecutar mysqld en un ordenador con OpenServer 5.0.6.
SCO proporciona parches del sistema operativo OpenServer 5.0.x en ftp://ftp.sco.com/pub/openserver5.
Las soluciones a problemas de seguridad y
libsocket.so.2
para OpenServer 5.0.x
están en
ftp://ftp.sco.com/pub/security/OpenServer y
ftp://ftp.sco.com/pub/security/sse.
Soluciones de seguridad para Pre-OSR506. También, la
solución para telnetd
en
ftp://stage.caldera.com/pub/security/openserver/
o
ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.10/
así como libsocket.so.2
y
libresolv.so.1
con instrucciones para
instalar en sistemas pre-OSR506.
Probablemente sea una buena idea instalar estos parches antes de compilar o utilizar MySQL.
A partir de Legend/OpenServer 6.0.0 se dispone de subprocesos nativos y se eliminó el límite de 2GB para el tamaño de los ficheros.
Se recomienda utilizar el último release de producción de MySQL.
Se ha logrado compilar MySQL con el siguiente comando configure en UnixWare versión 7.1.x:
CC="cc" CFLAGS="-I/usr/local/include" \ CXX="CC" CXXFLAGS="-I/usr/local/include" \ ./configure --prefix=/usr/local/mysql \ --enable-thread-safe-client --with-berkeley-db=./bdb \ --with-innodb --with-openssl --with-extra-charsets=complex
Si se desea utilizar gcc, debe ser la versión 2.95.3 o posterior.
CC=gcc CXX=g++ ./configure --prefix=/usr/local/mysql
La versión de Berkeley DB que viene con UnixWare 7.1.4 u
OpenServer 6.0.0 no se utiliza cuando se compila MySQL. En su
lugar, MySQL utiliza su propia versión de Berkeley DB. El
comando configure necesita compilar tanto
una biblioteca estática como una dinámica en
,
pero no utiliza la versión de Berkeley DB que MySQL necesita.
La solución es la siguiente.
src_directory
/bdb/build_unix/
Configurar para MySQL como de costumbre.
cd bdb/build_unix/
cp -p Makefile to Makefile.sav
Emplear las mismas opciones y ejecutar ../dist/configure.
Ejecutar gmake.
cp -p Makefile.sav Makefile
Posicionarse en el directorio principal o raíz de código fuente y ejecutar gmake.
Esto posibilita que tanto la biblioteca dinámica como la estática sean creadas y funcionen.
SCO proporciona parches de sistema operativo en ftp://ftp.sco.com/pub/unixware7 para UnixWare 7.1.1, ftp://ftp.sco.com/pub/unixware7/713/ para UnixWare 7.1.3, ftp://ftp.sco.com/pub/unixware7/714/ para UnixWare 7.1.4, y ftp://ftp.sco.com/pub/openunix8 para OpenUNIX 8.0.0.
SCO proporciona información sobre soluciones a problemas de seguridad en ftp://ftp.sco.com/pub/security/OpenUNIX para OpenUNIX y ftp://ftp.sco.com/pub/security/UnixWare para UnixWare.
En forma predeterminada, el máximo tamaño de fichero en un sistema UnixWare 7.1.1 es de 1GB, pero en UnixWare 7.1.4 es de 1TB con VXFS. Algunas utilidades del Sistema Operativo tienen una limitación de 2GB. El máximo tamaño posible para ficheros de UnixWare 7 es 1TB con VXFS.
En UnixWare 7.1.4 no se necesita ninguna acción en especial
para que soporte ficheros de gran tamaño, pero para
habilitarlo en versiones anteriores de UnixWare 7.1.x, hay que
ejecutar fsadm
.
# fsadm -Fvxfs -o largefiles / # fsadm / * Nota # ulimit unlimited # cd /etc/conf/bin # ./idtune SFSZLIM 0x7FFFFFFF ** Nota # ./idtune HFSZLIM 0x7FFFFFFF ** Nota # ./idbuild -B * Este comando debería informar "largefiles". ** El valor 0x7FFFFFFF representa "infinito" (sin límite) para esos valores.
Reiniciar el sistema empleando shutdown
.
por defecto, las entradas en
/etc/conf/cf.d/mtune
están establecidas
en:
Value Default Min Max ----- ------- --- --- SVMMLIM 0x9000000 0x1000000 0x7FFFFFFF HVMMLIM 0x9000000 0x1000000 0x7FFFFFFF SSTKLIM 0x1000000 0x2000 0x7FFFFFFF HSTKLIM 0x1000000 0x2000 0x7FFFFFFF
Se recomienda establecer estos valores como sigue:
SDATLIM 0x7FFFFFFF HDATLIM 0x7FFFFFFF SSTKLIM 0x7FFFFFFF HSTKLIM 0x7FFFFFFF SVMMLIM 0x7FFFFFFF HVMMLIM 0x7FFFFFFF SFNOLIM 2048 HFNOLIM 2048
Se recomienda ajustar el sistema, pero los valores de los
parámetros a emplear dependen del número de usuarios que
accederán a la aplicación o la base de datos y el tamaño de
la base de datos (es decir, el uso que se hará del buffer
pool -un caché de tablas y páginas-). Lo que sigue modifica
los parámetros del kernel definidos en
/etc/conf/cf.d/stune
:
SHMMAX
(valor recomendado: 128MB) y
SHMSEG
(valor recomendado: 15). Estos
parámetros influyen en la forma en que el motor de bases de
datos crea los buffer pools.
SFNOLIM
y HFNOLIM
deberían ser como máximo 2048.
NPROC
debería establecerse a por lo menos
3000/4000 (dependiendo del número de usuarios).
También se recomienda emplear la siguiente fórmula para
calcular los valores de SEMMSL
,
SEMMNS
, y SEMMNU
:
SEMMSL = 13
13 es el valor que se halló como el mejor para Progress y MySQL.
SEMMNS
= SEMMSL
*
cantidad de servidores de bases de datos a ejecutar en el
sistema.
Establecer SEMMNS
al valor de
SEMMSL
multiplicado por el número máximo
de servidores que se ejecutarán en el sistema al mismo
tiempo.
SEMMNU
= SEMMNS
Establecer el valor de SEMMNU
al mismo
valor que tiene SEMMNS
. Posiblemente se
pueda establecer a un 75% del valor de
SEMMNS
, pero esta es una estimación
conservadora.
Las mejoras clave en OpenServer 6 incluyen:
Soporte para ficheros más grandes, hasta 1 TB
Soporte para multiprocesadores incrementado de 4 a 32 procesadores.
Incremento del soporte de memoria hasta 64 GB.
Se extendió la potencia de UnixWare dentro de OpenServer 6.
Mejora dramática del rendimiento.
OpenServer 6.0.0 tiene las siguientes particularidades:
/bin
es para comandos que se
comportan exactamente del mismo modo que OpenServer
5.0.x.
/u95/bin
es para comandos que
están más en conformidad con los estándares, por
ejemplo el soporte para el Sistema de Ficheros Grandes o
LFS (Large File System).
/udk/bin
es para comandos que se
comportan igual que en UnixWare 7.1.4. por defecto, el
soporte para LFS.
La siguiente es una guía para configurar PATH en OpenServer
6. Si el usuario desea el OpenServer 5.0.x tradicional
entonces PATH
debería ser en primer lugar
/bin
. Si el usuario desea soporte para
LFS entonces el PATH debería ser
/u95/bin:/bin
. Si desea primariamente
soporte para UnixWare 7, debería ser
/udk/bin:/u95/bin:/bin:
.
Se recomienda utilizar el último release de producción de MySQL
En OpenServer Versión 6.0.x se ha logrado compilar MySQL con el siguiente comando configure:
CC="cc" CFLAGS="-I/usr/local/include" \ CXX="CC" CXXFLAGS="-I/usr/local/include" \ ./configure --prefix=/usr/local/mysql \ --enable-thread-safe-client --with-berkeley-db=./bdb \ --with-innodb --with-openssl --with-extra-charsets=complex \ --enable-readline
Si se desea emplear gcc, debe ser gcc 2.95.3 o posterior.
CC=gcc CXX=g++ ./configure --prefix=/usr/local/mysql
La versión de Berkeley DB que viene con UnixWare 7.1.4 u
OpenServer 6.0.0 no se utiliza cuando se compila MySQL. En su
lugar, MySQL utiliza su propia versión de Berkeley DB. El
comando configure necesita compilar tanto
una biblioteca estática como una dinámica en
,
pero no utiliza la versión de Berkeley DB que MySQL necesita.
La solución es la siguiente.
src_directory
/bdb/build_unix/
Configurar para MySQL como de costumbre.
cd bdb/build_unix/
cp -p Makefile to Makefile.sav
Emplear las mismas opciones y ejecutar ../dist/configure.
Ejecutar gmake.
cp -p Makefile.sav Makefile
Posicionarse en el directorio principal o raíz de código fuente y ejecutar gmake.
Esto posibilita que tanto la biblioteca dinámica como la
estática sean creadas y funcionen. OpenServer 6.0.0 también
necesita parches para el árbol de código fuente MySQL y el
parche para config.guess
aplicado sobre
bdb/dist/config.guess
. Los parches pueden
descargarse de
ftp://ftp.zenez.com/pub/zenez/prgms/mysql-4.1.12-osr6-patches.tar.gz
y de
ftp://ftp.zenez.com/pub/zenez/prgms/mysql-4.x.x-osr6-patches.
Hay un fichero README
para obtener ayuda.
Los parches del sistema operativo OpenServer 6 son proporcionados por SCO en ftp://ftp.sco.com/pub/openserver6.
SCO proporciona información sobre soluciones a problemas de seguridad en ftp://ftp.sco.com/pub/security/OpenServer.
En forma predeterminada, el máximo tamaño de fichero en un sistema OpenServer 6.0.0 es de 1TB. Algunas utilidades del Sistema Operativo tienen una limitación de 2GB. El máximo tamaño posible para ficheros de UnixWare 7 es 1TB con VXFS o HTFS.
En forma predeterminada, las entradas en
/etc/conf/cf.d/mtune
están establecidas
en:
Value Default Min Max ----- ------- --- --- SVMMLIM 0x9000000 0x1000000 0x7FFFFFFF HVMMLIM 0x9000000 0x1000000 0x7FFFFFFF SSTKLIM 0x1000000 0x2000 0x7FFFFFFF HSTKLIM 0x1000000 0x2000 0x7FFFFFFF
Se recomienda configurar estos valores en la siguiente forma:
SDATLIM 0x7FFFFFFF HDATLIM 0x7FFFFFFF SSTKLIM 0x7FFFFFFF HSTKLIM 0x7FFFFFFF SVMMLIM 0x7FFFFFFF HVMMLIM 0x7FFFFFFF SFNOLIM 2048 HFNOLIM 2048
Se recomienda ajustar el sistema, pero los valores de los
parámetros a emplear dependen del número de usuarios que
accederán a la aplicación o la base de datos y el tamaño de
la base de datos (es decir, el uso que se hará del buffer
pool -un caché de tablas y páginas-). Lo que sigue modifica
los parámetros del kernel definidos en
/etc/conf/cf.d/stune
:
SHMMAX
(Valor recomendado: 128MB) y
SHMSEG
(Valor recomendado: 15). Estos
parámetros influyen en la forma en que el motor de bases de
datos crea los buffer pools.
SFNOLIM
y HFNOLIM
deberían tener un valor máximo de 2048.
NPROC
debería ser por lo menos 3000/4000
(dependiendo de la cantidad de usuarioa).
También se recomienda emplear la siguiente fórmula para
calcular los valores de SEMMSL
,
SEMMNS
, y SEMMNU
:
SEMMSL = 13
13 es el valor que se halló como el mejor para Progress y MySQL.
SEMMNS
= SEMMSL
*
cantidad de servidores de bases de datos a ejecutar en el
sistema.
Establecer SEMMNS
al valor de
SEMMSL
multiplicado por el número máximo
de servidores que se ejecutarán en el sistema al mismo
tiempo.
SEMMNU
= SEMMNS
Establecer el valor de SEMMNU
al mismo
valor que tiene SEMMNS
. Posiblemente se
pueda establecer a un 75% del valor de
SEMMNS
, pero esta es una estimación
conservadora.
MySQL emplea varios ficheros abiertos. Debido a esto, se
debería agregar al fichero CONFIG.SYS
algo
como lo siguiente:
SET EMXOPT=-c -n -h1024
Si no se hace así, se pueden producir los siguientes errores:
File 'xxxx
' not found (Errcode: 24)
Al emplear MySQL en OS/2 Warp 3, se requiere el FixPack 29 o posterior. Con OS/2 Warp 4, se necesita el FixPack 4 o posterior. Este es un requisito de la biblioteca Pthreads. MySQL Debe ser instalado en una partición con un tipo que soporte nombres de fichero largos, tal como HPFS, FAT32, y otros.
El script INSTALL.CMD
debe ejecutarse desde
la línea de comandos de OS/2, CMD.EXE
, y
podría no funcionar con shells de remplazo como
4OS2.EXE
.
El script scripts/mysql-install-db
ha
cambiado su nombre. Se llama install.cmd
y
es un script REXX, el cual establece la configuración de
seguridad por defecto de MySQL y crea en el Workplace Shell
[nombre que recibe el sistema de ventanas de OS/2] los íconos
de MySQL.
El soporte para módulo dinámico se compila pero no está completamente testeado. Los módulos dinámicos se deben compilar empleando la biblioteca de tiempo de ejecución de Pthreads.
gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \ -o example udf_example.cc -L../lib -lmysqlclient udf_example.def mv example.dll example.udf
Nota: debido a limitaciones en
OS/2, el nombre (sin incluir extensión) de un módulo UDF no
debe exceder de 8 caracteres. Los módulos se almacenan en el
directorio /mysql2/udf
; el script
safe-mysqld.cmd
coloca este directorio en la
variable de entorno BEGINLIBPATH
. Al utilizar
módulos UDF, se ignora cualquier extensión que se especifique.
Se asume .udf
. Por ejemplo, en Unix, el
módulo compartido podría llamarse
example.so
y la carga de una función
contenida en él se haría así:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME 'example.so';
En OS/2, el modulo se llamaría
example.udf
, pero la extensión no se
especifica:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME 'example';
En Perl, el soporte para MySQL está proporcionado a través de la
interfaz cliente DBI
/DBD
. La
interfaz requiere Perl Versión 5.6.0 o posterior. La misma
no funciona en una versión anterior de Perl.
Para poder utilizar transacciones con Perl DBI, se necesita tener
DBD::mysql
versión 1.2216 o posterior. Se
recomienda la versión 2.9003 o posterior.
Si se está utilizando la biblioteca cliente de MySQL 4.1, se
deberá emplear DBD::mysql
2.9003 o posterior.
El soporte en Perl no se incluye con las distribuciones MySQL. Los módulos necesarios pueden descargarse de http://search.cpan.org para Unix, o utilizando el programa ActiveState ppm en Windows. Las siguientes secciones describen cómo hacerlo.
Se debe isntalar el soporte en Perl para MySQL si se desean ejecutar los scripts de de pruebas de rendimiento de MySQL. Consulte Sección 7.1.4, “El paquete de pruebas de rendimiento (benchmarks) de MySQL”.
El soporte MySQL en Perl requiere que se hayan instalado el soporte de programación de cliente MySQL (bibliotecas y ficheros de cabecera). La mayoría de los métodos de instalación crean los ficheros necesarios. Sin embargo, si se instaló MySQL en Linux a partir de ficheros RPM, hay que asegurarse de haber instalado el RPM de desarrollo. Los programas cliente están en el RPM de cliente, pero el soporte a la programación se encuentra en el RPM de desarrollo.
Si se desea instalar el soporte en Perl, los ficheros que se necesitarán pueden obtenerse desde la CPAN (Comprehensive Perl Archive Network, Red Integral de Archivo Perl) en http://search.cpan.org.
La forma más sencilla de instalar módulos Perl en Unix es
utilizar el módulo CPAN
. Por ejemplo:
shell> perl -MCPAN -e shell cpan> install DBI cpan> install DBD::mysql
La instalación de DBD::mysql
ejecuta una
cantidad de pruebas. Estas pruebas intentan conectarse al
servidor MySQL local, empleando el nombre de usuario y
contraseña por defecto. (El nombre de usuario por defecto es el
nombre usado para iniciar sesión en Unix, y en Windows es
ODBC
. La contraseña por defecto es
“sin contraseña.”). Si no se puede conectar al
servidor con estos valores (por ejemplo si la cuenta tiene una
contraseña establecida), la prueba falla. Se puede emplear
force install DBD::mysql
para ignorar las
pruebas fallidas.
DBI
requiere el módulo
Data::Dumper
. Es posible que esté instalado,
de lo contrario, se debería instalar antes que
DBI
.
Otra posibilidad es descargar las distribuciones de módulos en forma de ficheros tar comprimidos y compilar los módulos manualmente. Por ejemplo, para descompactar y compilar una distribución DBI, debe usarse un procedimiento como el siguiente:
Descompactar la distribución en el directorio actual:
shell> gunzip < DBI-VERSION
.tar.gz | tar xvf -
Este comando crea un directorio llamado
DBI-
.
VERSION
Hay que posicionarse en el directorio de más alto nivel de la distribución descompactada:
shell> cd DBI-VERSION
Compilar la distribución:
shell> perl Makefile.PL shell> make shell> make test shell> make install
El comando make test es importante porque
verifica que el módulo esté funcionando. Nótese que, al
ejecutar este comando durante la instalación de
DBD::mysql
para ejercitar el código de la
interfaz, el servidor MySQL debe estar funcionando o de lo
contrario la prueba fallará.
Es buena idea recompilar y reinstalar la distribución de
DBD::mysql
cada vez que se instale un nuevo
release de MySQL, en particular si se advierte que todos los
scripts DBI
fallan luego de actualizar el
servidor.
Si no se tienen privilegios para instalar los módulos Perl en el directorio del sistema, o si se desean instalar los módulos en forma local, la siguiente referencia puede ser útil: http://servers.digitaldaze.com/extensions/perl/modules.html#modules
Ver bajo el título “Installing New Modules that Require Locally Installed Modules.”
En Windows, se debe hacer lo siguiente para instalar el módulo
DBD
con ActiveState Perl:
Debe obtenerse ActiveState Perl en http://www.activestate.com/Products/ActivePerl/ e instalarlo.
Abrir una ventana de consola (“ventana DOS”).
Si se necesita, establecer el valor de la variable
HTTP_proxy
. Por ejemplo:
set HTTP_proxy=my.proxy.com:3128
Iniciar el programa PPM:
C:\> C:\perl\bin\ppm.pl
Si no se hizo antes, instalar DBI
:
ppm> install DBI
Si todo ha ido bien, ejecutar el siguiente comando:
install \ ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd
Este procedimiento debería funcionar con ActiveState Perl Versión 5.6 o posterior.
Si no se puede hacer funcionar el procedimiento, se debería en su lugar instalar el driver MyODBC y conectarse al servidos MySQL a través de ODBC:
use DBI; $dbh= DBI->connect("DBI:ODBC:$dsn",$user,$password) || die "Got error $DBI::errstr when connecting to $dsn\n";
Si Perl anuncia que no puede encontrar el módulo
../mysql/mysql.so
, entonces el problema
probablemente sea que Perl no ha podido encontrar la biblioteca
compartida libmysqlclient.so
.
Esto debería poder solucionarse a través de alguno de los siguientes métodos:
Compilar la distribución DBD::mysql
con
perl Makefile.PL -static -config
en lugar
de perl Makefile.PL
.
Copiar libmysqlclient.so
al directorio
donde se ubican las demás bibliotecas compartidas
(probablemente, /usr/lib
or
/lib
).
Modificar las opciones -L
utilizadas para
compilar DBD::mysql
para que reflejen la
ubicación real de libmysqlclient.so
.
En Linux, puede agregarse al fichero
/etc/ld.so.conf
la ruta donde se
localiza libmysqlclient.so
.
Agregar a la variable de entorno
LD_RUN_PATH
el directorio donde se ubica
libmysqlclient.so
. Algunos sistemas
utilizan LD_LIBRARY_PATH
en lugar de
LD_RUN_PATH
.
Hay que notar que si hay otras bibliotecas que el enlazador no
puede hallar, se necesitarán modificar las opciones
-L
. Por ejemplo, si no se puede hallar
libc
porque está en el directorio
/lib
y el enlazador está especificando
-L/usr/lib
, hay que cambiar la opción
-L
para que sea -L/lib
o
agregar -L/lib
al comando de enlazado
existente.
Si se obtienen los siguientes errores de
DBD::mysql
, probablemente se está utilizando
gcc (o un binario antiguo compilado con
gcc):
/usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3'
Agregar -L/usr/lib/gcc-lib/... -lgcc
al
comando de enlazado cuando se compila
mysql.so
(verificar la salida de
make para mysql.so
al
compilar el cliente Perl). La opción -L
debería especificar la ruta donde se localiza
libgcc.a
.
Otra causa de este problema es que Perl y MySQL no estén compilados (ambos) con gcc. En este caso, se puede resolver la desigualdad compilando a los dos con gcc.
Al ejecutar las pruebas, puede verse el siguiente error de
DBD::mysql
:.
t/00base............install_driver(mysql) failed: Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: ../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol: uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
Esto significa que se necesita incluir la biblioteca de
compresión -lz
en la línea de enlazado.
Puede hacerse cambiando la siguiente linea en el fichero
lib/DBD/mysql/Install.pm
.
Copiar libmysqlclient.so
al directorio
donde se ubican las otras bibliotecas compartidas
(probablemente, /usr/lib
or
/lib
).
Modificar las opciones -L
usadas para
compilar DBD::mysql
para que reflejen la
ubicación real de libmysqlclient.so
.
En Linux, puede agregarse al fichero
/etc/ld.so.conf
la ruta donde se localiza
libmysqlclient.so
.
Agregar a la variable de entorno LD_RUN_PATH
el directorio donde se ubica
libmysqlclient.so
. Algunos sistemas
utilizan LD_LIBRARY_PATH
en lugar de
LD_RUN_PATH
.
Hay que notar que si hay otras bibliotecas que el enlazador no
puede hallar, se necesitarán modificar las opciones
-L
. Por ejemplo, si no se puede hallar
libc
:
$sysliblist .= " -lm";
Cambiar la línea a:
$sysliblist .= " -lm -lz";
Despues de esto, debe ejecutarse make realclean y proceder con la instalación desde el principio.
Si se desea isntalar DBI en SCO, se tendrá que editar el
fichero Makefile
en
DBI-xxx
y en cada subdirectorio.
Notar que lo que sigue asume que se tiene gcc
2.95.2 o posterior:
OLD: NEW: CC = cc CC = gcc CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic CCDLFLAGS = -wl,-Bexport CCDLFLAGS = LD = ld LD = gcc -G -fpic LDDLFLAGS = -G -L/usr/local/lib LDDLFLAGS = -L/usr/local/lib LDFLAGS = -belf -L/usr/local/lib LDFLAGS = -L/usr/local/lib LD = ld LD = gcc -G -fpic OPTIMISE = -Od OPTIMISE = -O1 OLD: CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include NEW: CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include
Estos cambios se necesitan porque el cargador dinámico
(dynaloader) de Perl no cargará los módulos
DBI
si fueron compilados con
icc o cc.
Si se desea utilizar el módulo Perl en un sistema que no posee
soporte para enlazado dinámico (como SCO), se deberá generar
una versión estática de Perl que incluya
DBI
y DBD::mysql
. La forma
en que esto funciona es: se genera una versión de Perl con el
código DBI
enlazado y se la instala por
encima del Perl actual. Luego se lo utiliza para compilar una
versión de Perl que adicionalmente tiene incluído el código
de DBD
, y se lo instala.
En SCO, se deberán configurar las siguientes variables de entorno:
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
O bien:
LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\ /usr/progressive/lib:/usr/skunk/lib LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\ /usr/progressive/lib:/usr/skunk/lib MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:\ /usr/skunk/man:
En primer lugar hay que crear un Perl que incluya un módulo
DBI
enlazado estáticamente mediante la
ejecución de estos comandos en el directorio donde se ubica la
distribución de DBI
:
shell>perl Makefile.PL -static -config
shell>make
shell>make install
shell>make perl
Luego debe instalarse el nuevo Perl. La salida de make perl indica exactamente el comando make necesario para llevar a cabo la instalación. En SCO, este es make -f Makefile.aperl inst_perl MAP_TARGET=perl.
A continuación, emplear el recién creado Perl para crear otro
Perl que tmabién incluya un DBD::mysql
creado estáticamente, mediante la ejecución de estos comandos
en el directorio donde se ubica la distribución
DBD::mysql
:
shell>perl Makefile.PL -static -config
shell>make
shell>make install
shell>make perl
Finalmente, se debería instalar este nuevo Perl. De nuevo, la salida de make perl indicará el comando a emplear.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.