Instalaciion de mysql para windows

143 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
143
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Instalaciion de mysql para windows

  1. 1. 2.1. Cuestiones generales sobre la instalación 2.1.1. Sistemas operativos que MySQL soporta 2.1.2. Escoger la distribución MySQL a instalar 2.1.3. Cómo obtener MySQL 2.1.4. Comprobar la integridad de paquetes con sumas de verificación MD5 o GnuPG 2.1.5. Conformación de la instalación Antes de instalar MySQL, se debería hacer lo siguiente: 1. Determinarse si la plataforma donde se desea hacer la instalación está soportada. 2. Elegirse la distribución que se instalará. 3. Descargar la distribución que se desea instalar y verificar su integridad. Esta sección contiene la información necesaria para llevar adelante estos pasos. Una vez ejecutados, se puede seguir las instrucciones de secciones posteriores del capítulo, para instalar la distribución elegida. 2.1.1. Sistemas operativos que MySQL soporta En esta sección aparecen listados los sistemas operativos en los que es posible instalar MySQL. Se ha utilizado GNU Autoconfig, de modo que es posible portar MySQL a todos los sistemas modernos que tengan un compilador de C++ y una implementación funcional de subprocesos (threads) POSIX. (El soporte de subprocesos es necesario para el servidor. Para compilar únicamente el código del cliente, no se requiere más que el compilador de C++). Nosotros mismos desarrollamos y utilizamos el software ante todo en Linux (SuSE y Red Hat), FreeBSD, y Sun Solaris (Versiones 8 y 9), MySQL ha sido compilado correctamente en las siguientes combinaciones de sistemas operativos y paquetes de subprocesos. Nótese que, para varios sistemas operativos, el soporte nativo de subprocesos funciona solamente en las versiones más recientes. AIX 4.x, 5.x con subprocesos nativos. Consulte Sección 2.12.5.3, “Notas sobre IBM-AIX”. Amiga. BSDI 2.x with con el paquete MIT-pthreads. Consulte Sección 2.12.4.5, “Notas sobre BSD/OS Version 2.x”. BSDI 3.0, 3.1 y 4.x con subprocesos nativos. Consulte Sección 2.12.4.5, “Notas sobre BSD/OS Version 2.x”. Digital Unix 4.x con subprocesos nativos. Consulte Sección 2.12.5.5, “Notas AlphaDEC-UNIX (Tru64)”. FreeBSD 2.x con el paquete MIT-pthreads. Consulte Sección 2.12.4.1, “Notas sobre FreeBSD”.
  2. 2. FreeBSD 3.x and 4.x con subprocesos nativos. Consulte Sección 2.12.4.1, “Notas sobre FreeBSD”. FreeBSD 4.x con LinuxThreads. Consulte Sección 2.12.4.1, “Notas sobre FreeBSD”. HP-UX 10.20 con el paquete DCE threads o MIT-pthreads. Consulte Sección 2.12.5.1, “Notas sobre HP-UX Version 10.20”. HP-UX 11.x con subprocesos nativos. Consulte Sección 2.12.5.2, “Notas sobre HPUX Version 11.x”. Linux 2.0+ con LinuxThreads 0.7.1+ o glibc 2.0.7+ para varias arquitecturas de CPU. Consulte Sección 2.12.1, “Notas sobre Linux”. Mac OS X. Consulte Sección 2.12.2, “Notas sobre Mac OS X”. NetBSD 1.3/1.4 Intel y NetBSD 1.3 Alpha (requiere GNU make). Consulte Sección 2.12.4.2, “Notas sobre NetBSD”. Novell NetWare 6.0. Consulte Sección 2.6, “Instalar MySQL sobre NetWare”. OpenBSD> 2.5 con subprocesos nativos. OpenBSD< 2.5 con el paquete MITpthreads. Consulte Sección 2.12.4.3, “Notas sobre OpenBSD 2.5”. OS/2 Warp 3, FixPack 29 y OS/2 Warp 4, FixPack 4. Consulte Sección 2.12.6, “Notas sobre OS/2”. SCO OpenServer 5.0.X con una versión del paquete FSU Pthreads recientemente portada. Consulte Sección 2.12.5.8, “Notas sobre SCO UNIX y OpenServer 5.0.x”. SCO UnixWare 7.1.x. Consulte Sección 2.12.5.9, “Notas sobre SCO UnixWare 7.1.x y OpenUNIX 8.0.0”. SCO Openserver 6.0.x. Consulte Sección 2.12.5.10, “Notas sobre SCO OpenServer 6.0.x”. SGI Irix 6.x con subprocesos nativos. Consulte Sección 2.12.5.7, “Notas sobre SGI Irix”. Solaris 2.5 y posteriores con subprocesos nativos en SPARC y x86. Consulte Sección 2.12.3, “Notas sobre Solaris”. SunOS 4.x con el paquete MIT-pthreadspackage. Consulte Sección 2.12.3, “Notas sobre Solaris”. Tru64 Unix. Consulte Sección 2.12.5.5, “Notas Alpha-DEC-UNIX (Tru64)”. Windows 9x, Me, NT, 2000, XP, y 2003. Consulte Sección 2.3, “Instalar MySQL en Windows”. No todas las plataformas son igualmente aptas para ejecutar MySQL. Los siguientes factores determinan si una plataforma está más o menos bien preparada para un servidor MySQL con alto volumen de carga y para misiones crítica: Estabilidad general de la biblioteca de subprocesos. Una plataforma puede tener una excelente reputación en otras situaciones, pero MySQL es estable como lo sea la biblioteca de subprocesos que utiliza la plataforma, aun cuando cualquier otro aspecto sea perfecto. La capacidad del núcleo o kernel del sistema operativo y de la biblioteca de subprocesos para aprovechar sistemas de multiprocesamiento simétrico (SMP). En otras palabras, cuando un proceso crea un subproceso, éste debería poderse ejecutar en una CPU diferente a la del proceso original.
  3. 3. La capacidad del núcleo o kernel del sistema operativo y de la biblioteca de subprocesos para ejecutar varios subprocesos que bloquean y liberan mutexes frecuentemente en una pequeña región crítica sin excesivos cambios de contexto. Si la implementación de pthread_mutex_lock() es muy proclive a consumir tiempo de CPU, esto afectará en gran manera a MySQL. Si no se previene este problema, añadir más CPUs hará todavía más lento a MySQL. El rendimiento y la estabilidad general del sistema de ficheros. Si se emplean grandes tablas, la capacidad del sistema de ficheros para gestionar eficientemente archivos de gran tamaño. El nivel de experiencia que los desarrolladores de MySQL AB posean sobre una determinada plataforma. Si la conocen bien, habilitan optimizaciones específicas y soluciones en tiempo de compilación. Además pueden proporcionar consejos sobre cómo configurar el sistema en forma óptima para MySQL. El volumen de pruebas realizadas por MySQL AB sobre configuraciones similares. La cantidad de usuarios que han ejecutado MySQL con éxito en la misma plataforma y en configuraciones similares. Si este número es alto, las probabilidades de encontrar sorpresas específicas de la plataforma son mucho menores. En base a estos criterios, las mejores plataformas para ejecutar MySQL en este momento son x86 con SuSE Linux (kernel versión 2.4 o 2.6), y ReiserFS (o cualquier distribución de Linux similar) y SPARC con Solaris (2.7-9). FreeBSD aparece en tercer lugar, pero es de esperar que se integre al lote principal cuando se mejore la biblioteca de subprocesos. También las otras plataformas donde MySQL se compila y ejecuta en la actualidad podrian ser incluidas en la categoria principal, pero no con el mismo nivel de estabilidad y rendimiento. Esto requiere un esfuerzo por parte de los desarrolladores de MySQL en cooperación con los desarrolladores de los sistemas operativos y de bibliotecas de componentes de las que depende MySQL. Si Usted está interesado en mejorar alguno de estos componentes, está en posición de influir en su desarrollo, y necesita información más detallada acerca de lo que MySQL requiere para funcionar mejor, envíe un mensaje de correo electrónico a la lista de correo internals de MySQL. Consulte Sección 1.6.1.1, “Las listas de correo de MySQL”. El propósito de la anterior comparación no es afirmar que un sistema es, en términos generales, mejor o peor que otro. Se trata solamente de la elección de un sistema operativo con el objetivo de ejecutar MySQL. Por lo tanto, el resultado de la comparación podría ser diferente si se consideraran otros factores. En algunos casos, la razón de que un sistema operativo sea mejor que otros podría residir simplemente en que los desarrolladores de MySQL han podido dedicar más esfuerzos a la prueba y optimización sobre una plataforma en particular. Lo aquí manifestado son las observaciones de estos desarrolladores a fin de ayudar al usuario a decidir la plataforma sobre la que ejecutar MySQL. 2.1.2. Escoger la distribución MySQL a instalar 2.1.2.1. Escoger la versión de MySQL a instalar 2.1.2.2. Escoger un formato de distribución 2.1.2.3. Cómo y cuándo se entregan las actualizaciones
  4. 4. 2.1.2.4. Filosofía de las entregas—No hay bugs conocidos en las entregas 2.1.2.5. Binarios de MySQL compilados por MySQL AB Como parte de los preparativos para instalar MySQL, debe decidirse qué versión se utilizará. El desarrollo de MySQL se divide en entregas (releases) sucesivas, y el usuario puede decidir cuál es la que mejor satisface sus necesidades. Después de haber elegido la versión a instalar, se debe optar por un formato de distribución. Las entregas están disponibles en formato binario o código fuente. 2.1.2.1. Escoger la versión de MySQL a instalar La primera decisión a tomar es si se desea emplear una entrega "en producción" (estable) o una entrega de desarrollo. En el proceso de desarrollo de MySQL coexisten múltiples entregas, cada una con un diferente estado de madurez: MySQL 5.1 es la próxima serie de entregas de desarrollo, y en ella se implementarán las nuevas características. En breve se pondrán a disposición de los usuarios interesados en hacer pruebas integrales las entregas Alfa. MySQL 5.0 es la serie de entregas estables (para producción). Solamente se liberan nuevas entregas para corrección de errores, no se añaden nuevas características que pudieran afectar a la estabilidad. MySQL 4.1 es la anterior serie de entregas estables (para producción). Se liberarán nuevas entregas para solucionar problemas de seguridad o errores críticos. En esta serie no se agregarán nuevas caracteristicas de importancia. MySQL 4.0 y 3.23 son las antiguas series de entregas estables (para producción). Estas versiones están discontinuadas, de modo que solamente se liberarán nuevas entregas para solucionar errores de seguridad extremadamente críticos. Los desarrolladores de MySQL no son partidarios de la "congelación" total del código de una versión, puesto que anula la posibilidad de introducir soluciones a errores. Cuando se habla de algo “congelado” se quiere expresar que no se harán más que pequeñas modificaciones que no deberían afectar a la forma en que funciona actualmente una entrega en un entorno de producción. Naturalmente, los errores que se corrigen en una serie se propagan a las siguientes si son relevantes. Si el usuario está comenzando a emplear MySQL por primera vez o intentando su implementación en un sistema para el que no hay una distribución binaria, es recomendable instalar una entrega perteneciente a una serie en producción. Actualmente, MySQL 5.0. Todas las entregas de MySQL, aun aquellas pertenecientes a una serie en desarrollo, se verifican con las pruebas de rendimiento de MySQL y se prueban extensamente antes de liberarse. Si se está ejecutando una versión más antigua y se desea actualizar, pero se quiere evitar un cambio brusco con el consiguiente riesgo de incompatibilidades, debería actualizarse a la última versión dentro de la misma serie de entregas que se utiliza actualmente (es decir, aquélla donde únicamente la última parte del número de versión es más nueva que la
  5. 5. actual). En dicha versión los desarrolladores de MySQL han tratado de corregir solamente errores fatales y realizar cambios pequeños, relativamente “seguros”. Si se desea emplear características nuevas que no están en las entregas para ambientes de producción, habrá que utilizar una versión perteneciente a una serie de entregas en desarrollo. Hay que tener en cuenta que las entregas de desarrollo no son tan estables como las que están en producción. Si lo que se desea es emplear el código fuente más actualizado disponible, que contenga todas las correcciones y esté libre de bugs, se debería emplear uno de los repositorios BitKeeper, que no son “entregas” propiamente dichas, pero es el código en el que se basarán las entregas futuras. El esquema de denominaciones de MySQL emplea para las entregas nombres consistentes en tres números y un sufijo; por ejemplo, mysql-5.0.9-beta. Los números dentro del nombre de la entrega se interpretan como sigue: El primer número (5) es la versión principal y describe el formato de fichero. Todas las entregas de la versión 5 comparten el mismo formato para sus ficheros. El segundo número (0) es el nivel de entrega. En conjunto, la versión principal y el nivel de entrega constituyen el número de la serie. El tercer número (9) es el número de versión dentro de la serie. Se incrementa para cada nueva entrega. Usualmente es deseable poseer la última versión dentro de la serie que se está usando. Para los cambios menores, el que se incrementa es el último número en la denominación de la versión. Cuando se adicionan características de importancia o aparecen incompatibilidades menores con versiones precedentes, se incrementa el segundo número. Cuando cambia el formato de los ficheros, se incrementa el primer número. Las denominaciones de las entregas también incluyen un sufijo para indicar el grado de estabilidad. Una entrega progresa a través de un conjunto de sufijos a medida que mejora su estabilidad. Los posibles sufijos son: alpha indica que la entrega contiene características nuevas que no han sido plenamente probadas. Asimismo, en la sección "Novedades" deberían estar documentados los errores conocidos, aunque usualmente no los hay. Consulte Apéndice C, Historial de cambios de MySQL. Por lo general, en cada entrega alpha se implementan nuevos comandos y extensiones, y es la etapa donde puede producirse la mayor cantidad de cambios en el código. Sin embargo, debido a las pruebas realizadas, no deberían existir errores conocidos. beta significa que la entrega está destinada a poseer sus características completas y que se probó todo el código nuevo. No se agregan características de importancia, y no deberían existir errores críticos. Una versión cambia de alpha a beta cuando no se han descubierto errores fatales durante al menos un mes, y no hay planes de agregar características que pudieran comprometer la fiabilidad del código existente.
  6. 6. Todas las APIs, las estructuras visibles externamente y las columnas para comandos SQL no se modificarán en las futuras entregas, sean beta, candidatas, o de producción. rc es una entrega candidata; o sea, una beta que ha estado funcionando un intervalo de tiempo y parece hacerlo bien. Solamente podrían ser necesarias correcciones menores. (Una entrega candidata es formalmente conocida como una entrega gamma.) Si no hay un sufijo, significa que la versión se ha estado utilizando por un tiempo en diferentes sitios sin que se informaran errores críticos reproducibles, más allá de los específicos de una plataforma. Esto es lo que se llama una entrega de producción (estable) o “General Availability” (GA). MySQL utiliza un esquema de denominaciones ligeramente diferente a muchos otros productos. En general, se considera segura para usar una versión que ha durado un par de semanas sin ser reemplazada por una nueva dentro de la misma serie de entregas. La totalidad de las entregas de MySQL se someten a pruebas de fiabilidad y rendimiento (estándares dentro de MySQL) para cerciorarse de que son relativamente seguras de utilizar. Puesto que las pruebas estándar son ampliadas cada vez para que incluyan todos los errores anteriormente descubiertos, el conjunto de pruebas se mejora continuamente. Cada entrega se prueba al menos con: Un conjunto interno de pruebas El directorio mysql-test contiene un amplio conjunto de casos de prueba. En MySQL, prácticamente cada versión binaria del servidor pasa por estas pruebas. Consulte Sección 27.1.2, “El paquete de pruebas MySQL Test” para más información sobre este conjunto de pruebas. El conjunto de pruebas de rendimiento de MySQL Este conjunto ejecuta una serie de consultas comunes. Es también una manera de verificar que las últimas optimizaciones realizadas hacen efectivamente más rápido el código. Consulte Sección 7.1.4, “El paquete de pruebas de rendimiento (benchmarks) de MySQL”. La prueba crash-me Esta prueba intenta determinar las características soportadas por la base de datos y cuáles son sus capacidades y limitaciones. Consulte Sección 7.1.4, “El paquete de pruebas de rendimiento (benchmarks) de MySQL”.
  7. 7. Otra prueba consiste en utilizar la versión más reciente del servidor en el entorno de producción de MySQL, en al menos un ordenador. Se dispone de más de 100GB de datos para este fin. 2.1.2.2. Escoger un formato de distribución Después de haber decidido qué versión de MySQL instalar, se debe elegir entre una distribución binaria o una de código fuente. Probablemente la elección más frecuente sea la distribución binaria, si existe una para la plataforma en cuestión. Hay distribuciones binarias disponibles en formato nativo para muchas plataformas, como los ficheros RPM para Linux, paquetes de instalación DMG para Mac OS X, y ficheros comprimidos Zip y tar. Algunas razones a favor de la elección de una distribución binaria: Es más fácil de instalar que una distribución de código fuente. Para satisfacer distintos requerimientos de usuarios, se facilita dos versiones binarias diferentes: una que contiene motores de almacenamiento no transaccionales (más pequeña y rápida) y una configurada con las más importantes opciones, como por ejemplo tablas transaccionales. Ambas versiones se compilan a partir de la misma distribución de código fuente. Todos los clientes MySQL nativos pueden conectarse a ambas versiones indistintamente. La versión binaria extendida de MySQL está señalada con el sufijo -max y está configurada con las mismas opciones que mysqld-max. Consulte Sección 5.1.2, “El servidor extendido de MySQLmysqld-max”. Si se desea utilizar MySQL-Max en formato RPM, primero debe instalarse el RPM de MySQL-server estándar. Bajo ciertas circunstancias, puede ser mejor instalar MySQL a partir de una distribución de código fuente: Cuando se desea instalar MySQL en una ubicación especial. Las distribuciones binarias estándar están listas para ejecutarse en cualquier sitio, pero podria ser necesaria aún más flexibilidad en la elección de la ubicación de los componentes. Cuando se desea configurar mysqld con algunas características adicionales que no se encuentran incluídas en las distribuciones binarias estándar. La siguiente es una lista de las opciones adicionales más comunes: o --with-innodb (habilitado por defecto en todas las entregas binarias de la serie 5.0 de MySQL) o --with-berkeley-db (no está disponible en todas las plataformas) o o o --with-libwrap --with-named-z-libs --with-debug[=full] (en algunas distribuciones binarias ya está incluido) Cuando se desea excluir de mysqld algunas características presentes en las distribuciones binarias estándar. Por ejemplo, estas distribuciones se compilan
  8. 8. normalmente con soporte para todos los conjuntos de caracteres. Si se deseara un servidor MySQL más liviano, se lo puede recompilar con soporte solamente para el conjunto de caracteres que se necesita. Cuando se posee un compilador especial (como pgcc) o se desea utilizar opciones de compilación optimizadas para un determinado procesador. Las distribuciones binarias se compilan con opciones que deberían funcionar en diversos procesadores de la misma familia. Cuando se desea emplear la última versión de código fuente desde un repositorio BitKeeper, para acceder a modificaciones recientes. Por ejemplo, si se detecta un error y se comunica al equipo de desarrollo de MySQL, la corrección se realiza sobre el código fuente, que queda almacenado en el repositorio. La primera entrega con esta corrección será la siguiente. Cuando se desea leer (o modificar) el código en C y C++ que conforma MySQL. Para este fin, se debería poseer una distribución de código fuente, ya que es la documentación más actualizada. Las distribuciones de código fuente contienen más pruebas y ejemplos que las distribuciones binarias. 2.1.2.3. Cómo y cuándo se entregan las actualizaciones MySQL evoluciona con rapidez, y sus desarrolladores desean compartir el desarrollo con los usuarios. Se intenta producir una entrega cada vez que se incorpora nuevas características que pueden ser útiles para otros. También se escucha a los usuarios que solicitan características sencillas de implementar. Se toma nota de lo que los usuarios con licencia desean, y especialmente de lo que solicitan los clientes de soporte, intentando actuar al respecto. No es necesario descargar una entrega para conocer sus características, puesto que se puede dilucidar si una entrega posee determinada característica en la sección Novedades. Consulte Apéndice C, Historial de cambios de MySQL. MySQL se rige por la siguiente política de actualizaciones: Las entregas se liberan dentro de cada serie. Para cada entrega, el último número en la versión es uno más que en la entrega anterior dentro de la misma serie. Las entregas de producción (estables) tienden a aparecer 1 o 2 veces por año. Sin embargo, de hallarse pequeños bugs, se libera una entrega con solamente correcciones. Las entregas de corrección para viejas entregas tienden a aparecer cada 4 u 8 semanas. De cada entrega principal Mysql AB realiza distribuciones binarias para algunas plataformas. Otros sujetos pueden realizar distribuciones binarias para otros sistemas, pero probablemente con menos frecuencia. Las correcciones están disponibles tan pronto se identifican errores pequeños o no críticos, pero que igualmente afectan al uso normal de MySQL. Se colocan en el repositorio público BitKeeper, y se incluyen en la entrega siguiente.
  9. 9. Si por cualquier motivo se descubre un error fatal en una entrega, la política de MySQL es corregirlo mediante una nueva entrega, tan pronto como sea posible. (¡Y veríamos con agrado que otras compañías hicieran lo mismo!).

×