viernes, 3 de mayo de 2013

Replicacion

¿Que es Replicacion?
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:
  1. Copia de seguridad:En condiciones normales, una base de datos replicada de forma correcta es válida como copia de seguridad.
    Además se puede realizar copias de seguridad usando un servidor esclavo para así no interferir al servidor maestro.
  2. Mejorar la escalabilidad:Podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados.
    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.
  3. 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 continue 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 quisieramos 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 comodin % por el parámetro <slave_address>.

Configuración del servidor maestro

Deberemos agregar las siguientes lineas 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 lineas 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 instantaneamente se replica en el esclavo.
  • Detenga el esclavo durante un tiempo, realize cambios (cree tablas, modifique registros..) en el maestro e inicie el esclavo. En cuestion de milisegundos ambas bases de datos deberían de ser iguales.

video:

fuentes:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=mysql_replicacion

lunes, 29 de abril de 2013

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 instancia 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, osea 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, osea 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á.
fuentes
 
 

viernes, 26 de abril de 2013

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, esta el 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 dia 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últiplesniveles clasificando los datos los usuarios en varias clases deseguridad e implementando después la política de seguridadapropiada de la organización. Además se pueden crear cuentas de acceso a la basede datos para los distintos usuarios, las cuales sepodrí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 apartir de consultas, lo que tampoco debe permitirse.
Otra técnica de seguridad es el cifrado de datos.


 
fuentes

martes, 16 de abril de 2013

Indices

Indices
Un índice es un archivo usado para agilizar la recuperación de los registros.

Es redundante puesto que la información que almacena se encuentra en el archivo al cual indexa.

La ventaja, sin duda, viene por la vía de recuperar los registros de manera más rápida.


Tipos de índices
Existen diversos criterios para identificar los distintos tipos de índices, algunos de éstos son:

 Campo de indexación: según el campo usado para construir el índice, éste se llamará primario, de grupos o secundario.

a) índice primario (principal) : se construye sobre el campo clave de ordenamiento de un archivo ordenado de registros.

b) índice agrupado (clusterizado): se construye sobre un campo de ordenamiento que abarca varios registros con el mismo valor, dentro de un archivo ordenado de registros.

c) índice secundario: se construye sobre un campo que no se utiliza para ordenar el archivo.

Número de referencias: si el índice tiene una entrada por cada registro del archivo se denomina denso, en caso contrario, dicho índice se llama no denso o disperso.

Tipo de referencias: si la entrada en el índice contiene un puntero físico al
área de datos, es decir, un puntero que indica la dirección física de un registro en el disco, el índice se llama físico.

Estructura de las referencias: las referencias al área de datos se pueden estructurar como;

a) entrada de largo fijo, con un puntero al área de datos (bloque oregistro).

b) registros de largo variable en el índice, con un campo repetitivo que permita almacenar un puntero a cada bloque de disco que contiene un registro. Este esquema se llama archivo o lista invertida.

c) mantener entradas en el índice de largo fijo y tener una única entrada por cada valor del campo de indexación, pero creando un nivel extra de indirección para manipular los múltiples punteros.

d) entradas en el índice de largo fijo y tener un bitmap asociado acada una de ellas, el cual tenga un bit por cada bloque del archivo de datos; el bitmap guarda un valor 1 en los bits de los bloques que contiene un registro con el valor de la entrada, y un valor 0 en caso contrario.

jueves, 11 de abril de 2013

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 */