SlideShare ist ein Scribd-Unternehmen logo
1 von 182
Downloaden Sie, um offline zu lesen
Administración MySQL




Miguel Ángel Nieto <miguelangel@irontec.com>
 Irontec – Internet y Sistemas sobre GNU/Linux
Irontec – Administración de MySQL

                     Instalación




                               2
Irontec – Administración de MySQL

                                                             Instalación

●   La instalación puede realizarse de las siguientes formas:
      –   Código fuente
      –   Binarios
      –   Sistema de paquetes de tu distribución
●   Cada uno tiene sus ventajas e inconvenientes
      –   Código fuente es laborioso, pero te permite definir
            mejor las carácterísticas de tu servidor, activando y
            desactivando a tu gusto
      –   Los binarios vienen compilados y son más fáciles de
            actualizar. Si están compilados con icc se puede casi
            doblar el rendimiento
      –   Sistema de paquetes, facil de instalar y de actualizar


                                                                       3
Irontec – Administración de MySQL

                                                          Instalación

           http://downloads.mysql.com/archives.php
●   Para compilar en debian es necesario como mínimo:
      –   apt­get install build­essential libncurses5­dev
●   Como siempre ./configure && make && make install
      –   ./configure –help
      –   ./configure –prefix=/usr/local/mysql
      –   ./configure –without­plugin­innodb
●   Tenemos que crear los usuarios:
      –   # groupadd mysql
      –   # useradd ­g mysql mysql
●   Creamos las bases de datos necesarias para funcionar
      –   # cd scripts
      –   # ./mysql_install_db


                                                                    4
Irontec – Administración de MySQL

                                                        Instalación

●   Damos permisos a la carpeta:
      –   # chown ­R root /usr/local/mysql
      –   # chown ­R mysql /usr/local/mysql/var
      –   # chgrp ­R mysql /usr/local/mysq
●   Copiamos el fichero de configuración y lo editamos en
    caso de que sea necesario:
      –   # cp support­files/my­medium.cnf /etc/my.cnf
●   Arrancamos MySQL :)
      –   # /usr/local/mysql/bin/mysqld_safe –user=mysql




                                                                  5
Irontec – Administración de MySQL

                                                      Instalación

●   Los binarios podemos descargarlos de:
    http://dev.mysql.com/downloads/mysql/

    # groupadd mysql
    # useradd ­g mysql mysql
    # cd /usr/local
    # tar ­xzf mysql­VERSION­OS.tar.gz
    # cd mysql
    # chown ­R mysql .
    # chgrp ­R mysql .
    # scripts/mysql_install_db ­­user=mysql
    # chown ­R root .
    # chown ­R mysql data
    # bin/mysqld_safe ­­user=mysql &



                                                                6
Irontec – Administración de MySQL

                                                        Instalación

●   En Debian podemos hacer la instalación con apt-get :)

●   ¡En cualquiera de los tres modos de instalación es
    necesario dar una contraseña a root!




                                                                  7
Irontec – Administración de MySQL

                                                                 SandBox

●   Para crear una laboratorio de pruebas podemos:
      –   Montar equipos físicos e instalarlos (de locos).
      –   Montar máquinas virtuales.
      –   Usar ¡sandbox!




                                                                         8
Irontec – Administración de MySQL

                                                              SandBox

●   SandBox nos permite:
      –   Montar sistemas de replicación
      –   Probar versiones nuevas de MySQL facilmente
      –   Manejar múltiples instancias de MySQL desde un único
            punto.
      –   Te olvidas de rmps, sources, debs... ¡tar.gz binario!
      –   Testear
      –   Testear
      –   Testear...




                                                                      9
Irontec – Administración de MySQL

                                                            SandBox

●   No es un producto oficial de MySQL.
●   Está escrito el perl (puag!) y aún así funciona bien.

                 http://mysqlsandbox.net/
●   Tendremos que descargar un paquete tar.gz de MySQL
    y Sandbox.




                                                                    10
Irontec – Administración de MySQL

                                                                Instalación

●   ¡Como root!
root@shyris:~# tar ­xzf MySQL­Sandbox­3.0.05.tar.gz

root@shyris:~# cd MySQL­Sandbox­3.0.05/

root@shyris:~/MySQL­Sandbox­3.0.05# perl Makefile.PL

root@shyris:~/MySQL­Sandbox­3.0.05# make

root@shyris:~/MySQL­Sandbox­3.0.05# make test

root@shyris:~/MySQL­Sandbox­3.0.05# make install

root@shyris:/usr/local/bin# ls
low_level_make_sandbox        make_multiple_sandbox     make_sandbox 
                make_sandbox_from_source  sb      test_sandbox
make_multiple_custom_sandbox  make_replication_sandbox  
make_sandbox_from_installed  msandbox                  sbtool 




                                                                          11
Irontec – Administración de MySQL

                                                 Uso de SandBox

●   Crear un sandbox con una única instancia de MySQL


punisher@shyris:~$ make_sandbox /home/punisher/MySQL/mysql­
5.0.86­percona­highperf­b19.tar.gz 
unpacking /home/punisher/MySQL/mysql­5.0.86­percona­
highperf­b19.tar.gz
Executing low_level_make_sandbox 
­­basedir=/home/punisher/MySQL/5.0.86 
   ­­sandbox_directory=msb_5_0_86 
   ­­install_version=5.0 
   ­­sandbox_port=5086 
   ­­no_ver_after_name 
   ­­my_clause=log­error=msandbox.err




                                                                  12
Irontec – Administración de MySQL

                                        Uso de SandBox

●   Parar sandbox:
      –   stop
●   Arrancar sandbox:
      –   start
●   Utilizar sandbox:
      –   use
●   Reiniciar sandbox:
      –   restart
●   Limpiar el sandbox:
      –   clean



                                                         13
Irontec – Administración de MySQL

                                                           Clientes

●   Existen distintos clientes para conectarse a la BBDD
●   Clientes de consola
       –   Mysql
       –   Mysqldump
       –   Mysqladmin
       –   Mysqlimport
●   Gráficos
       –   Mysql Administrator
       –   Mysql Query Browser
       –   MySQL Workbench
●   etc.


                                                                  14
Irontec – Administración de MySQL

                                                             Clientes

●   Mysql: el típico, nos permite conectarse tanto de
    forma local como remota y ejecutar sentencias SQL
●   Mysqldump: permite hacer backups
●   Mysqladmin: crear/borrar bases de datos, cambiar
    contraseñas, ver el estado, variables, parar slaves, etc.
●   Mysqlimport “frontend” para “LOAD DATA INFILE”

                 Vienen ya incluidos en MySQL




                                                                    15
Irontec – Administración de MySQL

                                                  Clientes

●   MySQL administrator




                                                         16
Irontec – Administración de MySQL

                                                  Clientes

●   MySQL Query Browser




                                                         17
Irontec – Administración de MySQL

                                              Clientes

●   MySQL Workbench




                                                     18
Irontec – Administración de MySQL

   Ficheros de configuración




                               19
Irontec – Administración de MySQL

                                              Ficheros de configuración

●   Algunos parámetros de configuración se pueden pasar
    directamente al mysqld
      –   mysqld –basedir /usr/local/mysql
●   Otros parámetros que se pueden especificar:
      –   Habilitar/deshabilitar engines
      –   Opciones de rendimiento
      –   Logs
      –   …
●   Es más cómodo especificarlo en los ficheros de
    configuración



                                                                          20
Irontec – Administración de MySQL

                                       Ficheros de configuración

●   Por defecto busca los ficheros en las siguientes
    ubicaciones:
      –   /etc/my.cnf
      –   $MYSQL_HOME/my.cnf
      –   ~/.my.cnf
●   Se puede añadir un fichero de configuración en el
    arranque con:
      –   defaults­extra­file




                                                                   21
Irontec – Administración de MySQL

                                        Ficheros de configuración

●   El fichero se encuentra dividido en distintas secciones,
    por ejemplo [mysqld], [mysql], [mysqldump]
●   Cada opción dentro de una categoría se aplica
    únicamente a dicha aplicación
    [mysql]
    prompt='mysql [h] {u} (d) > '

    [mysqld]
    user                            = punisher
    port                            = 5140
    socket                          = 
    /tmp/mysql_sandbox5140.sock

    [mysqldump]
    quick
    quote­names
    max_allowed_packet      = 100M
                                                                    22
Irontec – Administración de MySQL

                        Engines




                               23
Irontec – Administración de MySQL

                                                          Engines




●   MySQL es modular, permite elegir entre diferentes
    engines para el almacenamiento de datos
●   Los engines se aplican a tablas, no a bases de datos
●   Puedes tener una base de datos con diferentes engines,
    dependiendo del tipo de datos o consultas que se
    hagan




                                                                 24
Irontec – Administración de MySQL

                                                            Tablas

●   Todas las tablas de MySQL tienen ciertas similitudes
●   Las tablas tienen .frm como formato. Este fichero
    guarda la estructura de la tabla
●   Independientemente del engine, tendremos un .frm
●   A parte, podemos tener otros ficheros acompañando
    al .frm




                                                                 25
Irontec – Administración de MySQL

                                                           Engines

●   Al crear una tabla se puede indicar el engine:
      create table t (i INT) ENGINE = MyISAM;


●   Una vez que está creada, se puede cambiar el engine:
            alter table t ENGINE = MyISAM;



●   También podemos saber con que engine se ha creado
    una tabla
                  Show create table t;


                                                                  26
Irontec – Administración de MySQL

                                                                       Engines

●   ¿De que engines tenemos soporte?
                                      show enginesG
mysql [localhost] {msandbox} (mysql) > 
*************************** 1. row ***************************
      Engine: InnoDB
     Support: YES
     Comment: Supports transactions, row­level locking, and foreign keys
Transactions: YES
          XA: YES
  Savepoints: YES
*************************** 2. row ***************************
      Engine: MRG_MYISAM
     Support: YES
     Comment: Collection of identical MyISAM tables
Transactions: NO
          XA: NO
  Savepoints: NO
*************************** 3. row ***************************
      Engine: BLACKHOLE
     Support: YES
     Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
          XA: NO
  Savepoints: NO
[...]



                                                                               27
Irontec – Administración de MySQL

                                                            MyISAM

●   MyISAM es el engine por defecto en MySQL
●   Si no se indica lo contrario, todas las tablas se crearán
    con este engine
●   Es obligatorio tener soporte para el engine en MySQL,
    ya que todas las tablas de la BBDD son MyISAM
●   La tabla viene definida por tres ficheros:
       –   mitabla.frm
       –   mitabla.MYD
       –   mitabla.MYI




                                                                    28
Irontec – Administración de MySQL

                                                                    MyISAM

●   Antes de usar MyISAM hay que conocer bien
    sus virtudes y defectos :)
●   Soporta busquedas FULLTEXT
●   Al escribir se hace uso de bloqueo de tabla
●   Se puede usar para generar tablas MERGE
●   No soporta, transacciones, integridad referencial o
    claves externas
●   Suele ser el más rápido en lecturas
●   No tiene cacheo de datos
●   Se pueden comprimir tablas para ahorrar espacio
    http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html

                                                                            29
Irontec – Administración de MySQL

                                                          MyISAM

●   El bloque en MyISAM se hace a nivel de tabla
●   No pueden ocurrir deadlocks (dos procesos se quedan
    esperando a que termine el otro)
●   Soporta inserciones concurrentes siempre y cuando la
    tabla no tenga “agujeros” causados por el borrado de
    datos (optimize table)
●   Las escrituras tienen prioridad sobre las lecturas
●   El servidor intenta hacer las escrituras en el orden en
    que las recibe




                                                                  30
Irontec – Administración de MySQL

                                                           MyISAM

●   Si una tabla se está leyendo y llega una petición de
    escritura, al escritura tiene que esperar
●   Si una tabla se está escribiendo y llega una petición de
    lectura, la lectura tiene que esperar
●   Si hay escrituras pendientes, las lecturas que lleguén
    tendrán que ponerse a la cola




                                                                   31
Irontec – Administración de MySQL

                                                              MyISAM

●   Las prioridades pueden moficiarse haciendo useo de
    los schedulers:
      –   LOW PRIORITY: para las querys que escriben datos. La
           escritura se queda esperando a que terminen todas las
           lecturas, incluso las que llegan después. Se escribirá
           cuando no exista ninguna lectura pendiente.
      –   HIGH PRIORITY: para las querys de lectura. Las querys
           con este modificador se mueven al principio de la cola,
           por delante de otras escrituras y lecturas
      –   DELAYED: para querys INSERT y REPLACE. El servidor
           mete en buffer las filas y lo inserta cuando no se esté
           usando la tabla. Las delayed se insertan en bloques en
           lugar de una a una aumentando el rendimiento


                                                                      32
Irontec – Administración de MySQL

                                                                      MyISAM

●   MyISAM puede almacenar las filas en tres formatos,
    fixed, dynamic y compressed.
●   FIXED
      –   Todas las filas tienen el mismo tamaño
      –   Ocupan más espacio
      –   Se encuentran más rápido
●   DYNAMIC
      –   Usa un tamaño variable de datos (menos que fixed)
      –   Las filas no se encuentran tan eficientemente
      –   Puede haber más fragmentación
●   COMPRESSED
      –   Ocupan mucho menos espacio
      –   Optimizado para consultas rápidas
      –   Solo lectura

                                                                              33
Irontec – Administración de MySQL

                                                          MyISAM

●   Para conocer el formato en el que se encuetran las filas
    de una tabla:
            SHOW TABLE STATUS LIKE 't'G

●   Crear tabla FIXED:
CREATE TABLE t (c CHAR(50)) ROW_FORMAT= FIXED;


●   Crear tabla DYNAMIC:
     CREATE TABLE t (c CHAR(50)) ROW_FORMAT= DYNAMIC;




                                                                  34
Irontec – Administración de MySQL

                                                        MyISAM

●   Una tabla MyISAM, fixed o dynamic, puede convertirse
    en tabla comprimida
●   Se suelen comprimir aquellas que se usan para datos
    históricos y que nunca van a ser modificadas
●   Son de solo lectura
●   Se comprimen con la utilidad myisampack
●   Se debe parar el servidor antes de comprimir
    los datos
●   Se descomprimen con myisamchk --unpack




                                                                35
Irontec – Administración de MySQL

                                                           MyISAM
$ myisampack departments employees
departments is too small to compress
Compressing employees.MYD: (300024 records)
­ Calculating statistics
­ Compressing file
47.12%     
Remember to run myisamchk ­rq on compressed tables

$ myisamchk ­rq departments employees
­ check record delete­chain
­ recovering (with sort) MyISAM­table 'departments'
Data records: 9
­ Fixing index 1
­ Fixing index 2
          
­­­­­­­­­

­ check record delete­chain
­ recovering (with sort) MyISAM­table 'employees'
Data records: 300024
­ Fixing index 1


                                                                   36
Irontec – Administración de MySQL

                                                            Merge

●   Una tabla merge es una colección de distintas tablas
    con la misma estructura
●   Una query en la tabla merge se ejecuta en todas las
    tablas que la componen
●   Puede ayudarnos a superar el tamaño máximo de una
    tabla MyISAM (256TB)
●   Es mas lento, ya que tiene que leer múltiples tablas
●   Aumenta el número de descriptores de ficheros
    abiertos requeridos




                                                                 37
Irontec – Administración de MySQL

                                                            Merge

●   Se suele utilizar para borrar millones de datos en un
    instante. Gracias a merge podemos borrar la tabla que
    lo compone en lugar de ir eliminando una a una cada
    fila
    mysql> CREATE TABLE A (name varchar(100)) 
    ENGINE=MyISAM; Query OK, 0 rows affected (0.00 sec)

    mysql> CREATE TABLE B (name varchar(100)) 
    ENGINE=MyISAM; Query OK, 0 rows affected (0.00 sec)

    mysql> CREATE TABLE TOTAL (name varchar(100)) 
    ENGINE=MERGE UNION=(A,B) INSERT_METHOD=LAST; 

    Query OK, 0 rows affected (0.01 sec)




                                                                 38
Irontec – Administración de MySQL

                                                            Merge

●   El problema de bloqueo se acentúa más con Merge
●   Cuando se bloquea para escritura, se bloquean todas
    las tablas que contiene
●   Cuando se bloquea para lectura, se bloquean todas las
    tablas que contiene
●   Añadir un registro en Merge puede traer como
    consecuencia el bloqueo de cientos de tablas
●   Contra más tablas y mas datos, mas problemas de
    rendimiento y bloqueos




                                                                 39
Irontec – Administración de MySQL

                                                               Memory

●   Es una tabla en memoria, lo cual ya nos da sus
    pros y contras solo con el nombre
      –   Es muy muy rápida
      –   Los datos no se guardan después del reinicio del servidor
      –   Usan la memoria RAM, por lo que no debe usarse para
            tablas grandes
      –   Usa bloqueo a nivel de tablas
      –   No puede tener columnas TEXT o BLOB




                                                                       40
Irontec – Administración de MySQL

                                                             Memory

●   Soporta dos típos de índices, HASH y BTREE:
      –   HASH: memory las usa por defecto. El algoritmo es muy
           rápido para comparaciones que usen índices únicos.
           Pero solo se puede usar para comparaciones = o <=>
      –   BTREE: es preferible para índices que se usarán con
           comparaciones disintas a las anteriores. Por ejemplo:
           id<1024 or id BETWEEN 4000 and 5000

          CREATE TABLE T (i int) ENGINE=MEMORY;




                                                                     41
Irontec – Administración de MySQL

                                                           Federated

●   Te permite usar tablas de otro servidores MySQL
    remotos
●   De esta forma el cliente no debe conectarse a otros
    servidores para acceder a los datos
●   Al estar en un servidor remoto, las federated no
    soportan el bloqueo de tablas
    CREATE TABLE federated_table (
        id     INT(20) NOT NULL AUTO_INCREMENT,
        name   VARCHAR(32) NOT NULL DEFAULT '',
        other  INT(20) NOT NULL DEFAULT '0',
        PRIMARY KEY  (id),
        INDEX name (name),
        INDEX other_key (other)
    )
    ENGINE=FEDERATED
    DEFAULT CHARSET=latin1
    CONNECTION='mysql://fed_user@remote_host:9306/federated/tes
    t_table';
                                                                     42
Irontec – Administración de MySQL

                                                        Federated

●   Los engines que se conectan a un servidor externo para
    coger datos (como FEDERATED, NDB o SPIDER) tienen
    un funcionamiento poco optimo cuando las querys
    tienen condiciones
●   En estos engines, la condición no se envia junto con la
    petición, por lo tanto el servidor remoto nos transmite
    TODAS las filas de la tabla para que nuestro MySQL
    local haga la búsqueda
●   Para solucionarlo se debe implementar “CONDITION
    PUSHDOWN” ya sea mediante un parche o plugin
●   Dependiendo del engine tendremos diferentes
    soluciones (o en algunos casos ninguna)

                                                                  43
Irontec – Administración de MySQL

                                                                 InnoDB

●   InnoDB nos ofrece todo aquello de lo que MyISAM
    carece
      –   Claves externas
      –   Integridad referencial
      –   Bloqueo de filas en lugar de tablas
      –   Auto recuperación ante errores
      –   Transacciones y rollbacks
      –   Cacheo de índices y datos
      –   Etc...

    http://dev.mysql.com/doc/refman/5.1/en/innodb.html


                                                                        44
Irontec – Administración de MySQL

                                                                 InnoDB

●   ¿Y que perdemos al pasarnos a InnoDB?
      –   Capacides de busqueda FULLTEXT
      –   La posibilidad de comprimir las tablas
      –   No poder hacer uso de Merge
      –   “Sólo” 64 TB de datos por tabla




                                                                        45
Irontec – Administración de MySQL

                                                               InnoDB

●   InnoDB es un engine que cumple las características
    ACID:
      –   Atomic: O todas las sentencias se ejectuan correctamente
            o se cancelan.
      –   Consistent: Es consistente cuando una transacción que
            comienza la deja en estado consistente al terminar.
      –   Isolated: Una transacción no afecta a las demás.
      –   Durable: Todos los cambios efectuados por una
            transacción se graban. No se pierden datos.




                                                                      46
Irontec – Administración de MySQL

                                                                 InnoDB

●   Cuando se producen múltiples transacciones que
    afectan a los mismos datos, pueden darse los siguientes
    problemas:
      –   Dirty read: es una lectura de una transacción de datos no
           commiteados realizados por otra. ¡Si finalmente esta
           última no hace el commit, lo que hemos leido no sirve!
      –   Non-repeatable: ocurre cuando una transacción realiza
           la misma petición de datos dos veces recibiendo
           resultados distintos
      –   Phantom: ocurre cuando aparece una fila que no era
           visible en la query, ya que otra transacción la ha incluido
           durante el proceso de lectura



                                                                        47
Irontec – Administración de MySQL

                                                                InnoDB
●   InnoDB dispone de 4 niveles de aislamiento:
      –   READ UNCOMMITED: permite a una transacción ver
            los datos sin commitear de otra. Se pueden dar non-
            repeatable reads, phantoms y dirty reads
      –   READ COMMITED: permite ver cambios de otras
            transacciones solo si están commiteados. Se pueden dar
            non-repeatable reads y phantoms
      –   REPETABLE READ: asegura que la misma SELECT
            ejecutada dos veces de los mismos valores. Las filas
            modificadas por una transacción no puden ser
            modificadas por otras. Se pueden dar phantoms
      –   SERIALIZE: separa completamente los efectos de unas
            transacciones sobre otras con la restricción de que las
            filas seleccionadas por una transacción no pueden ser
            accedidas por otras
                                                                       48
Irontec – Administración de MySQL

                                                        InnoDB

●   Por defecto InnoDB utiliza REPEATABLE READ para ser
    full ACID
●   Para cambiar de uno a otro aislamiento de:

[mysqld]
Transaction­isolation = READ­COMMITED




                                                               49
Irontec – Administración de MySQL

                                                           InnoDB

●   InnoDB implementa la concurrencia en las
    transacciones siguiendo el modelo MVCC (multiversion
    concurrency control)
●   Permite que cada transacción tenga una visión única de
    los datos (un snapshot) para tener una vista consistente
    con el paso del tiempo, sin tener en cuenta las
    modificaciones de otras transacciones
●   Esto puede permitir que distintas transacciones vean
    datos diferentes de la misma tabla en un mismo
    momento
●   Gracias a esto evitamos tener que bloquear siempre las
    filas. Menos overhead y más operaciones concurrentes
●   En lecturas casi nunca se bloquearán las filas
                                                                  50
Irontec – Administración de MySQL

                                                                  InnoDB

●   MVCC funciona añadiendo a cada fila dos valores
    adicionales que indican cuando fué creada y cuando
    fué eliminada
●   Con esto InnoDB se asegura que al iniciar una
    transacción...
      –   La fila existía antes de iniciar la transacción
      –   La fila no fué eliminada antes de iniciar la transacción
●   Con cada actualización de la fila, la transacción
    actualiza los valores asociados
●   El multiversioning se utiliza con:
      –   REPETABLE READ
      –   READ COMMITED

                                                                         51
Irontec – Administración de MySQL

                                                           InnoDB

●   Por defecto InnoDB viene habilitado con autocommit,
    cada query se commitea al instante
●   Esto no nos permite hacer rollback ni agrupar querys en
    batch para mejorar el rendimiento
●   ¿Y como desactivo el autocommit?
      –   SET AUTOCOMIT = 0;
      –   START TRANSACTION; COMMIT;
●   Para habilitar el rollback podemos añadir un
    SAVEPOINT
      –   SAVEPOINT nombre;
      –   ROLLBACK TO SAVEPOINT nombre;


                                                                  52
Irontec – Administración de MySQL

    Mantenimiento de tablas




                               53
Irontec – Administración de MySQL

                                      Mantenimiento de tablas

●   Existen una serie de comandos que nos ayudar al
    mantenimiento de las tablas
●   Algunos son tienen utilidad en unos engines pero no en
    otros
●   Podemos:
      –   Chequear
      –   Reparar
      –   Analizar
      –   Optimizar




                                                                 54
Irontec – Administración de MySQL

                                             Mantenimiento de tablas

●   CHECK TABLE
       –   Realizar un chequeo de integridad tanto de la estructura
             como del contenido de los datos
       –   Funciona tanto en MyISAM como InnoDB
       –   En MyISAM además actualiza las estadísticas de los índices
●   Su uso es el siguiente:
mysql > check table A;
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
| Table     | Op    | Msg_type | Msg_text |
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
| pruebas.A | check | status   | OK       |
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
1 row in set (0.00 sec)



                                                                        55
Irontec – Administración de MySQL

                                           Mantenimiento de tablas

●   REPAIR TABLE
      –   Repara los errores que se puedan encontrar en una tabla
      –   Solo funciona con MyISAM
      –   Se puede habilitar el auto-reparado de tablas
[mysqld]
myisam­recover=[Opciones]

­ Default: opciones por defecto
­ Backup: hace backup de las tablas que tenga que 
cambiar
­ Force: fuerza la reparación aunque se puedan 
perder datos
­ Quick: las tablas no fragmentadas se evitan



                                                                      56
Irontec – Administración de MySQL

                                 Mantenimiento de tablas

●   Reparación en caliente


mysql > repair table A;
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
| Table     | Op    | Msg_type | Msg_text |
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
| pruebas.A | repair| status   | OK       |
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
1 row in set (0.00 sec)




                                                            57
Irontec – Administración de MySQL

                                             Mantenimiento de tablas

●   ANALYZE TABLE
      –   Actualiza las tablas con información acerca de la
            distribución de los valores de las claves en la tabla
      –   Esta información la usa el optimizador para elegir el mejor
            plan de ejecución
      –   Solo funciona en MyISAM
mysql > analyze table A;
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
| Table     | Op    | Msg_type | Msg_text |
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
| pruebas.A |analyze| status   | OK       |
+­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
1 row in set (0.00 sec)



                                                                        58
Irontec – Administración de MySQL

                                            Mantenimiento de tablas

●   OPTIMIZE TABLE
      –   Desfragmenta las tablas MyISAM, eliminando los huecos
            generados por múltiples updates y deletes
      –   Actualiza las estadísticas de los índices
      –   Se puede utilizar en InnoDB, pero no desfragmenta (ya
            que InnoDB no se fragmenta) Actualiza las estadísticas
            de índices y libera espacio relacionado con índices
    mysql > optimize table A;
    +­­­­­­­­­­­+­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
    | Table     | Op     | Msg_type | Msg_text |
    +­­­­­­­­­­­+­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
    | pruebas.A |optimize| status   | OK       |
    +­­­­­­­­­­­+­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+
    1 row in set (0.00 sec)


                                                                       59
Irontec – Administración de MySQL

                                      Mantenimiento de tablas

●   Existen herramientas externas de consola que también
    nos pueden ayudar con el mantenimiento
      –   mysqlcheck
      –   myisamchk
●   Mysqlcheck envía las sentencias SQL necesarias para
    el mantenimiento. Por lo tanto, mysqld debe estár en
    funcionamiento
●   Myisamchk no necesita de un servidor en
    funcionamiento, puede actuar directamente contra las
    tablas en el sistema de ficheros



                                                                 60
Irontec – Administración de MySQL

                                            Mantenimiento de tablas

●   Mysqlcheck nos ofrece alguna ventaja al uso de las
    sentencias SQL directamente
      –   Podemos indicarle una BBDD para que haga operaciones
            de mantenimiento en todas sus tablas en lugar de indicar
            una a una
      –   Al ser un comando de consola, se puede crear una tarea
            programada
●   Ejemplo:
      –   Mysqlcheck test (chequea BBDD test)
      –   Mysqlcheck test A (chequea tabla A de la BBDD test)
      –   Mysqlcheck –all-databases (chequea todo)
      –   --check, --repair, --analyze, --optimize


                                                                       61
Irontec – Administración de MySQL

                                       Mantenimiento de tablas

●   Myisamchk permite realizar las mismas tareas que
    mysqlcheck
●   Se debe hacer offline, con mysqld apagado
●   Actua directamente sobre las tablas
●   Es el último recurso cuando ni siquiera el servidor
    arranca (por ejemplo, tablas en la BBDD mysql
    corruptas)
●   Como el propio nombre indica, solo funciona con
    tablas MyISAM




                                                                  62
Irontec – Administración de MySQL

          Usuarios y permisos




                               63
Irontec – Administración de MySQL

                                            Usuarios y permisos

●   MySQL permite definir usuarios y decidir que pueden
    hacer
●   Los usuarios siguen el siguiente formato:
      –   'usuario'@'host'
●   No es lo mismo irontec@localhost que
    irontec@10.10.0.210
●   La primera parte es el nombre de usuario con el que
    haremos login, mientras que la segunda será la IP desde
    la cual nos conectamos




                                                                 64
Irontec – Administración de MySQL

                                             Usuarios y permisos

●   Se puede crear un usuario que se conecta desde
    cualquier ubicación:
      –   'irontec'@'%'
●   Los usuarios y permisos se guardan dentro de las tablas
    user y grant de la BBDD mysql
●   Es posible insertar datos directamente mediante la
    consola de mysql, pero también es más lioso
●   ¡No debe existir nunca un 'root'@'%', por seguridad!




                                                                  65
Irontec – Administración de MySQL

                                                  Usuarios y permisos

●   Para ver todos los permisos disponibles y una
    descripción:

             mysql > show privileges;



●   Nos muestra tres columnas:
      –   Privilege: es el nombre del permiso
      –   Context: contexto en el cual es posible aplicar el permiso
      –   Comment: breve explicación




                                                                       66
Irontec – Administración de MySQL

                                                Usuarios y permisos

●   Permisos especiales:
      –   ALL y ALL PRIVILEGES da todos los permisos excepto
           GRANT OPTION
      –   USAGE no da ningún privilegio excepto el de conexión




                                                                     67
Irontec – Administración de MySQL

                                            Usuarios y permisos

●   Los permisos pueden aplicarse en diferentes contextos:
      –   Server
      –   Databases
      –   Tables
      –   Functions
      –   Procedures
      –   Indexes
      –   File Access
●   Por ejemplo, no puedes dar permisos FILE a un usuario
    sobre una tabla, es un permiso global o CREATE
    ROUTINE a nivel de índice
●   Todos pueden aplicarse globalmente

                                                                 68
Irontec – Administración de MySQL

                                             Usuarios y permisos

●   Para crear un usuario se debe indicar tanto el usuario
    como el host y su contraseña (no obligatorio):

mysql > create user 'irontec'@'localhost' 
IDENTIFIED BY '1234';

●   Borrar un usuario:
mysql > drop user 'irontec'@'localhost';

●   Renombrar un usuario:

mysql > rename user 'irontec'@'localhost' TO 
'miguelangel'@'localhost';

                                                                  69
Irontec – Administración de MySQL

                                              Usuarios y permisos

●   Para cambiar una contraseña hay distintas formas:
      –   Para un usuario en particular:

mysql > SET PASSWORD for 'miguel'@'localhost' = 
PASSWORD('nueva');


      –   Para tu usuario:
mysql > SET PASSWORD = PASSWORD('nueva');


      –   Mediante GRANT:

mysql > GRANT USAGE ON *.* TO 
'miguel'@'localhost' IDENTIFIED BY 'nueva';

                                                                   70
Irontec – Administración de MySQL

                                            Usuarios y permisos

●   Para dar permisos se usa GRANT
●   Importante: si el usuario al que damos permisos no
    existe, lo crea
mysql > GRANT SELECT ON mysql.* TO 
'miguel'@'localhost' IDENTIFIED BY 'test';

●   Se pueden indicar múltiples permisos separándolos por
    comas
●   Para aplicar a distintos contextos:
      –   ON *.*
      –   ON db.*
      –   ON db.table
      –   ON db.routine
                                                                 71
Irontec – Administración de MySQL

                                              Usuarios y permisos

●   Para eliminar un permiso haremos uso de REVOKE:
mysql > REVOKE SELECT ON mysql.* FROM 
'miguel'@'localhost';

●   El usuario seguirá existiendo, pero sin el permiso
    indicado
mysql > show grants for 'miguel'@'localhost';


●   Si le borramos el último permiso, USAGE, no se podrá
    conectar




                                                                   72
Irontec – Administración de MySQL

     Optimización de querys




                               73
Irontec – Administración de MySQL

                                       Optimización de querys

●   Hay que tener especial cuidado con las querys que se
    lanzan a una base de datos
●   Si está mal construida puede degradar el rendimiento
    del servicio
●   Es necesario detectar estas querys y reescribirlas
    completamente
●   EXPLAIN nos ayudará a saber como se comportar
    internamente una query y cuales son sus deficiencias




                                                                 74
Irontec – Administración de MySQL

                                        Optimización de querys

●   En primer lugar debemos detectar cuales son esas
    querys
●   Para ello nos ayudaremos del log-slow
●   En este log se irán escribiendo las sentencias SQL que
    tarden un tiempo superior al que le indiquemos
●   Su activación no afecta al rendimiento como otros logs
      –   log­slow­queries=/var/log/mysql/slow­querys.log
      –   long_query_time=5
      –   Log­queries­not­using­indexes
●   Log de querys lentas (superior a 5 segundos) así como
    querys sin índices :)


                                                                  75
Irontec – Administración de MySQL

                                          Optimización de querys

●   El log puede crecer con el tiempo y leerlo con un editor
    de textos convertirse en un infierno
●   No es necesario hacerte tu propio script, ya existen
    utilidades para dumpearlo
    /var/log/mysql# mysqldumpslow mysql­slow.log



●   Nos resumirá las querys lentas




                                                                    76
Irontec – Administración de MySQL

                                  Optimización de querys

●   ¿Cómo se ve en el log?


/var/log/mysql# cat mysql­slow.log

# Query_time: 4.00s  Lock_time: 0  Rows_sent: 0  
Rows_examined: 1380
SELECT * FROM foobar WHERE id="foo";
# Query_time: 2.50s  Lock_time: 0  Rows_sent: 0  
Rows_examined: 1380
SELECT * FROM foobar WHERE id="bar";




                                                            77
Irontec – Administración de MySQL

                                     Optimización de querys

●   Ejemplo de mysqldumpslow:


/var/log/mysql# mysqldumpslow mysql­slow.log

Count: 2  Time=4s (6.50s)  Lock=0.00s (0s)  
Rows=1380 (2760)
SELECT * FROM foobar WHERE id='S';




                                                               78
Irontec – Administración de MySQL

                                           Optimización de querys

●   Ya tenemos identificadas las querys lentas, ahora es
    necesario estudiarlas
      –   Mysql > explain [extended] SELECT [opciones]
●   Basicamente nos mostrará información del plan de
    ejecución del optimizador
●   Sólo funciona con SELECT




                                                                     79
Irontec – Administración de MySQL

                                Optimización de querys

●   Problema:
explain SELECT * from City where 
CountryCode='ESP'G
*************************** 1. row 
***************************
           id: 1
  select_type: SIMPLE
        table: City
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4079
        Extra: Using where
1 row in set (0.00 sec)
                                                          80
Irontec – Administración de MySQL

                                       Optimización de querys
●   ID: identificador de la query, en caso de tener
    subquerys
●   select_type: el tipo de select. Simple, primary,
    derived, union, subquery
●   table: indica el nombre de la tabla utilizada
●   type: tipo de acceso para la query. system/const,
    eq_ref, ref, ref_or_null, index_merge, range, index,
    ALL
●   possible_keys: lista de índices disponibles para usar
●   key: índice utilizado
●   key_len: número de bytes utilizados del índice
●   rows: número de filas a leer
●   extra: información extra de la query
                                                                 81
Irontec – Administración de MySQL

                                             Optimización de querys

●   Type:
      –   system: la tabla tiene una única fila
      –   const: la tabla tiene una única fila coincidente con la
            query
      –   eq_ref: la busqueda por índices da una única fila
      –   ref: similar a eq_ref pero puede devolver más de una fila
      –   ref_or_null: igual que los anteriores, pero también busca
            valores NULL
      –   index_merge: el único tipo de acceso que usa dos
            índices
      –   range: busqueda por rango
      –   index: busqueda completa por la tabla, pero de índices
            en lugar de los datos
      –   ALL: escaneo completo de la tabla. MAL
                                                                       82
Irontec – Administración de MySQL

                                            Optimización de querys

●   Extra:
      –   Using index: se está usando un index, cogiendo el dato
           del índice en lugar de la tabla
      –   Using filesort: se ordenan las filas de forma manual en
           lugar de usar índices
      –   Using temporary: se ha usado una tabla temporal (en
           RAM o disco) para realizar la consulta
      –   Using where: el filtrado se hace fuera del engine




                                                                      83
Irontec – Administración de MySQL

                                   Optimización de querys

●   Volvemos al problema :)
explain SELECT * from City where 
CountryCode='ESP'G
*************************** 1. row 
***************************
           id: 1
  select_type: SIMPLE
        table: City
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4079
        Extra: Using where
1 row in set (0.00 sec)
                                                             84
Irontec – Administración de MySQL

                                            Optimización de querys

●   El optimizador no encuentra índices
●   Al no encontrar... no puede usar
●   Como no hay índices, el tipo de búsqueda es ALL, se
    lee todas las filas
●   ¿Como podríamos mejorarlo?
      –   Añadiendo índices
      –   Optimizar la query añadiendo más detalles
●   Después de cada cambio hay que comprobar si existe
    mejora




                                                                      85
Irontec – Administración de MySQL

                                        Optimización de querys

●   Añadiendo un índice:
      –   Mysql>alter table City add index(CountryCode);
          Query OK, 4079 rows affected (0.02 sec)
          Records: 4079  Duplicates: 0  Warnings: 0
●   Ejecutamos de nuevo la query con explain:
                         id: 1
                select_type: SIMPLE
                      table: City
                       type: ref
              possible_keys: CountryCode
                        key: CountryCode
                    key_len: 3
                        ref: const
                       rows: 58
                      Extra: Using where
              1 row in set (0.00 sec)

                                                                  86
Irontec – Administración de MySQL

                                        Optimización de querys

●    Modificamos la query añadiendo más datos, haciéndola
     más concisa:
        – explain SELECT * from City where 
            CountryCode='ESP' and District='Madrid';
        – alter table City add index(District);
               id: 1
      select_type: SIMPLE
            table: City
             type: index_merge
    possible_keys: CountryCode,District
              key: District,CountryCode
          key_len: 20,3
              ref: NULL
             rows: 1
            Extra: Using intersect(District,CountryCode); 
    Using where
    1 row in set (0.00 sec)

                                                                  87
Irontec – Administración de MySQL

Optimización de la base de datos




                                   88
Irontec – Administración de MySQL

                                  Optimización de la base de datos

●   Cuando nos referimos a optimizar la base de datos,
    esto implica en primer lugar optimizar el servidor
      –   RAM: contra más RAM, más índices y datos en memoria,
            por lo tanto más velocidad de respuesta
      –   CPU: nunca sobra la CPU y los cores ;)
      –   Disco duro: contra más rápido mejor. Últimamente se
            estan empezando a usar disco SSD para bases de datos
●   Una vez que tenemos el mejor equipo que podamos
    comprar, tocará optimizar la base de datos de acuerdo
    a dicho hardware




                                                                      89
Irontec – Administración de MySQL

                                      Optimización de la base de datos

●   ¿32 o 64 bits?
●   Siempre que sea posible es recomendable 64 bits
●   En sistemas GNU/Linux y Solaris de 32 bits, un solo
    proceso no puede usar más de 2GB. Por lo tanto da
    igual que tengamos 4, MySQL usará la mitad
●   En algunos sistemas, según un parámetro de
    configuración del kernel, puede disponer de 3 GB,
    pero puede ser insuficiente
●   En 64 bits no existe esa limitación
●   Si tienes 32 bits, no configures MySQL para que use
    mas de 2GB, tendrás errores de falta de memoria
    memory=key_buffer+(sort_buffer_size+read_buffer_size)*max_connections

                                                                          90
Irontec – Administración de MySQL

                            Optimización de la base de datos

●   Las optimizaciones también dependerán mucho del
    tipo de querys que ejecutemos
●   Para tener una estadística
             mysql> show status like 'Com%';




                                                               91
Irontec – Administración de MySQL

                                  Optimización de la base de datos

●   Número máximo de conexiones (max_connections)
      –   Son el número máximo de conexiones simultaneas que
            soportará el servidor
      –   Cada conexión en espera consume memoria
      –   Se debe ajustar a un número no muy superior a la media
            de nuestro servidor
mysql> show status like '%connections%';
+­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­+
| Variable_name        | Value   |
+­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­+
| Connections          | 4651724 | 
| Max_used_connections | 41      | 
+­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­+
2 rows in set (0.01 sec)


                                                                      92
Irontec – Administración de MySQL

                                     Optimización de la base de datos

●   Cache de tablas (table_cache)
      –   Cada vez que mysql abre una tabla mantiene en cache
             información sobre ella para evitar reabrirlas
      –   Si se abren muchas y un usuario necesita abrir otra nueva,
             una de las ya abiertas debe cerrarse
      –   No vale poner millones y millones, estamos limitados por
             los descriptores del sistema operativo
●   Si Open_tables está cercano a Table_cache y
    Opened_tables no para de aumentar, toca subir el
    table_cache mysql> show status like 'Open%tables%';
                    +­­­­­­­­­­­­­­­+­­­­­­­+
                    | Variable_name | Value |
                    +­­­­­­­­­­­­­­­+­­­­­­­+
                    | Open_tables   | 1551  | 
                    | Opened_tables | 0     | 
                    +­­­­­­­­­­­­­­­+­­­­­­­+
                    2 rows in set (0.02 sec)

                                                                         93
Irontec – Administración de MySQL

                                    Optimización de la base de datos

●   Cacheo de índices en MyISAM (key_buffer_size)
      –   Cachea los índices que lee de una tabla MyISAM
      –   Permite reutilizar los índices en lugar de leerlos
             continuamente, más rendimiento
      –   Para calcularlo:
          Ratio de fallo: Key_reads / Key_read_requests
          Eficiencia: 1 – (Key_reads / Key_read_requests)
      –   Los fallos tienen que estar lo más cerca posible de 0 y
             eficiencia de 1
           mysql> show status like 'Key_read%';
           +­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+
           | Variable_name     | Value     |
           +­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+
           | Key_read_requests | 150683856 | 
           | Key_reads         | 325197    | 
           +­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+
           2 rows in set (0.01 sec)
                                                                        94
Irontec – Administración de MySQL

                                   Optimización de la base de datos

●   Buffer de InnoDB (innodb_buffer_pool_size)
      –   Cache tanto los índices como los datos de una tabla
             InnoDB
      –   El valor por defecto es 8 megas, pero se recomienda entre
             el 50% y 80% de la memoria total del sistema

      mysql> show variables like 
      'innodb_buffer_pool_size';
      +­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+
      | Variable_name           | Value     |
      +­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+
      | innodb_buffer_pool_size | 838860800 | 
      +­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+
      1 row in set (0.00 sec)



                                                                       95
Irontec – Administración de MySQL

                                   Optimización de la base de datos

●   Cacheo de querys (query_cache_size)
      –   Nos permite almacenar en cache el resultado de una query
            select
      –   La cache solo se mantiene mientras los datos de la tabla no
            se modifiquen
●   query_cache_type: OFF desactivado, ON activado,
    DEMAND solo para SELECT SQL_CACHE
●   query_cache_size: 0 es desactivado
●   query_cache_limit: el tamaño máximo de una query
    que se puede almacenar



                                                                       96
Irontec – Administración de MySQL

                                  Optimización de la base de datos

●   Midiendo la efectividad de la cache:
       –   Qcache_hits: numero de querys que no se han
            ejecutado por estar en cache
       –   Qcache_inserts: el número total de querys guardadas en
            la cache
       –   Qcache_lowmem_prunes: número de caches
            eliminadas por falta de memoria
●   Si hits es bajo e inserts alto... hay que aumentar la
    caché




                                                                      97
Irontec – Administración de MySQL

                                    Optimización de la base de datos

●   Otros valores:
      –   read_buffer_size: cuando se lee una tabla lo leerá en
            bloques del tamaño que aquí indiquemos. Contra mas
            grande, más rápido la leerá
      –   read_rnd_buffer_size: por defecto coge el valor del
            anterior. Se usa para lecturas no secuenciales (como las
            requeridas por ORDER BY)
      –   sort_buffer_size: para las operaciones con ORDER o
            GROUP BY
      –   join_buffer_size: para querys con joins




                                                                        98
Irontec – Administración de MySQL

      Optimización de tablas




                               99
Irontec – Administración de MySQL

                                       Optimización de tablas

●   Si las tablas aumentan mucho puede llegar un
    momento en el que los índices ocupen más que la
    propia RAM del sistema


         ÍNDICES



            RAM

                                                                100
Irontec – Administración de MySQL

                            Optimización de tablas

●   ¡Particionemos!




                                                     101
Irontec – Administración de MySQL

                                             Optimización de tablas

●   Si no queremos comprar más RAM, los índices se
    vuelven lentos
●   Particionar se vuelve más rápido que los índices
●   Será nuestra salvación cuando:
      –   Nos quedemos sin RAM
      –   Tenemos muchísimos datos
      –   Guardamos datos históricos
      –   Rotamos datos
      –   Datos crecientes
Es transparente, no tendremos que modificar las
                  aplicaciones


                                                                      102
Irontec – Administración de MySQL

                                               Optimización de tablas

●   Cosas a tener en cuenta antes de particionar:
      –   La columna que utilicemos para definir el rango de las
             particiones debe ser un INT, no se acepta cualquier otro
             valor
      –   Si tenemos una clave única o una primary key, esta debe
             usarse para particionar
      –   Como máximo se permiten 1024 particiones
      –   No se permiten claves externas
      –   No se permiten búsquedas FULL TEXT




                                                                        103
Irontec – Administración de MySQL

                                               Optimización de tablas

●   El particionado se puede hacer:
      –   Por rango: es el más sencillo, se divide en base a rangos
      –   Por listas: se divide en particiones en base a una lista de
           posibles valores
      –   Por hash: nos permite dividir los datos de forma
           equitativa entre todas las particiones. La expresión por la
           que separar los datos debe devolver un entero
      –   Por key: similar a hash. En lugar de indicar nosotros el
           valor del hash, lo hace el propio MySQL con md5 y
           password(). Pueden usarse columnas que no sean entero




                                                                        104
Irontec – Administración de MySQL

                                 Optimización de tablas

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970­01­01',
    separated DATE NOT NULL DEFAULT '9999­12­
31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1 VALUES LESS THAN (11),
    PARTITION p2 VALUES LESS THAN (16),
    PARTITION p3 VALUES LESS THAN (21),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

                                                          105
Irontec – Administración de MySQL

                                 Optimización de tablas
CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970­01­01',
    separated DATE NOT NULL DEFAULT '9999­12­
31',
    job_code INT,
    store_id INT
)
PARTITION BY LIST(store_id) (
    PARTITION pNorth VALUES IN (3,5,6,9,17),
    PARTITION pEast VALUES IN 
(1,2,10,11,19,20),
    PARTITION pWest VALUES IN 
(4,12,13,14,18),
    PARTITION pCentral VALUES IN (7,8,15,16)
);

                                                          106
Irontec – Administración de MySQL

                               Optimización de tablas

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970­01­
01',
    separated DATE NOT NULL DEFAULT 
'9999­12­31',
    job_code INT,
    store_id INT
)
PARTITION BY HASH( YEAR(hired) )
PARTITIONS 4;



                                                        107
Irontec – Administración de MySQL

                           Optimización de tablas




CREATE TABLE Employee (
    emp_id INT,
    fname VARCHAR(50),
    lname VARCHAR(50),
    store_id TINYINT
  ) ENGINE=MyISAM
  PARTITION BY KEY (lname)
  PARTITIONS 4;




                                                    108
Irontec – Administración de MySQL

                                         Optimización de tablas

●   Existe un script que nos permite crearnos la query de
    creación de particiones
    http://forge.mysql.com/wiki/Partition_Helper

    ./partitions_helper ­­table=mytable ­­column=d 
    ­interval=year ­­start=2004­01­01 –end=2009­01­01

    ./partitions_helper ­­table=mytable ­­column=d 
    ­­interval=month ­­start=2008­01­01 ­­end=2009­01­01

    ./partitions_helper ­­table=mytable –column=prod_id 
    ­­interval=1000 ­­start=1 –end=10000




                                                                  109
Irontec – Administración de MySQL

                                          Optimización de tablas

●   Para comprobar si las particiones funcionan y en que
    partición se encuentran nuestros datos:
     mysql [localhost] {msandbox} (employees) > explain 
     partitions select count(*) from salaries
     where from_date between '2000­01­01' and '2000­12­31'G
     *************************** 1. row 
     ***************************
                id: 1
       select_type: SIMPLE
             table: salaries
        partitions: p016
              type: index
     possible_keys: NULL
               key: emp_no
           key_len: 4
               ref: NULL
              rows: 2830488
             Extra: Using where; Using index
     1 row in set (0.00 sec)


                                                                   110
Irontec – Administración de MySQL

                                              Optimización de tablas

●   Mantenimiento de tablas RANGE y LIST
      –   Se pueden añadir más particiones
     ALTER TABLE gente ADD PARTITION (PARTITION p4 VALUES 
                      LESS THAN (2010));
      –   Se pueden eliminar particiones (borra datos)
               ALTER TABLE gente DROP PARTITION p4
      –   Se reorganizar particiones
     ALTER TABLE gente REORGANIZE PARTITION p0 INTO (
              PARTITION s0 VALUES LESS THAN (1960),
               PARTITION s1 VALUES LESS THAN (1970)
                                  );




                                                                       111
Irontec – Administración de MySQL

                                              Optimización de tablas

●   Mantenimiento de tablas HASH y KEY
       –   Se pueden añadir más particiones
           ALTER TABLE gente ADD PARTITION PARTITIONS 2;
       –   Se pueden reducir el número de particiones, DROP no
             funciona
             ALTER TABLE gente COALESCALE PARTITION 2;
●   Las particiones HASH o KEY se auto reorganizan según
    añadamos o eliminemos particiones




                                                                       112
Irontec – Administración de MySQL

                                                Optimización de tablas

●   Reconstruir partición:
      –   Borrar los datos de la partición para volver a insertarlos. De
            esta forma solucionas el problema de fragmentado
●   Optimizar partición:
      –   Otra forma de solucionar la fragmentación. Reclama el
           espacio libre y reorganiza los datos
●   Analizar partición:
      –   Lee y almacena la distribución de índices
●   Reparar partición:
      –   Repara particiones corruptas
●   Chequear partición:
      –   Chequea una partición en busca de errores

                                                                         113
Irontec – Administración de MySQL

                             Optimización de tablas




ALTER TABLE gente REBUILD PARTITION p1;
ALTER TABLE gente OPTIMIZE PARTITION p1;
ALTER TABLE gente ANALYZE PARTITION p1;
 ALTER TABLE gente REPAIR PARTITION p1;
  ALTER TABLE gente CHECK PARTITION p1;




                                                      114
Irontec – Administración de MySQL

                            Logs




                               115
Irontec – Administración de MySQL

                                                                     Logs

●   En MySQL tenemos 3 tipos de logs
      –   Slow: guardan las querys lentas
      –   Sql: guarda todas las querys que se ha recibido el servidor
      –   Binlog: guarda únicamente las querys que modifican
            datos
●   ¿Para que nos pueden servir?
      –   Arreglar querys lentas o sin índices
      –   Debuggear a nivel SQL nuestra aplicación
      –   Replicación o recuperación de backup




                                                                        116
Irontec – Administración de MySQL

                                                Logs

●   Slow Logs:
      –   Goto 75




                                                   117
Irontec – Administración de MySQL

                                                              Logs

●   SQL log almacena todas las querys que llegan a
    nuestro servidor
●   Se puede usar para debuggear nuestra aplicación antes
    de pasarla a producción
●   En producción no es recomendable tenerlo habilitado,
    consume muchos recusos tanto de CPU como de disco
    duro
●   Si este log está activado, el logrotate debe estar
    habilitado

           log=/var/log/mysql/mysql.log

                                                                 118
Irontec – Administración de MySQL

                                                               Logs

●   Los logs binarios almacenan los cambios que se realizan
    en la BBDD (update, insert, delete, alter, etc.)
●   Nos sirven para:
      –   Recuperación de backup
      –   Replicación
●   Es recomendable tenerlos habilitados, no consumen
    mucho y nos pueden salvar la vida
●   En caso de replicación es obligatorio tenerlos
    habilitados




                                                                  119
Irontec – Administración de MySQL

                                                                  Logs

●   Otras opciones:
      –   max_binlog_size (por defecto y máximo 1 GB)
      –   expire_logs_days
      –   sync_binlog (>0)
      –   replicate-do-db
      –   replicate-ignore-db
      –   binlog-do-db
      –   binlog-ignore-db
      –   replicate-do-table
      –   replicate-wild-do-table
      –   replicate-ignore-table
      –   replicate-wild-ignore-table

                                                                     120
Irontec – Administración de MySQL

                            Logs




                               121
Irontec – Administración de MySQL

                                                                           Logs

●   El diagrama para el logeo de tablas es demasiado
    grande y no entra ;)
    http://dev.mysql.com/doc/refman/5.0/en/replication-rules-table-options.html
●   Para rellenar la diapositiva pondré un dibujo:




    No se quien es el autor :(

                                                                              122
Irontec – Administración de MySQL

Replicación y alta disponibilidad




                                  123
Irontec – Administración de MySQL

                                   Arquitecturas de replicación

●   Tenemos varias formas de montar una arquitectura de
    replicación.
      –   Maestro-Maestro
      –   Maestro-Esclavo
      –   Circular
●   Según lo que se necesite, se monta una u otra.




                                                                 124
Irontec – Administración de MySQL

                                                    Limitaciones




●   Un esclavo solo puede tener un maestro. Por el
    contrario, un maestro múltiples esclavos.
●   No es recomendable montar una replicación por WAN.
    La replicación es asíncrona y sensible a latencias.
●   En un servidor esclavo esta prohibido escribir datos,
    solo se usarán selects.
                                                                125
Irontec – Administración de MySQL

                                                  Maestro-Esclavo

●   Un maestro, múltiples esclavos.
●   En el maestro se escribe, en el esclavo se lee.




                                                                   126
Irontec – Administración de MySQL

                                                        Maestro-Esclavo

●    Primero debemos configurar el maestro.
     Imprescindible:
        –   Habilitar los logs binarios.
        –   Crear un usuario que permita conectarse a los esclavos.
        –   Habilitar sync_binlog.
        –   Elegir un server-id.

    log­bin=mysql­bin
    server­id=1
    sync_binlog=1




                                                                         127
Irontec – Administración de MySQL

                                               Maestro-Esclavo

●   Dar permisos de conexión a los eslavos y dumpeamos
    la BD:

    mysqldump BD ­­master­data=2 > dump_file;

 mysql> grant replication slave on *.* to 
'replication'@10.10.10.1 identified by 'slave';

 mysql> grant replication slave on *.* to 
'replication'@10.10.10.2 identified by 'slave';




                                                                128
Irontec – Administración de MySQL

                                                    Maestro-Esclavo

●   Configuramos el eslavo:
      –   Seleccionamos un ID diferente para cada uno.
      –   Importamos la BD.
      –   Nos configuramos como esclavo de un maestro.
$mysql ­u root ­p < dump

server­id=101

mysql> CHANGE MASTER TO MASTER_HOST = ‘10.10.10.100’, 
MASTER_USER = ‘replication’, MASTER_PASSWORD = ‘slave’, 
MASTER_LOG_FILE = ‘master_log_file’, MASTER_LOG_POS = 
master_log_pos;




                                                                     129
Irontec – Administración de MySQL

                                               Maestro-Esclavo

●   Master_log_pos y Master_log_file indican al esclavo
    desde que posición del log binario deben leer, de
    forma que no se repliquen datos que ya tenemos.
●   Podemos sacarlo con un dump como ya hemos visto o
    con el comando show master status;
●   El log binario debe estár habilitado :)




                                                                130
Irontec – Administración de MySQL

                                                  Maestro-Esclavo

●   No se debe dejar al servidor la elección de cuando
    escribir los datos al disco duro.
●   Si el servidor se cae sin que algunos datos se escriban
    en el log, es posible que estos se pierdan (dependerá
    del sistema de ficheros).
●   sync_binlog por defecto es 0, que deja que el servidor
    decida cuando realizar la escritura al disco.
●   Se recomienda un valor de 1, para que se fuerce la
    escritura.
●   Esto también es lento, dependerá de los discos duros
    instalados.
●   Si el servidor se cae, como mucho perderemos una
    transacción.                                            131
Irontec – Administración de MySQL

                                                 Maestro-Esclavo

●   Para comprobar si la replicación es correcta tenemos el
    comando show slave status.
●   Este nos tiene que mostrar lo siguiente:
[...]
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
[...]
Seconds_Behind_Master: 0

    Slave_IO_Running: Se encarga de conectarse al
    maestro para comprobar cambios
    Slave_SQL_Running: Se encarga de escribir las
    sentencias SQL.
    Seconds_Behind_Master: El lag en segundos entre
    el maestro y el esclavo.
                                                                  132
Irontec – Administración de MySQL

                                                Maestro-Maestro

●   Lo que se escribe en uno se replica en el otro.
●   Se puede escribir en los dos.




                                                                  133
Irontec – Administración de MySQL

                                                 Maestro-Maestro

●   La arquitectura maestro-maestro es igual a la maestro
    esclavo.
●   Aquí los hosts realizan las dos tareas, maestro y esclavo
    al mismo tiempo.
●   Esta arquitectura soporta como máximo dos hosts, ya
    que un esclavo solo puede tener como máximo un
    maestro.
             A es maestro de B. B es maestro de A.
              A es esclavo de B. B es esclavo de A.




                                                                   134
Irontec – Administración de MySQL

                                                       Maestro-Maestro

●   Se debe tener en cuenta, al igual que antes, lo
    siguiente:
      –   Habilitar el log binario.
      –   Seleccionar un server-id.
      –   Establecer el valor de sync_binlog.
      –   Crear los usuarios para la replicación.
●   El funcionamiento, opciones, monitorización, etc. es
    todo igual.




                                                                         135
Irontec – Administración de MySQL

                                                 Maestro-Maestro

●   Los auto-incrementales son el gran problema de este
    tipo de arquitectura. Si se realizan dos insert al mismo
    tiempo que incluya un campo autoincremental,
    podemos tener un problema de ID duplicado.
●   A envía a B un artículo cuyo ID autoincremental es
    3000, B envía un artículo diferente a A cuyo
    autoincremental es 3000 también. La replicación se
    rompe.
       –   auto_increment_increment = 2
       –   auto_increment_offset = 1
●   ¿Cómo sería para el server B?


                                                                   136
Irontec – Administración de MySQL

                                                            Circular

●   Lo que se escribe en uno se replica en el siguiente, este
    en el siguiente, este en... A → B → C → D → A
●   Es la menos recomendable. En realidad está casi
    prohibida también ;)




                                                                   137
Irontec – Administración de MySQL

                                                           Circular

●   Es una forma de disponer de más de dos servidores en
    arquitectura maestro-maestro.
●   Contra más sean los hosts implicados, mayor el caos de
    su administración.
                     A→B→C→D→E→A
●   Si el host C se cae (por ejemplo) la replicación se
    rompe. Lo escrito en B no se replica, lo escrito en D se
    replica en todos menos en C, etc.
●   Si se cae por ejemplo B y D, el caos es infinito. La
    solución es salir corriendo.
●   A no ser que no exista otra solución, no se
    recomienda.
                                                                  138
Irontec – Administración de MySQL

                                                           Circular

●   Los logs que reciben los esclavos, deben logearlos en el
    log binario para enviarselo al siguiente en la cadena.
    Esto no es el funcionamiento por defecto, los que se
    recibe como esclavo no se logea. Para cambiarlo:
      –   log­slave­updates
●   En algún momento de la cadena nos llegarán nuestros
    propios logs. Para evitar formar un bucle:
      –   Replicate­same­server­id=0
●   También habrá que tener cuidado con los auto-
    incrementales:
      –   auto_increment_increment=4
      –   auto_increment_offset=1



                                                                  139
Irontec – Administración de MySQL

              Replicación rota




                               140
Irontec – Administración de MySQL

                                                 Replicación rota

●   Es recomendable tener el error-log habilitado, ahí se
    guardará, entre otras cosas, cualquier error relacionado
    con la replicación.
●   ¡EJEMPLO!
Sep 11 11:13:16 test2 mysqld[6776]: 090911 11:13:16 
[ERROR] Slave: Error 'Table 't' already exists' on 
query. Default database: 'mysql'. Query: 'CREATE 
TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE 
utf8_bin)', Error_code: 1050

Sep 11 11:13:16 test2 mysqld[6776]: 090911 11:13:16 
[ERROR] Error running query, slave SQL thread 
aborted. Fix the problem, and restart the slave SQL 
thread with "SLAVE START". We stopped at log 'mysql­
bin.000003' position 421


                                                                  141
Irontec – Administración de MySQL

                                                 Replicación rota

●    Forma rápida y no tan buena de solucionarlo:
●    Decirle al esclavo que ignore esa query y continue con
     la replicación:

    mysql> stop slave; Query OK, 0 rows affected (0.00 
    sec) 

    mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; Query 
    OK, 0 rows affected (0.00 sec) 

    mysql> start slave;




                                                                  142
Irontec – Administración de MySQL

                                                 Replicación rota

●   Forma buena de solucionarlo:
                     http://www.maatkit.org/
●   Maatkit makes MySQL easier to manage.
●   Lo de “easier” ponedlo entre muchas comillas.
●   Son una colección de herramientas que nos puede
    ayudar en la administración de nuestro servidores, y en
    este caso en particular, en rescatar una replicación.
●   Todas las utilidades:
                   http://www.maatkit.org/doc/




                                                                  143
Irontec – Administración de MySQL

                                                   Replicación rota

●    Para saber si dos tables están sincronizadas, podemos
     sacar un checksum de estas y comparar:
       –   mk­table­checksum
●    Para sincronizar los datos de dos tablas:
       –   mk­table­sync


    $ mk­table­checksum h=host1,u=user,p=password h=host2

 $ mk­table­sync –execute 
u=user,p=pass,h=host1,D=db,t=tbl host2




                                                                    144
Irontec – Administración de MySQL

                                                            MMM

●   Cuando ya sabemos que queremos y lo montamos,
    llega el mantenimiento.
●   Si tenemos un cluster de, por ejemplo, 2 maestros y 50
    esclavos, comprobar el correcto funcionamiento es
    complicado.
●   ¿Y si deseamos parar algún esclavo?
●   ¿Y si deseamos parar algún maestro?
●   Es necesario reducir el tiempo de parada de
    servicio al mínimo.




                                                                 145
Irontec – Administración de MySQL

                          MMM




                               146
Irontec – Administración de MySQL

                                                                  MMM

●   También el Perl. El mundo se ha vuelto loco...
●   Características:
      –   Monitorización de la replicación
      –   Monitorización de los hosts
      –   Gestión del failover
      –   Balanceo de IPs entre nodos
      –   Gestión de grupos de escritura/lectura




                                                                       147
Irontec – Administración de MySQL

                                                                 MMM

●   La alta disponibilidad se hace mediante el balanceo de
    Ips virtuales que saltarán de un servidor a otro en caso
    de ser necesario.
      –   Exclusivo: Una única IP para muchos hosts. Si el host que
            la tiene se cae se balancea a otro. Generalmente se usa
            en los nodos de escritura.
      –   Balanceado: Una IP por cada host. Si uno de los hosts se
            cae la IP se balancea a cualquier otro, pasando a tener
            dos IPs virtuales. Se usa para nodos en lectura.




                                                                      148
Irontec – Administración de MySQL

                                                                   MMM

●   Se pueden meter los servidores dentro de dos roles,
    escritura y lectura. Escritura es obligatorio, mientras que
    el de lectura no tiene porque definirse.
●   La diferencia es lógica:
       –   Nodos de escritura son aquellos en los que los datos se
            escribirán.
       –   Nodos de lectura son aquellos de los cuales se leerán
            datos.
●   Escritura (maestro) – Lectura (esclavo)




                                                                        149
Irontec – Administración de MySQL

                                                              MMM

                     http://mysql-mmm.org/
●   En el sistema de control se instalará:
      –   mysql-mmm-common_2.0.10-1_all.deb
      –   mysql-mmm-monitor_2.0.10-1_all.deb
●   En los nodos:
      –   mysql-mmm-common_2.0.10-1_all.deb
      –   mysql-mmm-agent_2.0.10-1_all.deb
●   ¡Junto con todas las dependencias!




                                                                   150
Irontec – Administración de MySQL

                                                             MMM

●   Los ficheros de configuración se guardan en /etc/mysql-
    mmm
●   Todos tendrán un fichero llamado
    mmm_common.conf que será exactamente igual.
●   El nodo de control mmm_mon.conf
●   Los servidores de MySQL mmm_agent.conf




                                                                  151
Irontec – Administración de MySQL

                                                                   MMM

●   mmm_common.conf
●   Incluye la configuración de:
      –   Los Hosts
      –   Sus Ips
      –   Los roles
      –   Usuario/Contraseña del agente
      –   Usuario/Contraseña para la replicación
      –   La interfaz de red en la que se trabaja




                                                                        152
Irontec – Administración de MySQL

                                                                 MMM

●   mmm_mon.conf
●   Incluye la configuración de:
      –   Usuario/Contraseña para la monitorización
      –   Ips a las que pingar
      –   Ruta de los binarios
      –   Ruta del PID
      –   Nivel de debug




                                                                      153
Irontec – Administración de MySQL

                                                                 MMM

●   mmm_agent
●   Incluye la configuración de:
      –   El nombre de este servidor
      –   Todo el mmm_common.conf
      –   Y nada más :P




                                                                      154
Irontec – Administración de MySQL

                                                                     MMM
●    Como hemos visto, hay varios usuarios y contraseñas
     definidos. Hay que crerlos en MySQL.


    GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'10.100.1.%' 
    IDENTIFIED BY 'RepMonitor';

    GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO 
    'mmm_agent'@'10.100.1.%' IDENTIFIED BY 'RepAgent';

    GRANT REPLICATION SLAVE ON *.* TO 'replication'@'10.100.1.%' 
    IDENTIFIED BY 'slave';


        –   El usuario monitor se usa para comprobar el estado de los
               servidores Mysql.
        –   El usuario agent se usa para cambiar el read only mode,
               poner offline un equipo, ejecutar un change_master, etc.
        –   El usuario replication slave... para replicación ;)
                                                                          155
Irontec – Administración de MySQL

                                                                     MMM

●   Una vez puesto en marcha los servicios, se deben
    poner online los servidores desde el comando de
    control.
    MMM:~# mmm_control show
      db1(10.100.1.1) master/AWAITING_RECOVERY. Roles: 
      db2(10.100.1.2) master/AWAITING_RECOVERY. Roles: 
      db3(10.100.1.3) slave/AWAITING_RECOVERY. Roles: 
      db4(10.100.1.4) slave/AWAITING_RECOVERY. Roles:

    MMM:~# mmm_control set_online db1
    OK: State of 'db1' changed to ONLINE. Now you can wait 
    some time and check its new roles!
    MMM:~# mmm_control set_online db2
    OK: State of 'db2' changed to ONLINE. Now you can wait 
    some time and check its new roles!
    MMM:~# mmm_control set_online db3
    OK: State of 'db3' changed to ONLINE. Now you can wait 
    some time and check its new roles!
    MMM:~# mmm_control set_online db4
    OK: State of 'db4' changed to ONLINE. Now you can wait 
    some time and check its new roles!
                                                                          156
Irontec – Administración de MySQL

                                                                   MMM

●   ¡Ejemplo! Parando un servidor en producción:

    MMM:~# mmm_control set_offline db1
    OK: State of 'db1' changed to ADMIN_OFFLINE. Now you can 
    wait some time and check all roles!


    MMM:~# mmm_control show
      db1(10.100.1.1) master/ADMIN_OFFLINE. Roles: 
      db2(10.100.1.2) master/ONLINE. Roles: 
    writer(10.100.1.10)
      db3(10.100.1.3) slave/ONLINE. Roles: reader(10.100.1.12)
      db4(10.100.1.4) slave/ONLINE. Roles: reader(10.100.1.11)




                                                                        157
Irontec – Administración de MySQL

                 MySQL Proxy




                               158
Irontec – Administración de MySQL

                                                     MySQL Proxy

●   El balanceo de carga se puede hacer bien por hardware
    como por software.
●   Existe un software creado para MySQL que nos puede
    “ayudar”.
●   Para que te ayude debes saber LUA.
           http://forge.mysql.com/wiki/MySQL_Proxy
●   Es un proxy que se pone entre el cliente y los servidores
    de MySQL.




                                                                   159
Irontec – Administración de MySQL

                                                    MySQL Proxy

●   Trae scripts de ejemplo, que entre otras cosas te
    permite:
      –   Reescribir queries.
      –   Balanceo de carga.
      –   Loggeo avanzado.
      –   Failover.
      –   Análisis de queries.




                                                                  160
Irontec – Administración de MySQL

                                                       MySQL Proxy

●   La instalación es sencilla, descargamos de:
      –   http://dev.mysql.com/downloads/mysql-proxy/
●   Descomprimimos en:
      –   /usr/local/mysql-proxy
●   Tenemos el binario en bin
●   Tenemos scripts de ejemplo en share/doc/mysql-proxy/




                                                                     161
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion
Mysql Administracion

Weitere ähnliche Inhalte

Was ist angesagt? (8)

MythTV Mediacenter on an IGEPv2
MythTV Mediacenter on an IGEPv2 MythTV Mediacenter on an IGEPv2
MythTV Mediacenter on an IGEPv2
 
El servidor perfecto
El servidor perfectoEl servidor perfecto
El servidor perfecto
 
Qnap LA 2020
Qnap LA 2020Qnap LA 2020
Qnap LA 2020
 
Mysql2
Mysql2Mysql2
Mysql2
 
Introduccion hyper v
Introduccion hyper vIntroduccion hyper v
Introduccion hyper v
 
Nfs, Nis, DHCP
Nfs, Nis, DHCPNfs, Nis, DHCP
Nfs, Nis, DHCP
 
Qnap QuTS Hero
Qnap QuTS Hero Qnap QuTS Hero
Qnap QuTS Hero
 
Consolidacion
ConsolidacionConsolidacion
Consolidacion
 

Ähnlich wie Mysql Administracion

Ähnlich wie Mysql Administracion (20)

Mysq Replication
Mysq ReplicationMysq Replication
Mysq Replication
 
Cluster MySQL en Windows
Cluster MySQL en WindowsCluster MySQL en Windows
Cluster MySQL en Windows
 
Mysql(1)
Mysql(1)Mysql(1)
Mysql(1)
 
Manual my sql Utu atlantida 2015
Manual my sql Utu atlantida 2015Manual my sql Utu atlantida 2015
Manual my sql Utu atlantida 2015
 
MYSQL
MYSQL MYSQL
MYSQL
 
Mysql
MysqlMysql
Mysql
 
Mysql
MysqlMysql
Mysql
 
Dbdeployer
DbdeployerDbdeployer
Dbdeployer
 
Mysql
MysqlMysql
Mysql
 
Manual de mysql
Manual de mysqlManual de mysql
Manual de mysql
 
Rails Against The Machine
Rails Against The MachineRails Against The Machine
Rails Against The Machine
 
Bases de datos distribuidas
Bases de datos distribuidasBases de datos distribuidas
Bases de datos distribuidas
 
Manual de instalacion_my_sql_sergio
Manual de instalacion_my_sql_sergioManual de instalacion_my_sql_sergio
Manual de instalacion_my_sql_sergio
 
Arquitectura sistemas operativos
Arquitectura sistemas operativosArquitectura sistemas operativos
Arquitectura sistemas operativos
 
My Sql Comunity Edition
My Sql Comunity EditionMy Sql Comunity Edition
My Sql Comunity Edition
 
Optimización del rendimiento con MySQL
Optimización del rendimiento con MySQLOptimización del rendimiento con MySQL
Optimización del rendimiento con MySQL
 
Docker y PostgreSQL
Docker y PostgreSQLDocker y PostgreSQL
Docker y PostgreSQL
 
Docker: la revolución en virtualización
Docker: la revolución en virtualizaciónDocker: la revolución en virtualización
Docker: la revolución en virtualización
 
Instalación de MySQL en CentOS 6
Instalación de MySQL en CentOS 6Instalación de MySQL en CentOS 6
Instalación de MySQL en CentOS 6
 
3 3 virtual_box
3 3 virtual_box3 3 virtual_box
3 3 virtual_box
 

Mehr von Irontec

Gestion de proyectos con GitLab en tiempos de teletrabajo
Gestion de proyectos con GitLab en tiempos de teletrabajoGestion de proyectos con GitLab en tiempos de teletrabajo
Gestion de proyectos con GitLab en tiempos de teletrabajoIrontec
 
Sobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIPSobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIPIrontec
 
Presente y futuro del nuevo IVOZ Provider
Presente y futuro del nuevo IVOZ ProviderPresente y futuro del nuevo IVOZ Provider
Presente y futuro del nuevo IVOZ ProviderIrontec
 
Automated Testing para aplicaciones VoIP, WebRTC
Automated Testing para aplicaciones VoIP, WebRTCAutomated Testing para aplicaciones VoIP, WebRTC
Automated Testing para aplicaciones VoIP, WebRTCIrontec
 
Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...
Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...
Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...Irontec
 
LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17
LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17
LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17Irontec
 
IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...
IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...
IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...Irontec
 
Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio
Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / KamailioEscalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio
Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / KamailioIrontec
 
VoIP2DAY 2015 - Workshop comercial ivoz provider
VoIP2DAY 2015 - Workshop comercial ivoz providerVoIP2DAY 2015 - Workshop comercial ivoz provider
VoIP2DAY 2015 - Workshop comercial ivoz providerIrontec
 
Irontec - comunicaciones unificadas en educación - biopen eduka - software li...
Irontec - comunicaciones unificadas en educación - biopen eduka - software li...Irontec - comunicaciones unificadas en educación - biopen eduka - software li...
Irontec - comunicaciones unificadas en educación - biopen eduka - software li...Irontec
 
Comparativa Firewall: IPCop vs. pfSense
Comparativa Firewall: IPCop vs. pfSenseComparativa Firewall: IPCop vs. pfSense
Comparativa Firewall: IPCop vs. pfSenseIrontec
 
Introducción a varnish cache (@irontec)
Introducción a varnish cache (@irontec)Introducción a varnish cache (@irontec)
Introducción a varnish cache (@irontec)Irontec
 
Curso de introducción a Sphinx | Irontec
Curso de introducción a Sphinx | IrontecCurso de introducción a Sphinx | Irontec
Curso de introducción a Sphinx | IrontecIrontec
 
Curso de VoIP / Parte 01: VoIP y Asterisk
Curso de VoIP / Parte 01: VoIP y AsteriskCurso de VoIP / Parte 01: VoIP y Asterisk
Curso de VoIP / Parte 01: VoIP y AsteriskIrontec
 
Curso de VoIP / Parte 03: Dialplan
Curso de VoIP / Parte 03: DialplanCurso de VoIP / Parte 03: Dialplan
Curso de VoIP / Parte 03: DialplanIrontec
 
Curso de VoIP / Parte 02: SIP
Curso de VoIP / Parte 02: SIPCurso de VoIP / Parte 02: SIP
Curso de VoIP / Parte 02: SIPIrontec
 
Curso de VoIP / Parte 04: Conceptos avanzados
Curso de VoIP / Parte 04: Conceptos avanzadosCurso de VoIP / Parte 04: Conceptos avanzados
Curso de VoIP / Parte 04: Conceptos avanzadosIrontec
 
Euskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskera
Euskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskeraEuskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskera
Euskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskeraIrontec
 
Virtualizacion KVM + libvirt + HREL6
Virtualizacion KVM + libvirt + HREL6Virtualizacion KVM + libvirt + HREL6
Virtualizacion KVM + libvirt + HREL6Irontec
 
Irontec - Presentación de servicios de telefonía IP
Irontec - Presentación de servicios de telefonía IPIrontec - Presentación de servicios de telefonía IP
Irontec - Presentación de servicios de telefonía IPIrontec
 

Mehr von Irontec (20)

Gestion de proyectos con GitLab en tiempos de teletrabajo
Gestion de proyectos con GitLab en tiempos de teletrabajoGestion de proyectos con GitLab en tiempos de teletrabajo
Gestion de proyectos con GitLab en tiempos de teletrabajo
 
Sobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIPSobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIP
 
Presente y futuro del nuevo IVOZ Provider
Presente y futuro del nuevo IVOZ ProviderPresente y futuro del nuevo IVOZ Provider
Presente y futuro del nuevo IVOZ Provider
 
Automated Testing para aplicaciones VoIP, WebRTC
Automated Testing para aplicaciones VoIP, WebRTCAutomated Testing para aplicaciones VoIP, WebRTC
Automated Testing para aplicaciones VoIP, WebRTC
 
Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...
Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...
Asterisk: Liberando y generando modelos de negocio en gran cuenta y operador ...
 
LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17
LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17
LA REVOLUCIÓN DEL CLOUD COMPUTING: NUEVA ERA DE DESARROLLO - OpenExpo17
 
IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...
IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...
IVOZ Provider Open Source - La solución VoIP opensource para operadores e int...
 
Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio
Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / KamailioEscalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio
Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio
 
VoIP2DAY 2015 - Workshop comercial ivoz provider
VoIP2DAY 2015 - Workshop comercial ivoz providerVoIP2DAY 2015 - Workshop comercial ivoz provider
VoIP2DAY 2015 - Workshop comercial ivoz provider
 
Irontec - comunicaciones unificadas en educación - biopen eduka - software li...
Irontec - comunicaciones unificadas en educación - biopen eduka - software li...Irontec - comunicaciones unificadas en educación - biopen eduka - software li...
Irontec - comunicaciones unificadas en educación - biopen eduka - software li...
 
Comparativa Firewall: IPCop vs. pfSense
Comparativa Firewall: IPCop vs. pfSenseComparativa Firewall: IPCop vs. pfSense
Comparativa Firewall: IPCop vs. pfSense
 
Introducción a varnish cache (@irontec)
Introducción a varnish cache (@irontec)Introducción a varnish cache (@irontec)
Introducción a varnish cache (@irontec)
 
Curso de introducción a Sphinx | Irontec
Curso de introducción a Sphinx | IrontecCurso de introducción a Sphinx | Irontec
Curso de introducción a Sphinx | Irontec
 
Curso de VoIP / Parte 01: VoIP y Asterisk
Curso de VoIP / Parte 01: VoIP y AsteriskCurso de VoIP / Parte 01: VoIP y Asterisk
Curso de VoIP / Parte 01: VoIP y Asterisk
 
Curso de VoIP / Parte 03: Dialplan
Curso de VoIP / Parte 03: DialplanCurso de VoIP / Parte 03: Dialplan
Curso de VoIP / Parte 03: Dialplan
 
Curso de VoIP / Parte 02: SIP
Curso de VoIP / Parte 02: SIPCurso de VoIP / Parte 02: SIP
Curso de VoIP / Parte 02: SIP
 
Curso de VoIP / Parte 04: Conceptos avanzados
Curso de VoIP / Parte 04: Conceptos avanzadosCurso de VoIP / Parte 04: Conceptos avanzados
Curso de VoIP / Parte 04: Conceptos avanzados
 
Euskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskera
Euskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskeraEuskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskera
Euskera zabaltzeko gure app berriak | Nuestras apps para difundir el euskera
 
Virtualizacion KVM + libvirt + HREL6
Virtualizacion KVM + libvirt + HREL6Virtualizacion KVM + libvirt + HREL6
Virtualizacion KVM + libvirt + HREL6
 
Irontec - Presentación de servicios de telefonía IP
Irontec - Presentación de servicios de telefonía IPIrontec - Presentación de servicios de telefonía IP
Irontec - Presentación de servicios de telefonía IP
 

Kürzlich hochgeladen

Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidaddanik1023m
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...RaymondCode
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfalejandrogomezescoto
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfodalistar77
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....Aaron Betancourt
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfOBr.global
 
Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxPaolaCarolinaCarvaja
 
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETGermán Küber
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfcastrodanna185
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfangelinebocanegra1
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.marianarodriguezc797
 
La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2montoyagabriela340
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx Emialexsolar
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSLincangoKevin
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosLCristinaForchue
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...OLGAMILENAMONTAEZNIO
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfJoseAlejandroPerezBa
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfymiranda2
 

Kürzlich hochgeladen (20)

Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidad
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
 
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura SilvaBEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
 
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier FolchBEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdf
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
 
Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docx
 
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdf
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdf
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.
 
La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx E
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
 

Mysql Administracion

  • 1. Administración MySQL Miguel Ángel Nieto <miguelangel@irontec.com> Irontec – Internet y Sistemas sobre GNU/Linux
  • 2. Irontec – Administración de MySQL Instalación 2
  • 3. Irontec – Administración de MySQL Instalación ● La instalación puede realizarse de las siguientes formas: – Código fuente – Binarios – Sistema de paquetes de tu distribución ● Cada uno tiene sus ventajas e inconvenientes – Código fuente es laborioso, pero te permite definir mejor las carácterísticas de tu servidor, activando y desactivando a tu gusto – Los binarios vienen compilados y son más fáciles de actualizar. Si están compilados con icc se puede casi doblar el rendimiento – Sistema de paquetes, facil de instalar y de actualizar 3
  • 4. Irontec – Administración de MySQL Instalación http://downloads.mysql.com/archives.php ● Para compilar en debian es necesario como mínimo: – apt­get install build­essential libncurses5­dev ● Como siempre ./configure && make && make install – ./configure –help – ./configure –prefix=/usr/local/mysql – ./configure –without­plugin­innodb ● Tenemos que crear los usuarios: – # groupadd mysql – # useradd ­g mysql mysql ● Creamos las bases de datos necesarias para funcionar – # cd scripts – # ./mysql_install_db 4
  • 5. Irontec – Administración de MySQL Instalación ● Damos permisos a la carpeta: – # chown ­R root /usr/local/mysql – # chown ­R mysql /usr/local/mysql/var – # chgrp ­R mysql /usr/local/mysq ● Copiamos el fichero de configuración y lo editamos en caso de que sea necesario: – # cp support­files/my­medium.cnf /etc/my.cnf ● Arrancamos MySQL :) – # /usr/local/mysql/bin/mysqld_safe –user=mysql 5
  • 6. Irontec – Administración de MySQL Instalación ● Los binarios podemos descargarlos de: http://dev.mysql.com/downloads/mysql/ # groupadd mysql # useradd ­g mysql mysql # cd /usr/local # tar ­xzf mysql­VERSION­OS.tar.gz # cd mysql # chown ­R mysql . # chgrp ­R mysql . # scripts/mysql_install_db ­­user=mysql # chown ­R root . # chown ­R mysql data # bin/mysqld_safe ­­user=mysql & 6
  • 7. Irontec – Administración de MySQL Instalación ● En Debian podemos hacer la instalación con apt-get :) ● ¡En cualquiera de los tres modos de instalación es necesario dar una contraseña a root! 7
  • 8. Irontec – Administración de MySQL SandBox ● Para crear una laboratorio de pruebas podemos: – Montar equipos físicos e instalarlos (de locos). – Montar máquinas virtuales. – Usar ¡sandbox! 8
  • 9. Irontec – Administración de MySQL SandBox ● SandBox nos permite: – Montar sistemas de replicación – Probar versiones nuevas de MySQL facilmente – Manejar múltiples instancias de MySQL desde un único punto. – Te olvidas de rmps, sources, debs... ¡tar.gz binario! – Testear – Testear – Testear... 9
  • 10. Irontec – Administración de MySQL SandBox ● No es un producto oficial de MySQL. ● Está escrito el perl (puag!) y aún así funciona bien. http://mysqlsandbox.net/ ● Tendremos que descargar un paquete tar.gz de MySQL y Sandbox. 10
  • 11. Irontec – Administración de MySQL Instalación ● ¡Como root! root@shyris:~# tar ­xzf MySQL­Sandbox­3.0.05.tar.gz root@shyris:~# cd MySQL­Sandbox­3.0.05/ root@shyris:~/MySQL­Sandbox­3.0.05# perl Makefile.PL root@shyris:~/MySQL­Sandbox­3.0.05# make root@shyris:~/MySQL­Sandbox­3.0.05# make test root@shyris:~/MySQL­Sandbox­3.0.05# make install root@shyris:/usr/local/bin# ls low_level_make_sandbox        make_multiple_sandbox     make_sandbox                  make_sandbox_from_source  sb      test_sandbox make_multiple_custom_sandbox  make_replication_sandbox   make_sandbox_from_installed  msandbox                  sbtool  11
  • 12. Irontec – Administración de MySQL Uso de SandBox ● Crear un sandbox con una única instancia de MySQL punisher@shyris:~$ make_sandbox /home/punisher/MySQL/mysql­ 5.0.86­percona­highperf­b19.tar.gz  unpacking /home/punisher/MySQL/mysql­5.0.86­percona­ highperf­b19.tar.gz Executing low_level_make_sandbox  ­­basedir=/home/punisher/MySQL/5.0.86  ­­sandbox_directory=msb_5_0_86  ­­install_version=5.0  ­­sandbox_port=5086  ­­no_ver_after_name  ­­my_clause=log­error=msandbox.err 12
  • 13. Irontec – Administración de MySQL Uso de SandBox ● Parar sandbox: – stop ● Arrancar sandbox: – start ● Utilizar sandbox: – use ● Reiniciar sandbox: – restart ● Limpiar el sandbox: – clean 13
  • 14. Irontec – Administración de MySQL Clientes ● Existen distintos clientes para conectarse a la BBDD ● Clientes de consola – Mysql – Mysqldump – Mysqladmin – Mysqlimport ● Gráficos – Mysql Administrator – Mysql Query Browser – MySQL Workbench ● etc. 14
  • 15. Irontec – Administración de MySQL Clientes ● Mysql: el típico, nos permite conectarse tanto de forma local como remota y ejecutar sentencias SQL ● Mysqldump: permite hacer backups ● Mysqladmin: crear/borrar bases de datos, cambiar contraseñas, ver el estado, variables, parar slaves, etc. ● Mysqlimport “frontend” para “LOAD DATA INFILE” Vienen ya incluidos en MySQL 15
  • 16. Irontec – Administración de MySQL Clientes ● MySQL administrator 16
  • 17. Irontec – Administración de MySQL Clientes ● MySQL Query Browser 17
  • 18. Irontec – Administración de MySQL Clientes ● MySQL Workbench 18
  • 19. Irontec – Administración de MySQL Ficheros de configuración 19
  • 20. Irontec – Administración de MySQL Ficheros de configuración ● Algunos parámetros de configuración se pueden pasar directamente al mysqld – mysqld –basedir /usr/local/mysql ● Otros parámetros que se pueden especificar: – Habilitar/deshabilitar engines – Opciones de rendimiento – Logs – … ● Es más cómodo especificarlo en los ficheros de configuración 20
  • 21. Irontec – Administración de MySQL Ficheros de configuración ● Por defecto busca los ficheros en las siguientes ubicaciones: – /etc/my.cnf – $MYSQL_HOME/my.cnf – ~/.my.cnf ● Se puede añadir un fichero de configuración en el arranque con: – defaults­extra­file 21
  • 22. Irontec – Administración de MySQL Ficheros de configuración ● El fichero se encuentra dividido en distintas secciones, por ejemplo [mysqld], [mysql], [mysqldump] ● Cada opción dentro de una categoría se aplica únicamente a dicha aplicación [mysql] prompt='mysql [h] {u} (d) > ' [mysqld] user                            = punisher port                            = 5140 socket                          =  /tmp/mysql_sandbox5140.sock [mysqldump] quick quote­names max_allowed_packet      = 100M 22
  • 23. Irontec – Administración de MySQL Engines 23
  • 24. Irontec – Administración de MySQL Engines ● MySQL es modular, permite elegir entre diferentes engines para el almacenamiento de datos ● Los engines se aplican a tablas, no a bases de datos ● Puedes tener una base de datos con diferentes engines, dependiendo del tipo de datos o consultas que se hagan 24
  • 25. Irontec – Administración de MySQL Tablas ● Todas las tablas de MySQL tienen ciertas similitudes ● Las tablas tienen .frm como formato. Este fichero guarda la estructura de la tabla ● Independientemente del engine, tendremos un .frm ● A parte, podemos tener otros ficheros acompañando al .frm 25
  • 26. Irontec – Administración de MySQL Engines ● Al crear una tabla se puede indicar el engine: create table t (i INT) ENGINE = MyISAM; ● Una vez que está creada, se puede cambiar el engine: alter table t ENGINE = MyISAM; ● También podemos saber con que engine se ha creado una tabla Show create table t; 26
  • 27. Irontec – Administración de MySQL Engines ● ¿De que engines tenemos soporte? show enginesG mysql [localhost] {msandbox} (mysql) >  *************************** 1. row ***************************       Engine: InnoDB      Support: YES      Comment: Supports transactions, row­level locking, and foreign keys Transactions: YES           XA: YES   Savepoints: YES *************************** 2. row ***************************       Engine: MRG_MYISAM      Support: YES      Comment: Collection of identical MyISAM tables Transactions: NO           XA: NO   Savepoints: NO *************************** 3. row ***************************       Engine: BLACKHOLE      Support: YES      Comment: /dev/null storage engine (anything you write to it disappears) Transactions: NO           XA: NO   Savepoints: NO [...] 27
  • 28. Irontec – Administración de MySQL MyISAM ● MyISAM es el engine por defecto en MySQL ● Si no se indica lo contrario, todas las tablas se crearán con este engine ● Es obligatorio tener soporte para el engine en MySQL, ya que todas las tablas de la BBDD son MyISAM ● La tabla viene definida por tres ficheros: – mitabla.frm – mitabla.MYD – mitabla.MYI 28
  • 29. Irontec – Administración de MySQL MyISAM ● Antes de usar MyISAM hay que conocer bien sus virtudes y defectos :) ● Soporta busquedas FULLTEXT ● Al escribir se hace uso de bloqueo de tabla ● Se puede usar para generar tablas MERGE ● No soporta, transacciones, integridad referencial o claves externas ● Suele ser el más rápido en lecturas ● No tiene cacheo de datos ● Se pueden comprimir tablas para ahorrar espacio http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html 29
  • 30. Irontec – Administración de MySQL MyISAM ● El bloque en MyISAM se hace a nivel de tabla ● No pueden ocurrir deadlocks (dos procesos se quedan esperando a que termine el otro) ● Soporta inserciones concurrentes siempre y cuando la tabla no tenga “agujeros” causados por el borrado de datos (optimize table) ● Las escrituras tienen prioridad sobre las lecturas ● El servidor intenta hacer las escrituras en el orden en que las recibe 30
  • 31. Irontec – Administración de MySQL MyISAM ● Si una tabla se está leyendo y llega una petición de escritura, al escritura tiene que esperar ● Si una tabla se está escribiendo y llega una petición de lectura, la lectura tiene que esperar ● Si hay escrituras pendientes, las lecturas que lleguén tendrán que ponerse a la cola 31
  • 32. Irontec – Administración de MySQL MyISAM ● Las prioridades pueden moficiarse haciendo useo de los schedulers: – LOW PRIORITY: para las querys que escriben datos. La escritura se queda esperando a que terminen todas las lecturas, incluso las que llegan después. Se escribirá cuando no exista ninguna lectura pendiente. – HIGH PRIORITY: para las querys de lectura. Las querys con este modificador se mueven al principio de la cola, por delante de otras escrituras y lecturas – DELAYED: para querys INSERT y REPLACE. El servidor mete en buffer las filas y lo inserta cuando no se esté usando la tabla. Las delayed se insertan en bloques en lugar de una a una aumentando el rendimiento 32
  • 33. Irontec – Administración de MySQL MyISAM ● MyISAM puede almacenar las filas en tres formatos, fixed, dynamic y compressed. ● FIXED – Todas las filas tienen el mismo tamaño – Ocupan más espacio – Se encuentran más rápido ● DYNAMIC – Usa un tamaño variable de datos (menos que fixed) – Las filas no se encuentran tan eficientemente – Puede haber más fragmentación ● COMPRESSED – Ocupan mucho menos espacio – Optimizado para consultas rápidas – Solo lectura 33
  • 34. Irontec – Administración de MySQL MyISAM ● Para conocer el formato en el que se encuetran las filas de una tabla: SHOW TABLE STATUS LIKE 't'G ● Crear tabla FIXED: CREATE TABLE t (c CHAR(50)) ROW_FORMAT= FIXED; ● Crear tabla DYNAMIC: CREATE TABLE t (c CHAR(50)) ROW_FORMAT= DYNAMIC; 34
  • 35. Irontec – Administración de MySQL MyISAM ● Una tabla MyISAM, fixed o dynamic, puede convertirse en tabla comprimida ● Se suelen comprimir aquellas que se usan para datos históricos y que nunca van a ser modificadas ● Son de solo lectura ● Se comprimen con la utilidad myisampack ● Se debe parar el servidor antes de comprimir los datos ● Se descomprimen con myisamchk --unpack 35
  • 36. Irontec – Administración de MySQL MyISAM $ myisampack departments employees departments is too small to compress Compressing employees.MYD: (300024 records) ­ Calculating statistics ­ Compressing file 47.12%      Remember to run myisamchk ­rq on compressed tables $ myisamchk ­rq departments employees ­ check record delete­chain ­ recovering (with sort) MyISAM­table 'departments' Data records: 9 ­ Fixing index 1 ­ Fixing index 2            ­­­­­­­­­ ­ check record delete­chain ­ recovering (with sort) MyISAM­table 'employees' Data records: 300024 ­ Fixing index 1 36
  • 37. Irontec – Administración de MySQL Merge ● Una tabla merge es una colección de distintas tablas con la misma estructura ● Una query en la tabla merge se ejecuta en todas las tablas que la componen ● Puede ayudarnos a superar el tamaño máximo de una tabla MyISAM (256TB) ● Es mas lento, ya que tiene que leer múltiples tablas ● Aumenta el número de descriptores de ficheros abiertos requeridos 37
  • 38. Irontec – Administración de MySQL Merge ● Se suele utilizar para borrar millones de datos en un instante. Gracias a merge podemos borrar la tabla que lo compone en lugar de ir eliminando una a una cada fila mysql> CREATE TABLE A (name varchar(100))  ENGINE=MyISAM; Query OK, 0 rows affected (0.00 sec) mysql> CREATE TABLE B (name varchar(100))  ENGINE=MyISAM; Query OK, 0 rows affected (0.00 sec) mysql> CREATE TABLE TOTAL (name varchar(100))  ENGINE=MERGE UNION=(A,B) INSERT_METHOD=LAST;  Query OK, 0 rows affected (0.01 sec) 38
  • 39. Irontec – Administración de MySQL Merge ● El problema de bloqueo se acentúa más con Merge ● Cuando se bloquea para escritura, se bloquean todas las tablas que contiene ● Cuando se bloquea para lectura, se bloquean todas las tablas que contiene ● Añadir un registro en Merge puede traer como consecuencia el bloqueo de cientos de tablas ● Contra más tablas y mas datos, mas problemas de rendimiento y bloqueos 39
  • 40. Irontec – Administración de MySQL Memory ● Es una tabla en memoria, lo cual ya nos da sus pros y contras solo con el nombre – Es muy muy rápida – Los datos no se guardan después del reinicio del servidor – Usan la memoria RAM, por lo que no debe usarse para tablas grandes – Usa bloqueo a nivel de tablas – No puede tener columnas TEXT o BLOB 40
  • 41. Irontec – Administración de MySQL Memory ● Soporta dos típos de índices, HASH y BTREE: – HASH: memory las usa por defecto. El algoritmo es muy rápido para comparaciones que usen índices únicos. Pero solo se puede usar para comparaciones = o <=> – BTREE: es preferible para índices que se usarán con comparaciones disintas a las anteriores. Por ejemplo: id<1024 or id BETWEEN 4000 and 5000 CREATE TABLE T (i int) ENGINE=MEMORY; 41
  • 42. Irontec – Administración de MySQL Federated ● Te permite usar tablas de otro servidores MySQL remotos ● De esta forma el cliente no debe conectarse a otros servidores para acceder a los datos ● Al estar en un servidor remoto, las federated no soportan el bloqueo de tablas CREATE TABLE federated_table (     id     INT(20) NOT NULL AUTO_INCREMENT,     name   VARCHAR(32) NOT NULL DEFAULT '',     other  INT(20) NOT NULL DEFAULT '0',     PRIMARY KEY  (id),     INDEX name (name),     INDEX other_key (other) ) ENGINE=FEDERATED DEFAULT CHARSET=latin1 CONNECTION='mysql://fed_user@remote_host:9306/federated/tes t_table'; 42
  • 43. Irontec – Administración de MySQL Federated ● Los engines que se conectan a un servidor externo para coger datos (como FEDERATED, NDB o SPIDER) tienen un funcionamiento poco optimo cuando las querys tienen condiciones ● En estos engines, la condición no se envia junto con la petición, por lo tanto el servidor remoto nos transmite TODAS las filas de la tabla para que nuestro MySQL local haga la búsqueda ● Para solucionarlo se debe implementar “CONDITION PUSHDOWN” ya sea mediante un parche o plugin ● Dependiendo del engine tendremos diferentes soluciones (o en algunos casos ninguna) 43
  • 44. Irontec – Administración de MySQL InnoDB ● InnoDB nos ofrece todo aquello de lo que MyISAM carece – Claves externas – Integridad referencial – Bloqueo de filas en lugar de tablas – Auto recuperación ante errores – Transacciones y rollbacks – Cacheo de índices y datos – Etc... http://dev.mysql.com/doc/refman/5.1/en/innodb.html 44
  • 45. Irontec – Administración de MySQL InnoDB ● ¿Y que perdemos al pasarnos a InnoDB? – Capacides de busqueda FULLTEXT – La posibilidad de comprimir las tablas – No poder hacer uso de Merge – “Sólo” 64 TB de datos por tabla 45
  • 46. Irontec – Administración de MySQL InnoDB ● InnoDB es un engine que cumple las características ACID: – Atomic: O todas las sentencias se ejectuan correctamente o se cancelan. – Consistent: Es consistente cuando una transacción que comienza la deja en estado consistente al terminar. – Isolated: Una transacción no afecta a las demás. – Durable: Todos los cambios efectuados por una transacción se graban. No se pierden datos. 46
  • 47. Irontec – Administración de MySQL InnoDB ● Cuando se producen múltiples transacciones que afectan a los mismos datos, pueden darse los siguientes problemas: – Dirty read: es una lectura de una transacción de datos no commiteados realizados por otra. ¡Si finalmente esta última no hace el commit, lo que hemos leido no sirve! – Non-repeatable: ocurre cuando una transacción realiza la misma petición de datos dos veces recibiendo resultados distintos – Phantom: ocurre cuando aparece una fila que no era visible en la query, ya que otra transacción la ha incluido durante el proceso de lectura 47
  • 48. Irontec – Administración de MySQL InnoDB ● InnoDB dispone de 4 niveles de aislamiento: – READ UNCOMMITED: permite a una transacción ver los datos sin commitear de otra. Se pueden dar non- repeatable reads, phantoms y dirty reads – READ COMMITED: permite ver cambios de otras transacciones solo si están commiteados. Se pueden dar non-repeatable reads y phantoms – REPETABLE READ: asegura que la misma SELECT ejecutada dos veces de los mismos valores. Las filas modificadas por una transacción no puden ser modificadas por otras. Se pueden dar phantoms – SERIALIZE: separa completamente los efectos de unas transacciones sobre otras con la restricción de que las filas seleccionadas por una transacción no pueden ser accedidas por otras 48
  • 49. Irontec – Administración de MySQL InnoDB ● Por defecto InnoDB utiliza REPEATABLE READ para ser full ACID ● Para cambiar de uno a otro aislamiento de: [mysqld] Transaction­isolation = READ­COMMITED 49
  • 50. Irontec – Administración de MySQL InnoDB ● InnoDB implementa la concurrencia en las transacciones siguiendo el modelo MVCC (multiversion concurrency control) ● Permite que cada transacción tenga una visión única de los datos (un snapshot) para tener una vista consistente con el paso del tiempo, sin tener en cuenta las modificaciones de otras transacciones ● Esto puede permitir que distintas transacciones vean datos diferentes de la misma tabla en un mismo momento ● Gracias a esto evitamos tener que bloquear siempre las filas. Menos overhead y más operaciones concurrentes ● En lecturas casi nunca se bloquearán las filas 50
  • 51. Irontec – Administración de MySQL InnoDB ● MVCC funciona añadiendo a cada fila dos valores adicionales que indican cuando fué creada y cuando fué eliminada ● Con esto InnoDB se asegura que al iniciar una transacción... – La fila existía antes de iniciar la transacción – La fila no fué eliminada antes de iniciar la transacción ● Con cada actualización de la fila, la transacción actualiza los valores asociados ● El multiversioning se utiliza con: – REPETABLE READ – READ COMMITED 51
  • 52. Irontec – Administración de MySQL InnoDB ● Por defecto InnoDB viene habilitado con autocommit, cada query se commitea al instante ● Esto no nos permite hacer rollback ni agrupar querys en batch para mejorar el rendimiento ● ¿Y como desactivo el autocommit? – SET AUTOCOMIT = 0; – START TRANSACTION; COMMIT; ● Para habilitar el rollback podemos añadir un SAVEPOINT – SAVEPOINT nombre; – ROLLBACK TO SAVEPOINT nombre; 52
  • 53. Irontec – Administración de MySQL Mantenimiento de tablas 53
  • 54. Irontec – Administración de MySQL Mantenimiento de tablas ● Existen una serie de comandos que nos ayudar al mantenimiento de las tablas ● Algunos son tienen utilidad en unos engines pero no en otros ● Podemos: – Chequear – Reparar – Analizar – Optimizar 54
  • 55. Irontec – Administración de MySQL Mantenimiento de tablas ● CHECK TABLE – Realizar un chequeo de integridad tanto de la estructura como del contenido de los datos – Funciona tanto en MyISAM como InnoDB – En MyISAM además actualiza las estadísticas de los índices ● Su uso es el siguiente: mysql > check table A; +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | Table     | Op    | Msg_type | Msg_text | +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | pruebas.A | check | status   | OK       | +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ 1 row in set (0.00 sec) 55
  • 56. Irontec – Administración de MySQL Mantenimiento de tablas ● REPAIR TABLE – Repara los errores que se puedan encontrar en una tabla – Solo funciona con MyISAM – Se puede habilitar el auto-reparado de tablas [mysqld] myisam­recover=[Opciones] ­ Default: opciones por defecto ­ Backup: hace backup de las tablas que tenga que  cambiar ­ Force: fuerza la reparación aunque se puedan  perder datos ­ Quick: las tablas no fragmentadas se evitan 56
  • 57. Irontec – Administración de MySQL Mantenimiento de tablas ● Reparación en caliente mysql > repair table A; +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | Table     | Op    | Msg_type | Msg_text | +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | pruebas.A | repair| status   | OK       | +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ 1 row in set (0.00 sec) 57
  • 58. Irontec – Administración de MySQL Mantenimiento de tablas ● ANALYZE TABLE – Actualiza las tablas con información acerca de la distribución de los valores de las claves en la tabla – Esta información la usa el optimizador para elegir el mejor plan de ejecución – Solo funciona en MyISAM mysql > analyze table A; +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | Table     | Op    | Msg_type | Msg_text | +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | pruebas.A |analyze| status   | OK       | +­­­­­­­­­­­+­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ 1 row in set (0.00 sec) 58
  • 59. Irontec – Administración de MySQL Mantenimiento de tablas ● OPTIMIZE TABLE – Desfragmenta las tablas MyISAM, eliminando los huecos generados por múltiples updates y deletes – Actualiza las estadísticas de los índices – Se puede utilizar en InnoDB, pero no desfragmenta (ya que InnoDB no se fragmenta) Actualiza las estadísticas de índices y libera espacio relacionado con índices mysql > optimize table A; +­­­­­­­­­­­+­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | Table     | Op     | Msg_type | Msg_text | +­­­­­­­­­­­+­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ | pruebas.A |optimize| status   | OK       | +­­­­­­­­­­­+­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­+ 1 row in set (0.00 sec) 59
  • 60. Irontec – Administración de MySQL Mantenimiento de tablas ● Existen herramientas externas de consola que también nos pueden ayudar con el mantenimiento – mysqlcheck – myisamchk ● Mysqlcheck envía las sentencias SQL necesarias para el mantenimiento. Por lo tanto, mysqld debe estár en funcionamiento ● Myisamchk no necesita de un servidor en funcionamiento, puede actuar directamente contra las tablas en el sistema de ficheros 60
  • 61. Irontec – Administración de MySQL Mantenimiento de tablas ● Mysqlcheck nos ofrece alguna ventaja al uso de las sentencias SQL directamente – Podemos indicarle una BBDD para que haga operaciones de mantenimiento en todas sus tablas en lugar de indicar una a una – Al ser un comando de consola, se puede crear una tarea programada ● Ejemplo: – Mysqlcheck test (chequea BBDD test) – Mysqlcheck test A (chequea tabla A de la BBDD test) – Mysqlcheck –all-databases (chequea todo) – --check, --repair, --analyze, --optimize 61
  • 62. Irontec – Administración de MySQL Mantenimiento de tablas ● Myisamchk permite realizar las mismas tareas que mysqlcheck ● Se debe hacer offline, con mysqld apagado ● Actua directamente sobre las tablas ● Es el último recurso cuando ni siquiera el servidor arranca (por ejemplo, tablas en la BBDD mysql corruptas) ● Como el propio nombre indica, solo funciona con tablas MyISAM 62
  • 63. Irontec – Administración de MySQL Usuarios y permisos 63
  • 64. Irontec – Administración de MySQL Usuarios y permisos ● MySQL permite definir usuarios y decidir que pueden hacer ● Los usuarios siguen el siguiente formato: – 'usuario'@'host' ● No es lo mismo irontec@localhost que irontec@10.10.0.210 ● La primera parte es el nombre de usuario con el que haremos login, mientras que la segunda será la IP desde la cual nos conectamos 64
  • 65. Irontec – Administración de MySQL Usuarios y permisos ● Se puede crear un usuario que se conecta desde cualquier ubicación: – 'irontec'@'%' ● Los usuarios y permisos se guardan dentro de las tablas user y grant de la BBDD mysql ● Es posible insertar datos directamente mediante la consola de mysql, pero también es más lioso ● ¡No debe existir nunca un 'root'@'%', por seguridad! 65
  • 66. Irontec – Administración de MySQL Usuarios y permisos ● Para ver todos los permisos disponibles y una descripción: mysql > show privileges; ● Nos muestra tres columnas: – Privilege: es el nombre del permiso – Context: contexto en el cual es posible aplicar el permiso – Comment: breve explicación 66
  • 67. Irontec – Administración de MySQL Usuarios y permisos ● Permisos especiales: – ALL y ALL PRIVILEGES da todos los permisos excepto GRANT OPTION – USAGE no da ningún privilegio excepto el de conexión 67
  • 68. Irontec – Administración de MySQL Usuarios y permisos ● Los permisos pueden aplicarse en diferentes contextos: – Server – Databases – Tables – Functions – Procedures – Indexes – File Access ● Por ejemplo, no puedes dar permisos FILE a un usuario sobre una tabla, es un permiso global o CREATE ROUTINE a nivel de índice ● Todos pueden aplicarse globalmente 68
  • 69. Irontec – Administración de MySQL Usuarios y permisos ● Para crear un usuario se debe indicar tanto el usuario como el host y su contraseña (no obligatorio): mysql > create user 'irontec'@'localhost'  IDENTIFIED BY '1234'; ● Borrar un usuario: mysql > drop user 'irontec'@'localhost'; ● Renombrar un usuario: mysql > rename user 'irontec'@'localhost' TO  'miguelangel'@'localhost'; 69
  • 70. Irontec – Administración de MySQL Usuarios y permisos ● Para cambiar una contraseña hay distintas formas: – Para un usuario en particular: mysql > SET PASSWORD for 'miguel'@'localhost' =  PASSWORD('nueva'); – Para tu usuario: mysql > SET PASSWORD = PASSWORD('nueva'); – Mediante GRANT: mysql > GRANT USAGE ON *.* TO  'miguel'@'localhost' IDENTIFIED BY 'nueva'; 70
  • 71. Irontec – Administración de MySQL Usuarios y permisos ● Para dar permisos se usa GRANT ● Importante: si el usuario al que damos permisos no existe, lo crea mysql > GRANT SELECT ON mysql.* TO  'miguel'@'localhost' IDENTIFIED BY 'test'; ● Se pueden indicar múltiples permisos separándolos por comas ● Para aplicar a distintos contextos: – ON *.* – ON db.* – ON db.table – ON db.routine 71
  • 72. Irontec – Administración de MySQL Usuarios y permisos ● Para eliminar un permiso haremos uso de REVOKE: mysql > REVOKE SELECT ON mysql.* FROM  'miguel'@'localhost'; ● El usuario seguirá existiendo, pero sin el permiso indicado mysql > show grants for 'miguel'@'localhost'; ● Si le borramos el último permiso, USAGE, no se podrá conectar 72
  • 73. Irontec – Administración de MySQL Optimización de querys 73
  • 74. Irontec – Administración de MySQL Optimización de querys ● Hay que tener especial cuidado con las querys que se lanzan a una base de datos ● Si está mal construida puede degradar el rendimiento del servicio ● Es necesario detectar estas querys y reescribirlas completamente ● EXPLAIN nos ayudará a saber como se comportar internamente una query y cuales son sus deficiencias 74
  • 75. Irontec – Administración de MySQL Optimización de querys ● En primer lugar debemos detectar cuales son esas querys ● Para ello nos ayudaremos del log-slow ● En este log se irán escribiendo las sentencias SQL que tarden un tiempo superior al que le indiquemos ● Su activación no afecta al rendimiento como otros logs – log­slow­queries=/var/log/mysql/slow­querys.log – long_query_time=5 – Log­queries­not­using­indexes ● Log de querys lentas (superior a 5 segundos) así como querys sin índices :) 75
  • 76. Irontec – Administración de MySQL Optimización de querys ● El log puede crecer con el tiempo y leerlo con un editor de textos convertirse en un infierno ● No es necesario hacerte tu propio script, ya existen utilidades para dumpearlo /var/log/mysql# mysqldumpslow mysql­slow.log ● Nos resumirá las querys lentas 76
  • 77. Irontec – Administración de MySQL Optimización de querys ● ¿Cómo se ve en el log? /var/log/mysql# cat mysql­slow.log # Query_time: 4.00s  Lock_time: 0  Rows_sent: 0   Rows_examined: 1380 SELECT * FROM foobar WHERE id="foo"; # Query_time: 2.50s  Lock_time: 0  Rows_sent: 0   Rows_examined: 1380 SELECT * FROM foobar WHERE id="bar"; 77
  • 78. Irontec – Administración de MySQL Optimización de querys ● Ejemplo de mysqldumpslow: /var/log/mysql# mysqldumpslow mysql­slow.log Count: 2  Time=4s (6.50s)  Lock=0.00s (0s)   Rows=1380 (2760) SELECT * FROM foobar WHERE id='S'; 78
  • 79. Irontec – Administración de MySQL Optimización de querys ● Ya tenemos identificadas las querys lentas, ahora es necesario estudiarlas – Mysql > explain [extended] SELECT [opciones] ● Basicamente nos mostrará información del plan de ejecución del optimizador ● Sólo funciona con SELECT 79
  • 80. Irontec – Administración de MySQL Optimización de querys ● Problema: explain SELECT * from City where  CountryCode='ESP'G *************************** 1. row  ***************************            id: 1   select_type: SIMPLE         table: City          type: ALL possible_keys: NULL           key: NULL       key_len: NULL           ref: NULL          rows: 4079         Extra: Using where 1 row in set (0.00 sec) 80
  • 81. Irontec – Administración de MySQL Optimización de querys ● ID: identificador de la query, en caso de tener subquerys ● select_type: el tipo de select. Simple, primary, derived, union, subquery ● table: indica el nombre de la tabla utilizada ● type: tipo de acceso para la query. system/const, eq_ref, ref, ref_or_null, index_merge, range, index, ALL ● possible_keys: lista de índices disponibles para usar ● key: índice utilizado ● key_len: número de bytes utilizados del índice ● rows: número de filas a leer ● extra: información extra de la query 81
  • 82. Irontec – Administración de MySQL Optimización de querys ● Type: – system: la tabla tiene una única fila – const: la tabla tiene una única fila coincidente con la query – eq_ref: la busqueda por índices da una única fila – ref: similar a eq_ref pero puede devolver más de una fila – ref_or_null: igual que los anteriores, pero también busca valores NULL – index_merge: el único tipo de acceso que usa dos índices – range: busqueda por rango – index: busqueda completa por la tabla, pero de índices en lugar de los datos – ALL: escaneo completo de la tabla. MAL 82
  • 83. Irontec – Administración de MySQL Optimización de querys ● Extra: – Using index: se está usando un index, cogiendo el dato del índice en lugar de la tabla – Using filesort: se ordenan las filas de forma manual en lugar de usar índices – Using temporary: se ha usado una tabla temporal (en RAM o disco) para realizar la consulta – Using where: el filtrado se hace fuera del engine 83
  • 84. Irontec – Administración de MySQL Optimización de querys ● Volvemos al problema :) explain SELECT * from City where  CountryCode='ESP'G *************************** 1. row  ***************************            id: 1   select_type: SIMPLE         table: City          type: ALL possible_keys: NULL           key: NULL       key_len: NULL           ref: NULL          rows: 4079         Extra: Using where 1 row in set (0.00 sec) 84
  • 85. Irontec – Administración de MySQL Optimización de querys ● El optimizador no encuentra índices ● Al no encontrar... no puede usar ● Como no hay índices, el tipo de búsqueda es ALL, se lee todas las filas ● ¿Como podríamos mejorarlo? – Añadiendo índices – Optimizar la query añadiendo más detalles ● Después de cada cambio hay que comprobar si existe mejora 85
  • 86. Irontec – Administración de MySQL Optimización de querys ● Añadiendo un índice: – Mysql>alter table City add index(CountryCode); Query OK, 4079 rows affected (0.02 sec) Records: 4079  Duplicates: 0  Warnings: 0 ● Ejecutamos de nuevo la query con explain:            id: 1   select_type: SIMPLE         table: City          type: ref possible_keys: CountryCode           key: CountryCode       key_len: 3           ref: const          rows: 58         Extra: Using where 1 row in set (0.00 sec) 86
  • 87. Irontec – Administración de MySQL Optimización de querys ● Modificamos la query añadiendo más datos, haciéndola más concisa: – explain SELECT * from City where  CountryCode='ESP' and District='Madrid'; – alter table City add index(District);            id: 1   select_type: SIMPLE         table: City          type: index_merge possible_keys: CountryCode,District           key: District,CountryCode       key_len: 20,3           ref: NULL          rows: 1         Extra: Using intersect(District,CountryCode);  Using where 1 row in set (0.00 sec) 87
  • 88. Irontec – Administración de MySQL Optimización de la base de datos 88
  • 89. Irontec – Administración de MySQL Optimización de la base de datos ● Cuando nos referimos a optimizar la base de datos, esto implica en primer lugar optimizar el servidor – RAM: contra más RAM, más índices y datos en memoria, por lo tanto más velocidad de respuesta – CPU: nunca sobra la CPU y los cores ;) – Disco duro: contra más rápido mejor. Últimamente se estan empezando a usar disco SSD para bases de datos ● Una vez que tenemos el mejor equipo que podamos comprar, tocará optimizar la base de datos de acuerdo a dicho hardware 89
  • 90. Irontec – Administración de MySQL Optimización de la base de datos ● ¿32 o 64 bits? ● Siempre que sea posible es recomendable 64 bits ● En sistemas GNU/Linux y Solaris de 32 bits, un solo proceso no puede usar más de 2GB. Por lo tanto da igual que tengamos 4, MySQL usará la mitad ● En algunos sistemas, según un parámetro de configuración del kernel, puede disponer de 3 GB, pero puede ser insuficiente ● En 64 bits no existe esa limitación ● Si tienes 32 bits, no configures MySQL para que use mas de 2GB, tendrás errores de falta de memoria memory=key_buffer+(sort_buffer_size+read_buffer_size)*max_connections 90
  • 91. Irontec – Administración de MySQL Optimización de la base de datos ● Las optimizaciones también dependerán mucho del tipo de querys que ejecutemos ● Para tener una estadística mysql> show status like 'Com%'; 91
  • 92. Irontec – Administración de MySQL Optimización de la base de datos ● Número máximo de conexiones (max_connections) – Son el número máximo de conexiones simultaneas que soportará el servidor – Cada conexión en espera consume memoria – Se debe ajustar a un número no muy superior a la media de nuestro servidor mysql> show status like '%connections%'; +­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­+ | Variable_name        | Value   | +­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­+ | Connections          | 4651724 |  | Max_used_connections | 41      |  +­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­+ 2 rows in set (0.01 sec) 92
  • 93. Irontec – Administración de MySQL Optimización de la base de datos ● Cache de tablas (table_cache) – Cada vez que mysql abre una tabla mantiene en cache información sobre ella para evitar reabrirlas – Si se abren muchas y un usuario necesita abrir otra nueva, una de las ya abiertas debe cerrarse – No vale poner millones y millones, estamos limitados por los descriptores del sistema operativo ● Si Open_tables está cercano a Table_cache y Opened_tables no para de aumentar, toca subir el table_cache mysql> show status like 'Open%tables%'; +­­­­­­­­­­­­­­­+­­­­­­­+ | Variable_name | Value | +­­­­­­­­­­­­­­­+­­­­­­­+ | Open_tables   | 1551  |  | Opened_tables | 0     |  +­­­­­­­­­­­­­­­+­­­­­­­+ 2 rows in set (0.02 sec) 93
  • 94. Irontec – Administración de MySQL Optimización de la base de datos ● Cacheo de índices en MyISAM (key_buffer_size) – Cachea los índices que lee de una tabla MyISAM – Permite reutilizar los índices en lugar de leerlos continuamente, más rendimiento – Para calcularlo: Ratio de fallo: Key_reads / Key_read_requests Eficiencia: 1 – (Key_reads / Key_read_requests) – Los fallos tienen que estar lo más cerca posible de 0 y eficiencia de 1 mysql> show status like 'Key_read%'; +­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+ | Variable_name     | Value     | +­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+ | Key_read_requests | 150683856 |  | Key_reads         | 325197    |  +­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+ 2 rows in set (0.01 sec) 94
  • 95. Irontec – Administración de MySQL Optimización de la base de datos ● Buffer de InnoDB (innodb_buffer_pool_size) – Cache tanto los índices como los datos de una tabla InnoDB – El valor por defecto es 8 megas, pero se recomienda entre el 50% y 80% de la memoria total del sistema mysql> show variables like  'innodb_buffer_pool_size'; +­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+ | Variable_name           | Value     | +­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+ | innodb_buffer_pool_size | 838860800 |  +­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+ 1 row in set (0.00 sec) 95
  • 96. Irontec – Administración de MySQL Optimización de la base de datos ● Cacheo de querys (query_cache_size) – Nos permite almacenar en cache el resultado de una query select – La cache solo se mantiene mientras los datos de la tabla no se modifiquen ● query_cache_type: OFF desactivado, ON activado, DEMAND solo para SELECT SQL_CACHE ● query_cache_size: 0 es desactivado ● query_cache_limit: el tamaño máximo de una query que se puede almacenar 96
  • 97. Irontec – Administración de MySQL Optimización de la base de datos ● Midiendo la efectividad de la cache: – Qcache_hits: numero de querys que no se han ejecutado por estar en cache – Qcache_inserts: el número total de querys guardadas en la cache – Qcache_lowmem_prunes: número de caches eliminadas por falta de memoria ● Si hits es bajo e inserts alto... hay que aumentar la caché 97
  • 98. Irontec – Administración de MySQL Optimización de la base de datos ● Otros valores: – read_buffer_size: cuando se lee una tabla lo leerá en bloques del tamaño que aquí indiquemos. Contra mas grande, más rápido la leerá – read_rnd_buffer_size: por defecto coge el valor del anterior. Se usa para lecturas no secuenciales (como las requeridas por ORDER BY) – sort_buffer_size: para las operaciones con ORDER o GROUP BY – join_buffer_size: para querys con joins 98
  • 99. Irontec – Administración de MySQL Optimización de tablas 99
  • 100. Irontec – Administración de MySQL Optimización de tablas ● Si las tablas aumentan mucho puede llegar un momento en el que los índices ocupen más que la propia RAM del sistema ÍNDICES RAM 100
  • 101. Irontec – Administración de MySQL Optimización de tablas ● ¡Particionemos! 101
  • 102. Irontec – Administración de MySQL Optimización de tablas ● Si no queremos comprar más RAM, los índices se vuelven lentos ● Particionar se vuelve más rápido que los índices ● Será nuestra salvación cuando: – Nos quedemos sin RAM – Tenemos muchísimos datos – Guardamos datos históricos – Rotamos datos – Datos crecientes Es transparente, no tendremos que modificar las aplicaciones 102
  • 103. Irontec – Administración de MySQL Optimización de tablas ● Cosas a tener en cuenta antes de particionar: – La columna que utilicemos para definir el rango de las particiones debe ser un INT, no se acepta cualquier otro valor – Si tenemos una clave única o una primary key, esta debe usarse para particionar – Como máximo se permiten 1024 particiones – No se permiten claves externas – No se permiten búsquedas FULL TEXT 103
  • 104. Irontec – Administración de MySQL Optimización de tablas ● El particionado se puede hacer: – Por rango: es el más sencillo, se divide en base a rangos – Por listas: se divide en particiones en base a una lista de posibles valores – Por hash: nos permite dividir los datos de forma equitativa entre todas las particiones. La expresión por la que separar los datos debe devolver un entero – Por key: similar a hash. En lugar de indicar nosotros el valor del hash, lo hace el propio MySQL con md5 y password(). Pueden usarse columnas que no sean entero 104
  • 105. Irontec – Administración de MySQL Optimización de tablas CREATE TABLE employees (     id INT NOT NULL,     fname VARCHAR(30),     lname VARCHAR(30),     hired DATE NOT NULL DEFAULT '1970­01­01',     separated DATE NOT NULL DEFAULT '9999­12­ 31',     job_code INT NOT NULL,     store_id INT NOT NULL ) PARTITION BY RANGE (store_id) (     PARTITION p0 VALUES LESS THAN (6),     PARTITION p1 VALUES LESS THAN (11),     PARTITION p2 VALUES LESS THAN (16),     PARTITION p3 VALUES LESS THAN (21),     PARTITION p3 VALUES LESS THAN MAXVALUE ); 105
  • 106. Irontec – Administración de MySQL Optimización de tablas CREATE TABLE employees (     id INT NOT NULL,     fname VARCHAR(30),     lname VARCHAR(30),     hired DATE NOT NULL DEFAULT '1970­01­01',     separated DATE NOT NULL DEFAULT '9999­12­ 31',     job_code INT,     store_id INT ) PARTITION BY LIST(store_id) (     PARTITION pNorth VALUES IN (3,5,6,9,17),     PARTITION pEast VALUES IN  (1,2,10,11,19,20),     PARTITION pWest VALUES IN  (4,12,13,14,18),     PARTITION pCentral VALUES IN (7,8,15,16) ); 106
  • 107. Irontec – Administración de MySQL Optimización de tablas CREATE TABLE employees (     id INT NOT NULL,     fname VARCHAR(30),     lname VARCHAR(30),     hired DATE NOT NULL DEFAULT '1970­01­ 01',     separated DATE NOT NULL DEFAULT  '9999­12­31',     job_code INT,     store_id INT ) PARTITION BY HASH( YEAR(hired) ) PARTITIONS 4; 107
  • 108. Irontec – Administración de MySQL Optimización de tablas CREATE TABLE Employee (     emp_id INT,     fname VARCHAR(50),     lname VARCHAR(50),     store_id TINYINT   ) ENGINE=MyISAM   PARTITION BY KEY (lname)   PARTITIONS 4; 108
  • 109. Irontec – Administración de MySQL Optimización de tablas ● Existe un script que nos permite crearnos la query de creación de particiones http://forge.mysql.com/wiki/Partition_Helper ./partitions_helper ­­table=mytable ­­column=d  ­interval=year ­­start=2004­01­01 –end=2009­01­01 ./partitions_helper ­­table=mytable ­­column=d  ­­interval=month ­­start=2008­01­01 ­­end=2009­01­01 ./partitions_helper ­­table=mytable –column=prod_id  ­­interval=1000 ­­start=1 –end=10000 109
  • 110. Irontec – Administración de MySQL Optimización de tablas ● Para comprobar si las particiones funcionan y en que partición se encuentran nuestros datos: mysql [localhost] {msandbox} (employees) > explain  partitions select count(*) from salaries where from_date between '2000­01­01' and '2000­12­31'G *************************** 1. row  ***************************            id: 1   select_type: SIMPLE         table: salaries    partitions: p016          type: index possible_keys: NULL           key: emp_no       key_len: 4           ref: NULL          rows: 2830488         Extra: Using where; Using index 1 row in set (0.00 sec) 110
  • 111. Irontec – Administración de MySQL Optimización de tablas ● Mantenimiento de tablas RANGE y LIST – Se pueden añadir más particiones ALTER TABLE gente ADD PARTITION (PARTITION p4 VALUES  LESS THAN (2010)); – Se pueden eliminar particiones (borra datos) ALTER TABLE gente DROP PARTITION p4 – Se reorganizar particiones ALTER TABLE gente REORGANIZE PARTITION p0 INTO (     PARTITION s0 VALUES LESS THAN (1960),     PARTITION s1 VALUES LESS THAN (1970) ); 111
  • 112. Irontec – Administración de MySQL Optimización de tablas ● Mantenimiento de tablas HASH y KEY – Se pueden añadir más particiones ALTER TABLE gente ADD PARTITION PARTITIONS 2; – Se pueden reducir el número de particiones, DROP no funciona ALTER TABLE gente COALESCALE PARTITION 2; ● Las particiones HASH o KEY se auto reorganizan según añadamos o eliminemos particiones 112
  • 113. Irontec – Administración de MySQL Optimización de tablas ● Reconstruir partición: – Borrar los datos de la partición para volver a insertarlos. De esta forma solucionas el problema de fragmentado ● Optimizar partición: – Otra forma de solucionar la fragmentación. Reclama el espacio libre y reorganiza los datos ● Analizar partición: – Lee y almacena la distribución de índices ● Reparar partición: – Repara particiones corruptas ● Chequear partición: – Chequea una partición en busca de errores 113
  • 114. Irontec – Administración de MySQL Optimización de tablas ALTER TABLE gente REBUILD PARTITION p1; ALTER TABLE gente OPTIMIZE PARTITION p1; ALTER TABLE gente ANALYZE PARTITION p1; ALTER TABLE gente REPAIR PARTITION p1; ALTER TABLE gente CHECK PARTITION p1; 114
  • 115. Irontec – Administración de MySQL Logs 115
  • 116. Irontec – Administración de MySQL Logs ● En MySQL tenemos 3 tipos de logs – Slow: guardan las querys lentas – Sql: guarda todas las querys que se ha recibido el servidor – Binlog: guarda únicamente las querys que modifican datos ● ¿Para que nos pueden servir? – Arreglar querys lentas o sin índices – Debuggear a nivel SQL nuestra aplicación – Replicación o recuperación de backup 116
  • 117. Irontec – Administración de MySQL Logs ● Slow Logs: – Goto 75 117
  • 118. Irontec – Administración de MySQL Logs ● SQL log almacena todas las querys que llegan a nuestro servidor ● Se puede usar para debuggear nuestra aplicación antes de pasarla a producción ● En producción no es recomendable tenerlo habilitado, consume muchos recusos tanto de CPU como de disco duro ● Si este log está activado, el logrotate debe estar habilitado log=/var/log/mysql/mysql.log 118
  • 119. Irontec – Administración de MySQL Logs ● Los logs binarios almacenan los cambios que se realizan en la BBDD (update, insert, delete, alter, etc.) ● Nos sirven para: – Recuperación de backup – Replicación ● Es recomendable tenerlos habilitados, no consumen mucho y nos pueden salvar la vida ● En caso de replicación es obligatorio tenerlos habilitados 119
  • 120. Irontec – Administración de MySQL Logs ● Otras opciones: – max_binlog_size (por defecto y máximo 1 GB) – expire_logs_days – sync_binlog (>0) – replicate-do-db – replicate-ignore-db – binlog-do-db – binlog-ignore-db – replicate-do-table – replicate-wild-do-table – replicate-ignore-table – replicate-wild-ignore-table 120
  • 121. Irontec – Administración de MySQL Logs 121
  • 122. Irontec – Administración de MySQL Logs ● El diagrama para el logeo de tablas es demasiado grande y no entra ;) http://dev.mysql.com/doc/refman/5.0/en/replication-rules-table-options.html ● Para rellenar la diapositiva pondré un dibujo: No se quien es el autor :( 122
  • 123. Irontec – Administración de MySQL Replicación y alta disponibilidad 123
  • 124. Irontec – Administración de MySQL Arquitecturas de replicación ● Tenemos varias formas de montar una arquitectura de replicación. – Maestro-Maestro – Maestro-Esclavo – Circular ● Según lo que se necesite, se monta una u otra. 124
  • 125. Irontec – Administración de MySQL Limitaciones ● Un esclavo solo puede tener un maestro. Por el contrario, un maestro múltiples esclavos. ● No es recomendable montar una replicación por WAN. La replicación es asíncrona y sensible a latencias. ● En un servidor esclavo esta prohibido escribir datos, solo se usarán selects. 125
  • 126. Irontec – Administración de MySQL Maestro-Esclavo ● Un maestro, múltiples esclavos. ● En el maestro se escribe, en el esclavo se lee. 126
  • 127. Irontec – Administración de MySQL Maestro-Esclavo ● Primero debemos configurar el maestro. Imprescindible: – Habilitar los logs binarios. – Crear un usuario que permita conectarse a los esclavos. – Habilitar sync_binlog. – Elegir un server-id. log­bin=mysql­bin server­id=1 sync_binlog=1 127
  • 128. Irontec – Administración de MySQL Maestro-Esclavo ● Dar permisos de conexión a los eslavos y dumpeamos la BD: mysqldump BD ­­master­data=2 > dump_file; mysql> grant replication slave on *.* to  'replication'@10.10.10.1 identified by 'slave'; mysql> grant replication slave on *.* to  'replication'@10.10.10.2 identified by 'slave'; 128
  • 129. Irontec – Administración de MySQL Maestro-Esclavo ● Configuramos el eslavo: – Seleccionamos un ID diferente para cada uno. – Importamos la BD. – Nos configuramos como esclavo de un maestro. $mysql ­u root ­p < dump server­id=101 mysql> CHANGE MASTER TO MASTER_HOST = ‘10.10.10.100’,  MASTER_USER = ‘replication’, MASTER_PASSWORD = ‘slave’,  MASTER_LOG_FILE = ‘master_log_file’, MASTER_LOG_POS =  master_log_pos; 129
  • 130. Irontec – Administración de MySQL Maestro-Esclavo ● Master_log_pos y Master_log_file indican al esclavo desde que posición del log binario deben leer, de forma que no se repliquen datos que ya tenemos. ● Podemos sacarlo con un dump como ya hemos visto o con el comando show master status; ● El log binario debe estár habilitado :) 130
  • 131. Irontec – Administración de MySQL Maestro-Esclavo ● No se debe dejar al servidor la elección de cuando escribir los datos al disco duro. ● Si el servidor se cae sin que algunos datos se escriban en el log, es posible que estos se pierdan (dependerá del sistema de ficheros). ● sync_binlog por defecto es 0, que deja que el servidor decida cuando realizar la escritura al disco. ● Se recomienda un valor de 1, para que se fuerce la escritura. ● Esto también es lento, dependerá de los discos duros instalados. ● Si el servidor se cae, como mucho perderemos una transacción. 131
  • 132. Irontec – Administración de MySQL Maestro-Esclavo ● Para comprobar si la replicación es correcta tenemos el comando show slave status. ● Este nos tiene que mostrar lo siguiente: [...] Slave_IO_Running: Yes Slave_SQL_Running: Yes [...] Seconds_Behind_Master: 0 Slave_IO_Running: Se encarga de conectarse al maestro para comprobar cambios Slave_SQL_Running: Se encarga de escribir las sentencias SQL. Seconds_Behind_Master: El lag en segundos entre el maestro y el esclavo. 132
  • 133. Irontec – Administración de MySQL Maestro-Maestro ● Lo que se escribe en uno se replica en el otro. ● Se puede escribir en los dos. 133
  • 134. Irontec – Administración de MySQL Maestro-Maestro ● La arquitectura maestro-maestro es igual a la maestro esclavo. ● Aquí los hosts realizan las dos tareas, maestro y esclavo al mismo tiempo. ● Esta arquitectura soporta como máximo dos hosts, ya que un esclavo solo puede tener como máximo un maestro. A es maestro de B. B es maestro de A. A es esclavo de B. B es esclavo de A. 134
  • 135. Irontec – Administración de MySQL Maestro-Maestro ● Se debe tener en cuenta, al igual que antes, lo siguiente: – Habilitar el log binario. – Seleccionar un server-id. – Establecer el valor de sync_binlog. – Crear los usuarios para la replicación. ● El funcionamiento, opciones, monitorización, etc. es todo igual. 135
  • 136. Irontec – Administración de MySQL Maestro-Maestro ● Los auto-incrementales son el gran problema de este tipo de arquitectura. Si se realizan dos insert al mismo tiempo que incluya un campo autoincremental, podemos tener un problema de ID duplicado. ● A envía a B un artículo cuyo ID autoincremental es 3000, B envía un artículo diferente a A cuyo autoincremental es 3000 también. La replicación se rompe. – auto_increment_increment = 2 – auto_increment_offset = 1 ● ¿Cómo sería para el server B? 136
  • 137. Irontec – Administración de MySQL Circular ● Lo que se escribe en uno se replica en el siguiente, este en el siguiente, este en... A → B → C → D → A ● Es la menos recomendable. En realidad está casi prohibida también ;) 137
  • 138. Irontec – Administración de MySQL Circular ● Es una forma de disponer de más de dos servidores en arquitectura maestro-maestro. ● Contra más sean los hosts implicados, mayor el caos de su administración. A→B→C→D→E→A ● Si el host C se cae (por ejemplo) la replicación se rompe. Lo escrito en B no se replica, lo escrito en D se replica en todos menos en C, etc. ● Si se cae por ejemplo B y D, el caos es infinito. La solución es salir corriendo. ● A no ser que no exista otra solución, no se recomienda. 138
  • 139. Irontec – Administración de MySQL Circular ● Los logs que reciben los esclavos, deben logearlos en el log binario para enviarselo al siguiente en la cadena. Esto no es el funcionamiento por defecto, los que se recibe como esclavo no se logea. Para cambiarlo: – log­slave­updates ● En algún momento de la cadena nos llegarán nuestros propios logs. Para evitar formar un bucle: – Replicate­same­server­id=0 ● También habrá que tener cuidado con los auto- incrementales: – auto_increment_increment=4 – auto_increment_offset=1 139
  • 140. Irontec – Administración de MySQL Replicación rota 140
  • 141. Irontec – Administración de MySQL Replicación rota ● Es recomendable tener el error-log habilitado, ahí se guardará, entre otras cosas, cualquier error relacionado con la replicación. ● ¡EJEMPLO! Sep 11 11:13:16 test2 mysqld[6776]: 090911 11:13:16  [ERROR] Slave: Error 'Table 't' already exists' on  query. Default database: 'mysql'. Query: 'CREATE  TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE  utf8_bin)', Error_code: 1050 Sep 11 11:13:16 test2 mysqld[6776]: 090911 11:13:16  [ERROR] Error running query, slave SQL thread  aborted. Fix the problem, and restart the slave SQL  thread with "SLAVE START". We stopped at log 'mysql­ bin.000003' position 421 141
  • 142. Irontec – Administración de MySQL Replicación rota ● Forma rápida y no tan buena de solucionarlo: ● Decirle al esclavo que ignore esa query y continue con la replicación: mysql> stop slave; Query OK, 0 rows affected (0.00  sec)  mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; Query  OK, 0 rows affected (0.00 sec)  mysql> start slave; 142
  • 143. Irontec – Administración de MySQL Replicación rota ● Forma buena de solucionarlo: http://www.maatkit.org/ ● Maatkit makes MySQL easier to manage. ● Lo de “easier” ponedlo entre muchas comillas. ● Son una colección de herramientas que nos puede ayudar en la administración de nuestro servidores, y en este caso en particular, en rescatar una replicación. ● Todas las utilidades: http://www.maatkit.org/doc/ 143
  • 144. Irontec – Administración de MySQL Replicación rota ● Para saber si dos tables están sincronizadas, podemos sacar un checksum de estas y comparar: – mk­table­checksum ● Para sincronizar los datos de dos tablas: – mk­table­sync $ mk­table­checksum h=host1,u=user,p=password h=host2 $ mk­table­sync –execute  u=user,p=pass,h=host1,D=db,t=tbl host2 144
  • 145. Irontec – Administración de MySQL MMM ● Cuando ya sabemos que queremos y lo montamos, llega el mantenimiento. ● Si tenemos un cluster de, por ejemplo, 2 maestros y 50 esclavos, comprobar el correcto funcionamiento es complicado. ● ¿Y si deseamos parar algún esclavo? ● ¿Y si deseamos parar algún maestro? ● Es necesario reducir el tiempo de parada de servicio al mínimo. 145
  • 146. Irontec – Administración de MySQL MMM 146
  • 147. Irontec – Administración de MySQL MMM ● También el Perl. El mundo se ha vuelto loco... ● Características: – Monitorización de la replicación – Monitorización de los hosts – Gestión del failover – Balanceo de IPs entre nodos – Gestión de grupos de escritura/lectura 147
  • 148. Irontec – Administración de MySQL MMM ● La alta disponibilidad se hace mediante el balanceo de Ips virtuales que saltarán de un servidor a otro en caso de ser necesario. – Exclusivo: Una única IP para muchos hosts. Si el host que la tiene se cae se balancea a otro. Generalmente se usa en los nodos de escritura. – Balanceado: Una IP por cada host. Si uno de los hosts se cae la IP se balancea a cualquier otro, pasando a tener dos IPs virtuales. Se usa para nodos en lectura. 148
  • 149. Irontec – Administración de MySQL MMM ● Se pueden meter los servidores dentro de dos roles, escritura y lectura. Escritura es obligatorio, mientras que el de lectura no tiene porque definirse. ● La diferencia es lógica: – Nodos de escritura son aquellos en los que los datos se escribirán. – Nodos de lectura son aquellos de los cuales se leerán datos. ● Escritura (maestro) – Lectura (esclavo) 149
  • 150. Irontec – Administración de MySQL MMM http://mysql-mmm.org/ ● En el sistema de control se instalará: – mysql-mmm-common_2.0.10-1_all.deb – mysql-mmm-monitor_2.0.10-1_all.deb ● En los nodos: – mysql-mmm-common_2.0.10-1_all.deb – mysql-mmm-agent_2.0.10-1_all.deb ● ¡Junto con todas las dependencias! 150
  • 151. Irontec – Administración de MySQL MMM ● Los ficheros de configuración se guardan en /etc/mysql- mmm ● Todos tendrán un fichero llamado mmm_common.conf que será exactamente igual. ● El nodo de control mmm_mon.conf ● Los servidores de MySQL mmm_agent.conf 151
  • 152. Irontec – Administración de MySQL MMM ● mmm_common.conf ● Incluye la configuración de: – Los Hosts – Sus Ips – Los roles – Usuario/Contraseña del agente – Usuario/Contraseña para la replicación – La interfaz de red en la que se trabaja 152
  • 153. Irontec – Administración de MySQL MMM ● mmm_mon.conf ● Incluye la configuración de: – Usuario/Contraseña para la monitorización – Ips a las que pingar – Ruta de los binarios – Ruta del PID – Nivel de debug 153
  • 154. Irontec – Administración de MySQL MMM ● mmm_agent ● Incluye la configuración de: – El nombre de este servidor – Todo el mmm_common.conf – Y nada más :P 154
  • 155. Irontec – Administración de MySQL MMM ● Como hemos visto, hay varios usuarios y contraseñas definidos. Hay que crerlos en MySQL. GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'10.100.1.%'  IDENTIFIED BY 'RepMonitor'; GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO  'mmm_agent'@'10.100.1.%' IDENTIFIED BY 'RepAgent'; GRANT REPLICATION SLAVE ON *.* TO 'replication'@'10.100.1.%'  IDENTIFIED BY 'slave'; – El usuario monitor se usa para comprobar el estado de los servidores Mysql. – El usuario agent se usa para cambiar el read only mode, poner offline un equipo, ejecutar un change_master, etc. – El usuario replication slave... para replicación ;) 155
  • 156. Irontec – Administración de MySQL MMM ● Una vez puesto en marcha los servicios, se deben poner online los servidores desde el comando de control. MMM:~# mmm_control show   db1(10.100.1.1) master/AWAITING_RECOVERY. Roles:    db2(10.100.1.2) master/AWAITING_RECOVERY. Roles:    db3(10.100.1.3) slave/AWAITING_RECOVERY. Roles:    db4(10.100.1.4) slave/AWAITING_RECOVERY. Roles: MMM:~# mmm_control set_online db1 OK: State of 'db1' changed to ONLINE. Now you can wait  some time and check its new roles! MMM:~# mmm_control set_online db2 OK: State of 'db2' changed to ONLINE. Now you can wait  some time and check its new roles! MMM:~# mmm_control set_online db3 OK: State of 'db3' changed to ONLINE. Now you can wait  some time and check its new roles! MMM:~# mmm_control set_online db4 OK: State of 'db4' changed to ONLINE. Now you can wait  some time and check its new roles! 156
  • 157. Irontec – Administración de MySQL MMM ● ¡Ejemplo! Parando un servidor en producción: MMM:~# mmm_control set_offline db1 OK: State of 'db1' changed to ADMIN_OFFLINE. Now you can  wait some time and check all roles! MMM:~# mmm_control show   db1(10.100.1.1) master/ADMIN_OFFLINE. Roles:    db2(10.100.1.2) master/ONLINE. Roles:  writer(10.100.1.10)   db3(10.100.1.3) slave/ONLINE. Roles: reader(10.100.1.12)   db4(10.100.1.4) slave/ONLINE. Roles: reader(10.100.1.11) 157
  • 158. Irontec – Administración de MySQL MySQL Proxy 158
  • 159. Irontec – Administración de MySQL MySQL Proxy ● El balanceo de carga se puede hacer bien por hardware como por software. ● Existe un software creado para MySQL que nos puede “ayudar”. ● Para que te ayude debes saber LUA. http://forge.mysql.com/wiki/MySQL_Proxy ● Es un proxy que se pone entre el cliente y los servidores de MySQL. 159
  • 160. Irontec – Administración de MySQL MySQL Proxy ● Trae scripts de ejemplo, que entre otras cosas te permite: – Reescribir queries. – Balanceo de carga. – Loggeo avanzado. – Failover. – Análisis de queries. 160
  • 161. Irontec – Administración de MySQL MySQL Proxy ● La instalación es sencilla, descargamos de: – http://dev.mysql.com/downloads/mysql-proxy/ ● Descomprimimos en: – /usr/local/mysql-proxy ● Tenemos el binario en bin ● Tenemos scripts de ejemplo en share/doc/mysql-proxy/ 161