martes, 30 de abril de 2013

Replicación

Cómo montar la replicación

Aquí hay una breve descripción de cómo inicializar una replicación completa de su servidor MySQL. Asume que quiere replicar todas las bases de datos en el maestro y no tiene una replicación préviamente configurarda. Necesita parar el servidor maestro brevemente para completar los pasos descritos aquí.
Este procedimiento está escrito en términos de inicializar un esclavo único, pero puede usarlo para inicializar múltiples esclavos.
Mientras este método es el más directo para inicializar un esclavo, no es el único. Por ejemplo, si tiene una muestra de los datos del maestro, y el maestro tiene su ID de servidor y el log binario activo, puede preparar un esclavo sin parar el maestro o incluso sin bloquear actualizaciones para ello.   
Si quiere administrar la inicialización de una replicación MySQL, sugerimos que lea este capítulo entero y pruebe todos los comandos mencionados.-   
Nota: este procedimiento y algunos de los comandos de replicación SQL mostrados en secciones posteriores necesita el privilegio SUPER.
  1. Asegúrese de que las versiones de MySQL instalado en el maestro y en el esclavo son compatibles según dice la tabla mostrada en Sección 6.5, “Compatibilidad entre versiones de MySQL con respecto a la replicación”. Idealmente, debe usar la versión más reciente de MySQL en maestro y servidor.
    Por favor no reporte bugs hasta que ha verificado que el problema está presente en la última versión de MySQL.
  2. Prepare una cuenta en el maestro que pueda usar el esclavo para conectar. Este cuenta debe tener el privilegio REPLICATION SLAVE . Si la cuenta se usa sólo para replicación (lo que se recomienda), no necesita dar ningún privilegio adicional. (Para información sobre preparar cuentas de usuarios y privilegios, consulte Sección 5.7, “Gestión de la cuenta de usuario MySQL”.)
    Suponga que su dominio es mydomain.com y que quiere crear una cuenta con un nombre de usuario de repl que puedan usar los esclavos para acceder al maestro desde cualquier equipo en su dominio usando una contraseña de slavepass. Para crear la cuenta, use el comando GRANT:
    mysql> GRANT REPLICATION SLAVE ON *.*
        -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
    Si quiere usar los comandos LOAD TABLE FROM MASTER o LOAD DATA FROM MASTER desde el servidor esclavo, necesita dar a esta cuenta privilegios adicionales:
    • De a la cuenta el privilegio global SUPER y RELOAD .
    • De el privilegio SELECT para todas las tablas que quiere cargar. Cualquier tabla maestra desde la que la cuenta no puede hacer un SELECT se ignoran por LOAD DATA FROM MASTER.
  3. Si usa sólo tablas MyISAM , vuelque todas las tablas y bloquee los comandos de escritura ejecutando un comando FLUSH TABLES WITH READ LOCK :
    mysql> FLUSH TABLES WITH READ LOCK;
    Deje el cliente en ejecución desde el que lanza el comando FLUSH TABLES para que pueda leer los efectos del bloqueo. (Si sale del cliente, el bloqueo se libera.) Luego tome una muestra de los datos de su servidor maestro.
    La forma más fácil de crear una muestra es usar un programa de archivo para crear una copia de seguidad binaria de las bases de datos en su directorio de datos del maestro. Por ejemplo. use tar en Unix, o PowerArchiver, WinRAR, WinZip, o cualquier software similar en Windos. Para usar tar para crear un archivo que incluya todas las bases de datos, cambie la localización en el directorio de datos del maestro, luego ejecute el comando:
    shell> tar -cvf /tmp/mysql-snapshot.tar .
    Si quiere que el archivo sólo incluya una base de datos llamada this_db, use este comando:
    shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db
    Luego copie el archivo en el directorio /tmp del servidor esclavo. En esa máquina, cambie la localización al directorio de datos del esclavo, y desempaquete el fichero usando este comando:
    shell> tar -xvf /tmp/mysql-snapshot.tar
    Puede no querer replicar la base de datos mysql si el servidor esclavo tiene un conjunto distinto de cuentas de usuario a la existente en el maestro. En tal caso, debe excluírla del archivo. Tampoco necesita incluir ningún fichero de log en el archivo, o los ficheros master.info o relay-log.info files.
    Mientras el bloqueo de FLUSH TABLES WITH READ LOCK está en efecto, lee el valor del nombre y el desplazamiento del log binario actual en el maestro:
    mysql > SHOW MASTER STATUS;
    +---------------+----------+--------------+------------------+
    | File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +---------------+----------+--------------+------------------+
    | mysql-bin.003 | 73       | test         | manual,mysql     |
    +---------------+----------+--------------+------------------+
    La columna File muestra el nombre del log, mientras que Position muestra el desplazamiento. En este ejemplo, el valor del log binario es mysql-bin.003 y el desplazamiento es 73. Guarde los valores. Los necesitará más tarde cuando inicialice el servidor. Estos representan las coordenadas de la replicación en que el esclavo debe comenzar a procesar nuevas actualizaciones del maestro.
    Una vez que tiene los datos y ha guardado el nombre y desplazamiento del log, puede reanudar la actividad de escritura en el maestro:
    mysql> UNLOCK TABLES;
    Si está usando tablas InnoDB , debería usar la herramienta InnoDB Hot Backup. Realiza una copia consistente sin bloquear el servidor maestro, y guarda el nombre y desplazamiento del log que se corresponden a la copia para usarlo posteriormente en el esclavo. InnoDB Hot Backup es una herramienta no libre (comercial) que no está incluída en la distribución de MySQL estándar. Consulte la página web de InnoDB Hot Backup en http://www.innodb.com/manual.php para información detallada.
    Sin la herramienta Hot Backup , la forma más rápida de hacer una copia binaria de los datos de las tablas InnoDB es parar el maestro y copiar los ficheros de datos InnoDB, ficheros de log, y ficheros de definición de tablas (ficheros .frm). Para guardar los nombres de ficheros actual y desplazamientos, debe ejecutar el siguiente comando antes de parar el servidor:
    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SHOW MASTER STATUS;
    Luego guarde el nombre del log y el desplazamiento desde la salida de SHOW MASTER STATUS como se mostró antes. Tras guardar el nombre del log y el desplazamiento, pare el servidor sin bloquear las tablas para asegurarse que el servidor para con el conjunto de datos correspondiente al fichero de log correspondiente y desplazamiento:
    shell> mysqladmin -u root shutdown
    Una alternativa que funciona para tablas MyISAM y InnoDB es realizar un volcado SQL del maestro en lugar de una copia binaria como se describe en la discusión precedente. Para ello, puede usar mysqldump --master-data en su maestro y cargar posteriormente el fichero de volcado SQL en el esclavo. Sin embargo, esto es más lento que hacer una copia binaria.
    Si el maestro se ha ejecutado previamente sin habilitar --log-bin , el nombre del log y las posiciones mostradas por SHOW MASTER STATUS o mysqldump --master-data están vacíos. En ese caso, los valores que necesita usar posteriormente cuando especifica el fichero de log del esclavo y la posición son una cadena vacía ('') y 4.
  4. Asegúrese que la sección [mysqld] del fichero my.cnf en el maestro incluye una opción log-bin . Esta sección debe también tener la opción server-id=master_id , donde master_id debe ser un entero positivo de 1 a 2^32 - 1. Por ejemplo:
    [mysqld]
    log-bin=mysql-bin
    server-id=1
    Si estas opciones no están presentes, añádalas y reinicie el servidor.
  5. Pare el servidor que se vaya a usar como esclavo y añada lo siguiente a su fichero my.cnf :
    [mysqld]
    server-id=slave_id
    El valor slave_id , como el valor master_id , debe ser un entero positivo de 1 a 2^32 - 1. Además, es muy importante que el ID del esclavo sea diferente del ID del maestro. Por ejemplo:
    [mysqld]
    server-id=2
    Si está preparando varios esclavos, cada uno debe tener un valor de server-id único que difiera del maestro y de cada uno de los otros esclavos. Piense en los valores de server-id como algo similar a las direcciones IP: estos IDs identifican unívocamente cada instancia de servidor en la comunidad de replicación.
    Si no especifica un server-id, se usa 1 si no ha definido un master-host, de otro modo se usa 2. Tenga en cuenta que en caso de omisión de server-id, un maestro rechaza conexiones de todos los esclavos, y un esclavo rechaza conectar a un maestro. Por lo tanto, omitir el server-id es bueno sólo para copias de seguridad con un log binario.
  6. Si ha hecho una copia de seguridad binara de los datos del maestro, cópielo en el directorio de datos del esclavo antes de arrancar el esclavo. Asegúrese que los privilegios en los ficheros y directorios son correctos. El usuario que ejecuta el servidor MySQL debe ser capaz de leer y escribir los ficheros, como en el maestro.
    Si hizo una copia de seguridad usando mysqldump, arranque primero el esclavo (consulte el siguiente paso).
  7. Arranque el esclavo. Si ha estado replicando préviamente, arranque el esclavo con la opción --skip-slave-start para que no intente conectar inmediatamente al maestro. También puede arrancar el esclavo con la opción --log-warnings (activada por defecto en MySQL 5.0), para obtener más mensajes en el log de errores acerca de problemas (por ejemplo, problemas de red o conexiones). En MySQL 5.0, las conexiones abortadas no se loguean en el log de errores a no ser que el valor sea mayor que 1.
  8. Si hace una copia de seguridad de los datos del maestro usando mysqldump, cargue el fichero de volcado en el esclavo:
    shell> mysql -u root -p < dump_file.sql
  9. Ejecute los siguientes comandos en el esclavo, reemplazando los valores de opciones con los valores relevantes para su sistema:
    mysql> CHANGE MASTER TO
        ->     MASTER_HOST='master_host_name',
        ->     MASTER_USER='replication_user_name',
        ->     MASTER_PASSWORD='replication_password',
        ->     MASTER_LOG_FILE='recorded_log_file_name',
        ->     MASTER_LOG_POS=recorded_log_position;
    La siguiente tabla muestra la longitud máxima para las opciones de cadenas de caracteres:
    MASTER_HOST60
    MASTER_USER16
    MASTER_PASSWORD32
    MASTER_LOG_FILE255
  10. Arranque el flujo esclavo:
    mysql> START SLAVE;
Una vez realizado este procedimiento, el esclavo debe conectar con el maestro y atapar cualquier actualización que haya ocurrido desde que se obtuvieron los datos.
Si ha olvidado asignar un valor para server-id en el maestro, los esclavos no son capaces de conectar.
Si olvida asignar un valor para server-id en el esclavo, obtiene el siguiente error en el log de errores:
Warning: You should set server-id to a non-0 value if master_host is set;
we will force server id to 2, but this MySQL server will not act as a slave.
También encuentra mensajes de error en el log de errores del esclavo si no es capaz de replicar por ninguna otra razón.
Una vez que un esclavo está replicando, puede encontrar en su directorio de datos un fichero llamado master.info y otro llamado relay-log.info. El esclavo usa estos dos ficheros para saber hasta que punto ha procesado el log binario del maestro. No borre o edite estos ficheros, a no ser que realmente sepa lo que hace y entienda las implicaciones. Incluso en tal caso, es mejor que use el comando CHANGE MASTER TO.
Nota: El contenido de master.info subedita algunas de las opciones especificadas en línea de comandos o en my.cnf. Consulte Sección 6.8, “Opciones de arranque de replicación” para más detalles.
Una vez que tiene una copia de los datos, puede usarlo para actualizar otros esclavos siguiendo las porciones del procedimiento descrito. No necesita otra muestra de los datos del maestro; puede usar la misma para todos los esclavos.
Nota: para la mayor durabilidad y consistencia posible en una inicialización de replicación usando InnoDB con transacciones debe usar innodb_flush_logs_at_trx_commit=1, sync-binlog=1, y innodb_safe_binlog en su fichero my.cnf del maestro.


http://www.youtube.com/watch?v=XVkI0WlcVSM

lunes, 29 de abril de 2013

Espejeo

Administración y Mantenimiento de Database Mirroring en SQL Server 2005 y SQL Server 2008 (introducción)


Una vez configurado y puesto en marcha Database Mirroring en SQL Server, es necesario estar preparados para administrar y mantener dicha infraestructura de Database Mirroring, evitando caídas de servicio y entradas de incidencias. Aunque Database Mirroring es una tecnología con un bajo coste de mantenimiento (más dolores de cabeza genera la Replicación de SQL Server, por ejemplo), es necesario tener en cuenta ciertas peculiaridades en la administración y mantenimiento de las bases de datos montadas en Database Mirroring. ¿Qué se debe tener en cuenta para la Administración y Mantenimiento de Database Mirroring en SQL Server?


Como en todas áreas, podríamos extendernos ampliamente para cubrir este tema. Sin embargo, y para no abrumar, vamos a intentar hacer un capítulo introductorio capaz de presentar las principales problemáticas, herramientas y comandos a tener en cuenta en la administración y mantenimiento de Database Mirroring. En particular, vamos a ver lo siguente:
  • Herramientas de Database Mirroring
  • Crear un Database Snapshot sobre la base de datos Espejo
  • Cómo quitar Database Mirroring
  • Orden de Parada y Arranque de Servidores SQL Server con Database Mirroring
  • Cómo Pausar y Reanudar Database Mirroring
  • Quitar o Reemplazar el Servidor Testigo (Witness)
  • Redirección de Cliente: ADO.NET / SQL Native Client automatic redirection
  • Otras consideraciones de la Administración y Mantenimiento de Database Mirroring en SQL Server
Tomada conciencia de qué es lo que vamos a ver, empezamos a meternos en harina...

Herramientas de Database Mirroring

Desde SQL Server Management Studio (SSMS), están disponibles las siguientes herramientas o utilidades:
  • Página Mirroring del diálogo de Propiedades de Base de Datos. Al abrir el diálogo de Propiedades de una base de datos (click con el botón derecho sobre la base de datos deseada, y seguidamente click en Properties), podemos acceder a la página Mirroring. Aquí se muestra información general sobre el Mirroring (Extremos o EndPoints de los Servidores Principal, Espejo y Testigo, Modo de Operación del Database Mirroring, Estado, etc.), y además, se permite realizar distintas acciones, como Pausar y Reanudar el Database Mirroring, realizar un balanceo (failover), o eliminar el Database Mirroring.
  • Asistente de Configuración de Database Mirroring (Configure Database Mirroring Security Wizard). Este asistente está disponible desde la página Mirroring del diálogo de Propiedades de Base de Datos. A través de este asistente es posible configurar el Database Mirroring (creación de los Extremos o EndPoints necesarios, establecimiento de la sesión de Database Mirroring entre el Principal y Espejo, agregar el Testigo, etc.).
  • Database Mirroring Monitor. Podemos acceder a esta herramienta, desde SQL Server Management Studio (SSMS), haciendo click con el botón derecho sobre la base de datos deseada, después click sobre Tasks en el menú contextual, y seguidamente click sobre la opción Launch Database Mirroring Monitor. Database Mirroring Monitor, permite monitorizar en tiempo real las bases de datos configuradas en Database Mirroring, así como obtener información histórica de las mismas (qué servidor era Principal y Secundario en un momento anterior en el tiempo, transacciones pendientes, etc.). Nota: el historial almacenado es de los últimos 7 días. Este valor no se puede cambiar.
Como siempre, todo lo que se puede realizar desde un interfaz gráfico, es posible realizarlo también por comandos, utilizando Transact-SQL. En este caso, trataremos especialmente con los comandos ALTER DATABASE SET PARTNER y CREATE ENDPOINT.

Crear un Database Snapshot sobre la base de datos Espejo

Una tarea que puede resultar de gran utilidad, es la creación de un Snapshot (o Instantánea de Base de Datos) sobre una base de datos en Espejo. Lo gracioso de esto, es que la base de datos en Espejo no puede ser accedida, pero sin embargo, si creamos un Snapshot sobre dicha base de datos espejo, si podremos acceder a los datos de la base de datos en el momento de creación del Snapshot (eso sí, accederemos en modo de sólo lectura). A continuación se incluye un trozo de código Transact-SQL como ejemplo de creación de un Database Snapshot.
CREATE DATABASE GuilleSQL_Snap01
ON (NAME = GuilleSQL, FILENAME = 'D:\ DATA\GuilleSQL_Snap01.mdf')
AS SNAPSHOT OF GuilleSQL

Cómo quitar Database Mirroring

Aunque no se trate de una tarea de mantenimiento habitual, resulta interesante conocer como quitar o deshacer el Database Mirroring, principalmente para pruebas que deseemos realizar en entornos de laboratorio, etc. En cualquier caso, se trata de una tarea muy sencilla, pues para deshacer el Database Mirroring, tan sólo es necesario ejecutar una sentencia ALTER DATABASE SET PARTNER OFF, como se muestra en el siguiente ejemplo:
ALTER DATABASE GuilleSQL SET PARTNER OFF
También es posible realizarlo de forma gráfica desde la pestaña Mirroring del diálogo de Propiedades de la base de datos correspondiente (botón Remove Mirroring).
Después de desconfigurar Database Mirroring con la anterior sentencia ALTER DATABASE SET PARTNER OFF o desde SSMS, es posible volver a configurarlo (si fuese necesario, por ejemplo, por haber deshabilitado Database Mirroring por error) sin necesidad de volver a ejecutar sentencias de BACKUP ni de RESTORE, es decir, directamente ejecutando las correspondientes sentencias ALTER DATABASE SET PARTNER (como se vió anteriormente, en el apartado de configuración de Database Mirroring). Esto es así (probado), siempre y cuando no perdamos transacciones en la base de datos principal (ej: truncar el Log).
De hecho, al ejecutar la sentencia ALTER DATABASE SET PARTNER OFF, la base de datos Principal se quedará activa como una base de datos normal y corriente (sin Database Mirroring, ni ná de ná), mientras que la base de datos Espejo se quedará en estado Restoring, igual que la dejamos cuando ejecutamos los RESTORE WITH NORECOVERY utilizados inicialmente para configurar el Database Mirroring. Por este motivo, tenemos la posibilidad de volver a configurar el Database Mirroring, o bien, si lo deseamos podemos configurar la base de datos del Espejo como una base de datos activa ejecutando una sentencia RESTORE WITH RECOVERY (ej: RESTORE DATABASE GuilleSQL WITH RECOVERY).
En cualquier caso, una vez que se ha roto la sesión de Database Mirroring con la sentencia ALTER DATABASE SET PARTNER OFF, y si queremos dejar la casa limpia, el siguiente paso sería eliminar los ENDPOINT creados para el Database Mirroring (en el Principal, Espejo y Testigo), mediante sentencias DROP ENDPOINT (ej: DROP ENDPOINT Mirroring) en cada uno de los servidores. Eso sí, eliminaremos los ENDPOINT si no existe ninguna otra sesión de Database Mirroring (es decir, si no se están utilizando, claro).

Orden de Parada y Arranque de Servidores SQL Server con Database Mirroring

El orden de parada de los servidores Database Mirroring en modo Alta Disponibilidad (High Availability) es vinculante, pues podría producirse un failover automático, es decir, que se intercambien los roles de Principal y Mirror. En consecuencia, en el posterior inicio de servidores, los roles de mantendrán intercambiados.
Por ejemplo, si trabajando en modo Alta Disponibilidad (High Availability), primero se produce la parada del Principal (lo cual, implica un failover automático, intercambiándose los roles), y seguidamente se realiza la parada del Mirror (mentira… después del anterior failover, realmente ahora sería el Principal debido al intercambio de roles, ¿ok?) y Witness, en el siguiente inicio de servidores, se mantendrán los roles intercambiados.
En este caso, si las aplicaciones clientes de dichas bases de datos en Mirror, no disponen de ningún sistema automático de re-dirección a la nueva instancia que actúa como Principal en el Database Mirroring, podría ser necesaria alguna operación manual para conseguir restablecer el correcto funcionamiento de las aplicaciones, ya sea la realización de un balanceo manual (manual failover) a través de una sentencia ALTER DATABASE SET PARTNER FAILOVER, o bien, una redirección manual de las aplicaciones (ej: modificar el Alias SQL utilizado para conectar a las bases de datos, cambiar la cadena de conexión a la base de datos, etc.).
Del mismo modo, es importante aclarar, que el orden de arranque de los servidores Database Mirroring no es vinculante (es decir, no producirá balaceo automático - automatic failover), ni en modo Alta Disponibilidad (High Availability), ni en ningún otro modo. Este comportamiento es bastante lógico, aunque en algún caso cuesta más entenderlo. El Quiz de la cuestión es el siguiente: si están todos los servidores parados, y se inician el Testigo (Witness) y el Espejo (Mirror) ¿Qué debería ocurrir? ¿Debería el Testigo (Witness) forzar un balanceo automático (automatic failover)? Pues no, el Mirror seguirá como Mirror y los clientes no podrán conectarse a la base de datos hasta que arranque el servidor Principal, excepto que rompamos el Database Mirroring (ejecutando la correspondiente sentencia ALTER DATABASE GuilleSQL SET PARTNER OFF) y recuperemos dicha base de datos (RESTORE DATABASE GuilleSQL WITH RECOVERY), algo que sólo deberíamos realizar en caso de emergencia (ojo, que en este caso, cuando levante el servidor Principal, nos encontraremos con dos servidores que contienen la misma base de datos viva, con el riesgo de que unos clientes puedan conectarse a un servidor y otros clientes a otro, y aquí si podemos liarla parda con los datos). He comentado la opción de romper el Mirroring en vez de forzar el cambio de roles, porque en las pruebas que he realizado, al intentar ejecutar la sentencia ALTER DATABASE SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS (que es lo que en principio yo pensaba que habría que hacer), el servidor me ha dicho que me peine.

Cómo Pausar y Reanudar Database Mirroring

Estas tareas resultan bastante fáciles de ejecutar, pues tan sólo requieren la ejecución de un único comando ALTER DATABASE SET PARTNER, y para quienes le guste, también es posible realizarlas de forma gráfica con SQL Server Management Studio (SSMS) desde la pestaña Mirroring del diálogo de Propiedades de la base de datos deseada. Sin embargo, bajo mi punto de vista, la problemática es para qué, y no el cómo. ¿Qué implica parar una sesión de Database Mirroring? ¿Para qué sirve? ¿Qué ventajas o inconvenientes tiene parar el Database Mirroring?
Parar una sesión de Database Mirroring suspende el Mirroring, lo cual implica que se detiene el envío de transacciones desde la Base de Datos Principal a la Base de Datos Espejo (Mirror). Esta situación nos va a permitir obtener una mejora de rendimiento adicional, que puede resultar de gran utilidad para realizar alguna tarea de mantenimiento o ejecutar algún proceso que genere muchas escrituras en base de datos. Sin embargo, nos va a traer un riesgo adicional, debido a que no se podrán truncar transacciones de los ficheros de Log (aún haciendo backups de Log), lo cual podría llegar incluso a llenar completamente el disco, impactando en el servicio de base de datos. Por ello, en caso de pausar una sesión de Database Mirroring, es importante reanudar dicha sesión de Database Mirroring lo antes posible, así como vigilar el crecimiento del Log en la base de datos Principal mientras la sesión de mirroring se mantenga pausada. También es importante tener en cuenta, que al reanudar la sesión de Database Mirroring, se enviarán las transacciones acumuladas en Log desde la base de datos Principal a la base de datos Espejo (Mirror).
A continuación se incluyen las sentencias Transact-SQL (ALTER DATABASE SET PARTNER) correspondientes a pausar y reaundar una sesión de Database Mirroring:
ALTER DATABASE GuilleSQL SET PARTNER SUSPEND

ALTER DATABASE GuilleSQL SET PARTNER RESUME

Quitar o Reemplazar el Servidor Testigo (Witness)

Para quitar el Servidor Testigo (Witness) asociado a una sesión de Database Mirroring, es suficiente con ejecutar un comando ALTER DATABASE SET WITNESS OFF, como se muestra en el siguiente ejemplo:
ALTER DATABASE GuilleSQL SET WITNESS OFF
Este comando puede ejecutarse independientemente desde el Servidor Principal o desde el Servidor Espejo (Testigo). También es posible ejecutarlo con éxito, aún con el Servidor Testigo (Witness) caído. En cualquier caso, debe tenerse en cuenta que el hecho de quitar el Servidor Testigo (Witness), configurará implícitamente el Database Mirroring en el modo de funcionamiento de Alta Protección (High Protection). Por ello, en caso de tener que quitar el Servidor Testigo (Witness) por pérdida del mismo, es recomendable configurar como Servidor Testigo (Witness) cualquier otra instancia de SQL Server, como medida preventiva, y hasta que pueda recuperarse el Servidor Testigo (Witness), recuperando así el modo de Alta Disponibilidad (High Availability) del Database Mirroring.

Redirección de Cliente: ADO.NET / SQL Native Client automatic redirection

En una conexión a una base de datos SQL Server configurada en Database Mirroring, realizada a través de ADO.Net o SQL Native Client, permite que pueda realizarse una Redirección Automática de la conexión a SQL Server. Es decir, si el cliente al conectarse a SQL Server detecta que el Servidor Principal está caído, será capaz de conectarse a través del Servidor Espejo (Mirror). Del mismo modo, si una vez el cliente ha conectado con SQL Server, se produce un failover, en la siguiente ocasión que el cliente necesite acceder a la base de datos, será capaz de reconectarse automáticamente al servidor que actúe como Servidor Principal.
La Redirección Automática del cliente en una infraestructura de Database Mirroring, es una funcionalidad muy apreciada, y en este caso, es tan fácil como utilizar una sintaxis determinada en la cadena de conexión a SQL Server, como se muestra en el siguiente:
"Data Source=SrvPrincipal;Failover Partner=SrvMirror;Initial Catalog=GuilleSQL;Integrated Security=True;"
De este modo, una aplicación que utilice esta funcionalidad (ej: una Aplícación Web de ASP.Net) será capaz de reconectarse automáticamente en caso de balanceo (failover), reduciéndose el coste de mantenimiento de la infraestructura.

Otras consideraciones de la Administración y Mantenimiento de Database Mirroring en SQL Server

  • No es posible realizar un Backup sobre la base de datos espejo. Al intentar realizar una copia de seguridad sobre la base de datos espejo, se obtiene el siguiente error:

    Msg 954, Level 14, State 1, Line 1
    The database "GuilleSQL" cannot be opened. It is acting as a mirror database.
    Msg 3013, Level 16, State 1, Line 1
    BACKUP DATABASE is terminating abnormally.

    Por ello, será necesario que la realización de los backups sea condicionada, y sólo se realice el backup de una base de datos configurada en Database Mirroring, cuando esté actuando como Principal. Esto puede solucionarse consultando la Vista de Catálogo sys.database_mirroring.

  • Las operaciones SHRINK no son siempre correctamente duplicadas de la base de datos principal a la base de datos espejo. Este problema está descrito en el Artículo de Soporte KB937531, dónde además se describe una solución temporal (WorkAround) para dicho problema. No nos asustemos, porque no es habitual, pero eso no quita que lo tengamos en cuenta.
Y con esto acaba este capítulo. Evidentemente, con este contenido no seremos los más expertos en Database Mirroring con SQL Server, pero seguro que tendremos una idea orientativa bastante acertada de las principales tareas de Mantenimiento y Administración de Database Mirroring.

 

viernes, 26 de abril de 2013

Seguridad en las Bases de Datos

SEGURIDAD EN BASE DE DATOS

Gran parte de los errores en cuanto a la seguridad en base de datos aun con el avance tecnológico suele producirse por la falta de preocupación de los procedimientos sencillos que a la larga se convierten en graves inconvenientes que afecta en lo concerniente a la seguridad, todo tiene que quedar de acuerdo con lo planeado sin ninguna omisión por mas mínima que sea, así como  en  la instalación en el diseño o en el desarrollo, cualquier punto que se deje sin la preocupación debida  que no pude afectar en nada puede ser la entrada para los atacantes.
 
Medidas de seguridad

Físicas: Comprende el control de quienes acceden al equipo.

Personal: Determinación del personal que tiene el acceso autorizado.

SO: Técnicas que se establecen para proteger la seguridad del Sistema Operativo

SGBD: Utilización de las herramientas que facilita el SGBD
 
La seguridad (fiabilidad) del sistema

Es necesario proteger a los sistemas de los ataques externos.

Controlar los fallos o caídas del software o equipo.

Controlar el manejo del administrador frente a errores que se pueden cometer.

Donde están los intrusos

Existen ataques externos que son detectados y controlados  por  el firewall, pero  aquí no termina el problema, de igual forma existen ataques internos, donde se le permite al usuario acceder libremente a la base de datos sin ningún tipo de protección suponiendo que el usuario no actuara con malas intenciones sobre el contenido almacenado y de esta forma comienzan un laberinto de  problemas.

Diferentes tipos de ataques

Se los pude clasificar como:

·         Ataques que no requieren autenticación

·         Ataques que requieren autenticación

ATAQUES QUE NO REQUIEREN AUTENTICACION: Son los más comunes ya que no se necesita de ninguna contraseña o clave, aquí tenemos las explotaciones  de buffer overflow como las más presentes.

Otra técnica que se encuentra en este misma clasificación es la que se pretende obtener una clave de acceso al sistema adivinando y los ataques de fuerza fruta o diccionario.

ATAQUES QUE REQUIEREN AUTENTICACION: Este tipo de ataques son lanzados por personas que tienes las claves de acceso obtenidas de formas generalmente ilícitas, este tipo de ataque suele tener un grado mayor de riesgo ya que se tiene  mas acceso, un ejemplo de este tipo de ataques es el de la explotación de los buffer overflows en procedimientos almacenados.

Metodología     

Puntos que se deben tomar en cuenta al momento que se requiere realizar un test de penetración a un servidor de base de datos:

·         Adquisición

·         Fingerprinting/Sondeo/Descubrimiento

·         Obtención de acceso

·         Estalación de privilegios

·         Compromiso total del host

Tareas que se deben tomar en cuenta al realizar una auditoria detallada:

·         Seguridad física

·         Políticas y procedimiento

·         Seguridad a nivel de file system

·         Seguridad de entorno

·         Stored procedures

·         Passwords

Los servidores de base de datos  ofrecen servicios de conexión los cuales deben ser controlados, pues son un punto de ataque. Los puertos en Oracle son 1521/tcp, Sql Server utiliza puertos 1433/tcp y 1434/udp.

En el año 2003 fue detectado uno de los gusanos llamado Sapphire, este era uno de los virus infecciosos mas rapidos que atacaba a versiones no parchadas de Sql Server.

Entre los factores que contribuyeron a la infección tenemos: los administradores no aplicaban parques correspondientes, cierta incapacidad por parte de Microsoft en servicios automáticos update y la falta de control en el port 1434/udp.

El puerto 1434/udp viene habilitado por defecto en toda instalación Sql server 2000 que se lo utiliza para diferentes actividades, y simplemente el hecho de bloquearlo hubiera sido necesario para controlar un ataque infeccioso. Una de las causas es que se cree que al no estar habilitado este puerto no funcionara bien el servicio de Sql Server, relativamente esto es falso ya que se puede trabajar normalmente si se bloquea este tipo de puerto.

martes, 16 de abril de 2013

Rendimiento de una base de datos



 

Capítulo 7. Optimización de MySQL

Tabla de contenidos

7.1. Panorámica sobre optimización     [+/-]
7.2. Optimizar sentencias SELECT y otras consultas     [+/-]
7.3. Temas relacionados con el bloqueo     [+/-]
7.4. Optimizar la estructura de una base de datos     [+/-]
7.5. Optimización del servidor MySQL     [+/-]
7.6. Cuestiones relacionadas con el disco     [+/-]



La optimización es una tarea compleja, porque requiere un conocimiento de todo el sistema a optimizar. Se podría optimizar sólo algunos aspectos teniendo poco conocimiento del sistema o aplicación, pero cuanto más óptimo se quiera el sistema, más se tiene que conocer acerca del mismo.

Este capítulo intenta explicar y da algunos ejemplos de las diferentes maneras de optimizar MySQL. Sin embargo se debe recordar que siempre existen vías de hacer todavía más rápido el sistema, aunque pudieran requerir un notable incremento de esfuerzos.

 


7.1.1. Limitaciones y soluciones de compromiso en el diseño de MySQL

Al utilizar el motor de almacenamiento MyISAM, MySQL usa un bloqueo (lock) extremadamente rápido de tablas, que permite múltiples lecturas o una sola escritura. El mayor problema con este motor de almacenamiento ocurre cuando se tiene un flujo constante de actualizaciones y selecciones lentas de una sola tabla. Si éste es el problema para algunas tablas, puede usar otro motor de almacenamiento para ellas. Ver Capítulo 14, Motores de almacenamiento de MySQL y tipos de tablas.

MySQL puede trabajar con tablas transaccionales y no transaccionales. Para hacer el trabajo más facil con tablas no transaccionales (donde no se puede deshacer una transacción si algo va mal), MySQL tiene las siguientes reglas. Obsérvese que estas reglas sólo se aplican cuando no se está corriendo en modo SQL estricto o si se usa el especificador IGNORE para un INSERT o un UPDATE.

  • Todas las columnas tienen valores por defecto. Obsérvese que cuando se ejecuta en modo SQL estricto (incluyendo modo SQL TRADITIONAL), se debe especificar cualquier valor para una columna NOT NULL.
  • Si se inserta un valor inapropiado o fuera de rango dentro de una columna, MySQL atribuye a la columna el “ mejor valor posible ” en vez de reportar un error. Para valores numéricos, éste es el 0, el valor más pequeño posible o el valor más grande posible. Para cadenas de texto, puede ser una cadena vacía o el trozo de la cadena más grande que quepa en la columna. Este comportamiento no se aplica cuando se ejecuta en modo SQL estricto TRADITIONAL.
  • Todas las expresiones calculadas retornan un valor que puede ser usado en vez de señalar una condición de error. Por ejemplo, 1/0 devuelve NULL. (Este comportamiento puede ser cambiado usando el modo SQL ERROR_FOR_DIVISION_BY_ZERO).

Si se usa una tabla no transaccional, no debería usar MySQL para comprobar el contenido de la columna. En general, la manera más segura (y generalmente más rápida) es usar la aplicacion para asegurarse que se están pasando sólo valores legales a la base de datos.

7.4. Optimizar la estructura de una base de datos


Los índices se utilizan para buscar las filas con valores de columna específicos rápidamente. Sin un índice, MySQL debe comenzar con el primer disco y luego leer a través de toda la tabla para buscar las filas correspondientes. Cuanto mayor sea la tabla, más esto cuesta. Si la tabla tiene un índice para las columnas en cuestión, MySQL puede determinar rápidamente la posición de buscar en el medio del archivo de datos sin tener que mirar a todos los datos. Si una tabla tiene 1000 filas, entonces este es al menos 100 veces más rápido que la lectura secuencial. Tenga en cuenta que si usted necesita para acceder a la mayoría de las filas, es más rápido para leer de forma secuencial, ya que esto minimiza el disco busca.

La mayoría de los índices de MySQL ( PRIMARY KEY , UNIQUE , INDICE y FULLTEXT ) se almacenan en árboles b.Las excepciones son que los índices de tipos de columna espaciales utilizan R-árboles, y que los MEMORIA tablas también soporta índices hash.

Las cadenas son automáticamente prefijo y finales espacio comprimido. Consulte Sección 13.1.4, "Sintaxis deCREATE INDEX " .

En general, los índices se utilizan como se describe en la siguiente discusión. Características específicas de índices hash (como los utilizados en MEMORIA tablas) se describen al final de esta sección.

Los índices se utilizan para estas operaciones:

·         Para buscar las filas que coincidan con una DONDE cláusula rápidamente.

·         Para eliminar filas de consideración. Si hay una elección entre varios índices, MySQL normalmente utiliza el índice que encuentra el menor número de filas.

·         Para recuperar filas de otras tablas al realizar combinaciones.

·         Para encontrar el MIN () o MAX () valor para una columna indexada específico key_col . Esto se optimiza mediante un preprocesador que comprueba si se está utilizando DONDE key_part_ # = constante en todas las partes fundamentales que se producen antes key_col en el índice. En este caso, MySQL hace una búsqueda de claves para cada MIN () y MAX () expresión y sustituirla por una constante. Si todas las expresiones se sustituyen con constantes, la consulta devuelve a la vez. Por ejemplo:

·         SELECT MIN ( key_part2 ), MAX ( key_part2 )

·           DE tbl_name DONDE key_part1 = 10;

·         Para ordenar o agrupar una tabla si la clasificación o agrupación se realiza en un prefijo a la izquierda de una clave útil (por ejemplo, ORDER BY key_part1 , key_part2 ). Si todas las partes fundamentales son seguidos por DESC , la clave se leen en orden inverso. Consulte Sección 7.2.10, "Como optimización de MySQL ORDER BY ".

·         En algunos casos, una consulta puede ser optimizado para recuperar valores sin consultar a las filas de datos. Si una consulta utiliza sólo las columnas de una tabla que es numérica y que forman un prefijo a la izquierda por alguna clave, los valores seleccionados se pueden recuperar desde el árbol de índice para una mayor velocidad:

·         SELECT key_part3 DE tbl_name 

  DONDE key_part1 = 1

 

7.5. Optimización del servidor MySQL


La siguiente lista indica algunas de las formas en que el mysqld servidor utiliza la memoria. En su caso, se le da el nombre de la variable de sistema relevantes para el uso de la memoria:

·         El key buffer (variable key_buffer_size ) es compartida por todos los temas, otros buffers usados ​​por el servidor se asignan según sea necesario. Consulte Sección 7.5.2, "afinar Lista de parámetros del Servidor" .

·         Cada conexión utiliza algo de espacio para subprocesos específicos:

§  Una pila (por defecto 64KB, variables thread_stack )

§  Un tampón de conexión (variable net_buffer_length )

§  Un buffer resultado (variable net_buffer_length )

El buffer de conexión y búfer resultado se amplían de forma dinámica hasta max_allowed_packet cuando sea necesario. Mientras se ejecuta una consulta, también se le asigna una copia de la cadena de consulta actual.

·         Todos los hilos comparten la misma memoria base.

·         Sólo comprimidos MyISAM tablas son la memoria asignada. Esto es debido a que el espacio de memoria de 32 bits de 4 GB no es lo suficientemente grande para la mayoría de grandes tablas. En equipos con un espacio de direcciones de 64 bits se vuelven más comunes, podemos añadir un apoyo general para la asignación de memoria.

·         Cada solicitud que realiza un análisis secuencial de la tabla asigna un búfer de lectura (variableread_buffer_size ).

·         Cuando la lectura de filas en una secuencia arbitraria (por ejemplo, a raíz de una especie), una memoria intermedia de lectura aleatoria (variable read_rnd_buffer_size ) puede ser asignado con el fin de evitar búsquedas en disco.

·         Todo se une se ejecutan en un solo paso, y la mayoría se une se puede hacer sin necesidad de utilizar una tabla temporal. La mayoría son tablas temporales basados ​​en memoria ( HEAP tablas). Las tablas temporales con una gran longitud de registro (calculado como la suma de todas las longitudes de columna) o que contengan BLOBcolumnas se almacenan en el disco.

Si una tabla de montón interna supera el tamaño de tmp_table_size , MySQL 5.0 se encarga de esto automáticamente al cambiar la tabla de montón en memoria a un disco basado en MyISAM mesa si es necesario.También puede aumentar el tamaño de la tabla temporal mediante el establecimiento de la tmp_table_sizeopción de mysqld o estableciendo la opción SQL SQL_BIG_TABLES en el programa cliente. Consulte Sección 13.5.3, "Sintaxis de SET " .

·         La mayoría de las peticiones que realizan una especie asignar un buffer de ordenación y de cero a dos archivos temporales, dependiendo del tamaño del conjunto de resultados. Consulte Sección A.4.4, "Dónde almacena MySQL los Archivos Temporales" .

·         Casi todos los análisis y cálculo se realiza en una tienda de la memoria local. No se necesita ninguna sobrecarga de la memoria para objetos pequeños, por lo que se evita la asignación de memoria normal y lenta liberación. La memoria se asigna sólo a las grandes cadenas de forma inesperada, lo que se hace con malloc () y free () .

·         Para cada MyISAM tabla que se abre, el archivo índice se abrió una vez, el archivo de datos se abre una vez por cada hilo de ejecución simultánea. Para cada hilo concurrente, una estructura de tabla, las estructuras de columna para cada columna, y un buffer de tamaño 3 * N se asignan (donde N es la longitud máxima de fila, sin contar BLOB columnas). Un BLOB columna requiere siete y cincuenta y cinco bytes más la longitud de los BLOB de datos. El MyISAM motor de almacenamiento mantiene un búfer fila adicional para su uso interno.

·         Para cada tabla que tiene BLOB columnas, un tampón se amplía dinámicamente a leer en grandes BLOB valores.Si escanea una mesa, un búfer tan grande como el mayor BLOB se asigna valor.

·         Estructuras de controlador de todas las tablas en uso se guardan en la memoria caché y administran como una FIFO. De forma predeterminada, la memoria caché tiene 64 entradas. Si una tabla se ha utilizado por dos subprocesos que se ejecutan al mismo tiempo, la memoria caché contiene dos entradas para la tabla. ConsulteSección 7.4.8, "como abre y cierra tablas MySQL" .

·         A FLUSH TABLES declaración o mysqladmin flush-tables comando cierra todas las tablas que no están en uso a la vez y marca todas las tablas en uso a ser cerradas cuando el hilo se está ejecutando actualmente acabados.Esto libera más eficaz en el uso de memoria. FLUSH TABLES no vuelve hasta que todas las mesas se han cerrado.

ps y otros programas de estado del sistema puede informar de que mysqld utiliza una gran cantidad de memoria.Esto puede ser causado por las pilas de procesos en diferentes direcciones de memoria. Por ejemplo, la versión de Solaris ps cuenta la memoria no utilizada entre las pilas de la memoria utilizada. Usted puede verificar esto comprobando intercambio disponible con swap-s . Probamos mysqld con varios detectores de fugas de memoria (tanto comerciales y de código abierto), por lo que no debe haber fugas de memoria.