REPLICACION

¿Qué es Replicación? Es un proceso de una base de datos consiste en replicar las consultas de actualización
(tanto DML como DDL) en una base de datos maestra (master) sobre una o varias bases de datos esclavas
(slave), de manera que tengamos una copia de las mismas a lo largo del tiempo.

La replicación es útil para:

a. Copia de seguridad: En condiciones normales, una base de datos replicada de forma correcta es válida
como copia de seguridad.
b. Además se puede realizar copias de seguridad usando un servidor esclavo para así no interferir al servidor
maestro.
c. Mejorar la escalabilidad: Podríamos configurar nuestras aplicaciones para balancear las consultas de
lectura (SELECT) entre los servidores replicados.
d. Podríamos usar herramientas como MySQL Proxy para balancear las consultas de lectura entre los
servidores replicados y enviar las consultas de actualización de datos al maestro.
e. Alta disponibilidad: En aplicaciones y entornos en donde sólo se requieren lecturas, podríamos configurar
nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados de
manera que si uno se cae se continúe prestando servicio.

Pasos para poner en marcha la replicación

A continuación vamos a exponer los pasos a realizar la replicación de una base de datos bd_autentia en un único
servidor esclavo. Si quisiéramos configurar más esclavos, los pasos a realizar serían los mismos sobre cada uno de
los esclavos.

Creamos de un usuario MySQL en el servidor maestro con privilegios de replicación

El servidor esclavo se autenticará frente al servidor maestro como un usuario normal. Para crear el usuario
debemos ejecutar desde la consola de comandos de mysql las siguientes sentencias SQL:

Con la sentencia anterior el usuario sólo tendría permiso de acceso desde la máquina <slave_address>, en caso de
no requerir esta medida de seguridad puedes sustituir el comodín % por el parámetro <slave_address>.

Configuración del servidor maestro

Deberemos agregar las siguientes líneas al final del archivo de configuración del servidor MySQL, por defecto:
<MySQL_HOME>/my.ini

Configuración del servidor esclavo

Deberemos agregar las siguientes líneas al final del archivo de configuración del servidor MySQL, por defecto:
<MySQL_HOME>/my.ini

Realizamos una copia de seguridad de la base de datos del maestro sobre el servidor el esclavo

Desde la consola ejecutamos los siguientes comandos:

1. [maestro]: <MYSQL_HOME>/bin/mysql -u root --password=<contraseña> -e "FLUSH TABLES WITH

READ LOCK"
Para limpiar las caches y bloquear el acceso de cualquier aplicacion a la base de datos.
2. [maestro]: <MYSQL_HOME>/bin/mysqldump --u root --password=<contraseña> --opt bd_autentia
> backup.sql
Realizamos una copia completa de la base de datos en el archivo backup.sql.
3. [esclavo]: <MYSQL_HOME>/bin/mysql --user=root --password=<contraseña> bd_autentia <
backup.sql
Para restaurar la copia de seguridad en el esclavo.
4. [esclavo]: <MYSQL_HOME>/bin/mysqladmin -u root --password=<contraseña> shutdown
Detenemos el servidor esclavo
5. [maestro]: <MYSQL_HOME>/bin/mysqladmin -u root --password=<contraseña> shutdown
Detenemos el servidor maestro (Se desbloquearán las tablas de las bases de datos previamente bloquadas)
6. [esclavo]: <MYSQL_HOME>/bin/mysqld-nt --defaults-file="<MYSQL_HOME>\my.ini" MySQL
Iniciamos el servidor el cual tomará la nueva configuración.
7. [maestro]: <MYSQL_HOME>/bin/mysqld-nt --defaults-file="<MYSQL_HOME>\my.ini" MySQL
Iniciamos el servidor el cual tomará la nueva configuración.

Probando la replicación

 En el servidor esclavo ejecute el comando SHOW SLAVE STATUS y observe que el mensaje que le muestra es
un mensaje que indica que está esperando eventos del maestro...
 Modifique algo en el maestro y verifique que instantáneamente se replica en el esclavo.
 Detenga el esclavo durante un tiempo, realicé cambios (cree tablas, modifique registros...) en el maestro e
inicie el esclavo. En cuestión de milisegundos ambas bases de datos deberían de ser iguales.
 ESPEJEO EN BASES DE DATOS

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres servidores de base de datos,
ejecutándose en equipos independientes, cooperan para mantener copias de la base de datos y archivo de registro de
transacciones (log).

Tanto el servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones,
mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los los otros
dos servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La
configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo
(Mirroring System), y el servidor primarioy espejo juntos son llamados Servidores Operacionales (Operational Servers) o
Compañeros (Partners).

Para hacer el mirror, es necesario como mínimo 2 instancias y como máximo 3. Si utilizamos 2 instancias, una de ellas
contiene la base de datos y la otra la espejo. La pega de esta configuración es que el failover no es automático y se necesita
intervención humana. Si utilizamos 3 instancias, entonces utilizamos una de ellas como witness server y permite que el
failover sea automático, o sea que cuando una caiga, la otra se ponga en marcha. Para ello el witness server se encarga de
“mirar” el estado de las 2 instancias y cuando una de ellas cae, pone la otra en marcha. Hacer el mirror son dos pasos
principales:

1. Copiar y restaurar la base de datos de la que queremos hacer el mirror desde una instancia a la otra.
2. Configurar el asistente de configuración del mirror. Vamos un ejemplo paso a paso.

Lo primero que tenemos que hacer es hacer un reflejo de nuestra base de datos en otra instancia. En nuestro ejemplo esta
base de datos se denomina prueba.

Debemos hacer copia de seguridad de la base de datos y del log (Ojo, la base de datos debe estar en modo Full) con estas
sentencias:
Backup Database Prueba to Disk=’D:\prueba.bak’;
Backup Log Prueba to Disk=’D:\logprueba.bak;
Una vez hecha la copia de seguridad, copiamos los ficheros y los restauramos otra instancia donde queremos hacer el
reflejo con estas sentencias
Restore Database Prueba from Disk=’D:\prueba.bak’ with NORECOVERY;
Restore Log Prueba from Disk=’D:\logprueba.bak with NORECOVERY;
Fijémonos que tanto la restauración del fichero de datos como el del log, son con el parámetro NORECOVERY. Esto es muy
importante porque estamos diciendo al SQL Server que restauramos la base de datos pero que no la ponga en marcha y que
la deje lista para poder aplicar más logs, o sea los logs que vendrán de la otra base de datos cuando comience el mirror.

Una vez tenemos hecha la restauración de la base de datos que queremos reflejar en la otra instancia, ya podemos
configurar el mirror. Para ello, pulsamos en la primera instancia con el botón derecho del ratón sobre la base de datos, y
seleccionamos Propiedades. En el cuadro de diálogo de las propiedades de la base de datos, seleccionamos la opción
Mirror.

Vemos que aparece un cuadro de diálogo con las opciones de configuración del mirror. Para comenzar a configurarlo,
seleccionamos el botón Configure Security.

Vemos que aparece el asistente de configuración del mirror. Lo primero que nos pregunta es si queremos utilizar un witness
server. Indicamos que sí. Después debemos indicarle que queremos configurar las 3 instancias para poder hacer el failover
automáticamente.
Seguidamente indicamos la instancia que contendrá la base de datos en sí. Fijémonos que por defecto, el asistente abre el
puerto 5022 para comunicarse con el resto de instancias. Dicho puerto y el resto que se configuran en el asistente, deben
estar abiertos en los firewalls de Windows. Fijémonos también que hemos quitado la opción de cifrado, ya que en esta
configuración, no tenemos habilitado el cifrado de la base de datos.

Seguidamente configuramos la segunda instancia que será la que contendrá el reflejo de la base de datos. Fijémonos que
por defecto configura el puerto 5023.

Por último nos queda configurar el witness server que estará en una tercera instancia. Fijémonos que por defecto configura
el puerto 5024.
Un último paso en el asistente es configurar la seguridad. Aquí debemos indicar una cuenta con permisos para acceder al
SQL Server. Por ejemplo, podemos indicar la cuenta con la que arrancan los servicios de las instancias.

Para acabar con el asistente pulsamos en Finish. El asistente se pondrá a configurar los puertos (Endpoints) en cada
instancia y acabará.
 PROBLEMAS DE SEGURIDAD COMUNES EN UNA BD
Nombre de usuario/password en blanco, por defecto o débil.
No es nada raro conseguir en el día a día pares de usuario/password como sa/1234,
está en la primera línea de defensa y un punto fundamental de la armadura de
nuestras bases de datos.
SOL. Hacer revisiones periódicas de credenciales.
Características de base de datos innecesariamente habilitadas.
Cada instalación de base de datos viene con paquetes adicionales de todas las formas
y tamaños que en su mayoría rara vez son utilizados por una sola organización. Dado
que el nombre del juego en materia de seguridad de base de datos es el de reducir
las superficies de ataque.
SOL. Las empresas necesitan buscar los paquetes que no utilizan y desactivarlos.
Esto no sólo reduce los riesgos de ataques a través de estos vectores, sino que
también simplifica la gestión de parches.

 Configuración de seguridad ineficiente.

Del mismo modo, las bases de datos tienen una gran cantidad opciones de
configuración y consideraciones diferentes a disposición de los administradores para
ajustar el rendimiento y funcionalidades mejoradas.
SOL. Las organizaciones necesitan conseguir y desactivar aquellas configuraciones
inseguras que podrían estar activadas por defecto para mayor comodidad de los DBA o
desarrolladores de aplicaciones. Las configuraciones de bases de datos en producción
y desarrollo deben ser radicalmente diferentes.

 Desbordamientos de búfer.
Un favorito de los piratas cibernéticos, las vulnerabilidades de desbordamiento de
búfer, son explotadas por las inundaciones de las fuentes de entrada con valores
diferentes o muy superiores a los que aplicación espera - por ejemplo, mediante la
adición de 100 caracteres en un cuadro de entrada pidiendo un número de Seguro
Social.
Los proveedores de bases de datos han trabajado duro para solucionar los problemas
técnicos que permiten estos ataques se produzcan. Esta es otra razón por la cual los
parches son tan importantes.
SOL. Actualizar constantemente con parches para evitar estos desbordamientos.
Bases de datos sin actualizar.
Esto podría sonar repetitivo, pero vale la pena repetirlo. Los administradores de
base de datos a veces no aplican un parche en el momento oportuno porque tienen
miedo de este dañe sus bases de datos. Pero el riesgo de ser hackeado hoy es mucho
más alto que el riesgo de aplicar un parche que descomponga la base de datos. Además
existen ante esos temores los backups y las réplicas. Quizás este punto pudo haber
sido válido hace cinco años, pero hoy en día no.
SOL. Actualizar siempre que sea posible.

 Inyecciones SQL.

 Cuando la plataforma de base de datos falla para desinfectar las entradas, los
atacantes son capaces de ejecutar las inyecciones SQL de forma similar a como lo
hacen en los ataques basados en Web, lo que les permite elevar sus privilegios y
obtener acceso a una amplia gama de funcionalidades.
Muchos de los proveedores han dado a conocer soluciones para evitar estos problemas,
pero no servirá de mucho si los parches no se aplican o no se toman los correctivos
correspondientes.

Seguridad contra el acceso no autorizado

Existen dos tipos de mecanismos de seguridad contra el acceso no autorizado:
Discrecionales, se usan para otorgar privilegios a los usuarios.
Obligatorios, sirven para imponer seguridad de múltiples niveles clasificando los
datos los usuarios en varias clases de seguridad e implementando después la política
de seguridad apropiada de la organización. Además se pueden crear cuentas de acceso
a la base de datos para los distintos usuarios, las cuales se podrían agrupar en
roles.

En una base de datos estadística no se deber permitir tener acceso a información

confidencial detallada sobre individuos específicos. En ocasiones es posible deducir
ciertos hechos relativos a los individuos a partir de consultas, lo que tampoco debe
permitirse.

Otra técnica de seguridad es el cifrado de datos.

 MODOS DE OPERACION DE UN SGBD

MySQL
¿Qué es una transacción?

“Secuencia de operaciones que se ejecutan completamente o bien no se realizan”.

 No puede quedarse en un estado intermedio.

 Ejemplo: una transferencia entre dos cuentas no puede quedarse en un estado intermedio: O se deja el dinero en la primera

cuenta o en la segunda, pero no se puede sacar el dinero de la primera cuenta, que falle algo en ese momento y no
entregarlo en la segunda.

Es una secuencia de una o varias instrucciones de SQL que forman conjuntamente una unidad lógica de trabajo. Cuando una
transacción finaliza con éxito, se graba (COMMIT). Si fracasa, se restaura el estado anterior (ROLLBACK.

Instrucciones COMMIT y ROLLBACK.

SQL acoge las transacciones de base de datos mediante dos instrucciones de procesamiento de transacciones de SQL:

 COMMIT: La instrucción COMMIT señala la conclusión con éxito de una transacción. Indica al SGBD que la transacción se ha

completado; se han ejecutado todas las instrucciones que conforman la transacción, y la base de datos es autoconsistente.

 ROLLBACK: La instrucción ROLLBACK señala el fracaso de una transacción. Indica al SGBD que el usuario no desea completar

la transacción; en lugar de ello, el SGBD debe volverse atrás de las modificaciones realizadas en las BD durante la
transacción. En efecto, el SGBD devuelve la base de datos a su estado previo al comienzo de la transacción.

Ejemplo:

mysql> CREATE TABLE t (name CHAR(20), UNIQUE (name)) TYPE = INNODB;

mysql> BEGIN;

mysql> INSERT INTO t SET name = 'William';

mysql> INSERT INTO t SET name = 'Wallace';

mysql> COMMIT; mysql> SELECT * FROM t;

+---------+
| name |
+---------+

| Wallace |

| William |

+---------+

mysql> BEGIN;

mysql> INSERT INTO t SET name = 'Gromit';

mysql> INSERT INTO t SET name = 'Wallace';

ERROR 1062: Duplicate entry 'Wallace' for key 1

mysql> ROLLBACK;

mysql> SELECT * FROM t;

+---------+

| name |

+---------+

| Wallace |

| William |

+---------+

mysql> DROP TABLE t;

mysql> CREATE TABLE t (name CHAR(20), UNIQUE (name)) TYPE = INNODB;

mysql> SET AUTOCOMMIT = 0;

mysql> INSERT INTO t SET name = 'William';

mysql> INSERT INTO t SET name = 'Wallace';

mysql> COMMIT;

mysql> SELECT * FROM t;

+---------+

| name |

+---------+

| Wallace |

| William |

+---------+

Oracle

COMMIT

Para dejar los cambios echos permantentes en una transaccion utiliza COMMIT statement.
La sintaxis de COMMIT Statement es

COMMIT [WORK] [COMMENT ‘your comment’];

WORK es opcional.
COMMENT es opcional, especifica cuando quieres identificar una transaccion en el diccionario de datos.
DBA_2PC_PENDING.

Ejemplo
insert into emp (empno,ename,sal) values (101,’Abid’,2300);
commit;

ROLLBACK
To rollback the changes done in a transaction give rollback statement. Rollback restore the state of the database to the last
commit point.

Ejemplo:
delete from emp;
rollback; /* undo the changes */