2.12. Notas específicas sobre sistemas operativos

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:

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:

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 <[email protected]> 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:

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”.

MySQL debería funcionar sin mayores problemas en Mac OS X 10.x (Darwin).

Los problemas conocidos son:

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

Consulte Sección 2.5, “Instalar MySQL en Mac OS X”.

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.

Consulte Sección 2.5, “Instalar MySQL en Mac OS X”.

• Enlazar clientes con el flag -Wl,r/full/path/to/libmysqlclient.so en lugar de -Lpath).

• Copiar libmysqclient.so al directorio /usr/lib.

• Antes de ejecutar el cliente, agregar a la variable de entorno LD_RUN_PATH la ruta del directorio donde se localiza libmysqlclient.so.

• 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.

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:

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:

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”.

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:

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:

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=xxx para que concuerde con la CPU del usuario. Generalmente puede necesitarse 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.

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

#define HAVE_SNPRINTF 1

#undef HAVE_SNPRINTF

#ifdef _AIX41
extern "C" int initgroups(const char *,int);
#endif

export LDR_CNTRL='MAXDATA=0x80000000'