5.1 ESPEJEO(MIRRORING)
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.
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.
5.2 REPLICA(REPLICATION)
La Réplica de Mezcla, además de hacer el back-up de la Base de Datos del
Servidor (comúnmente por razones de seguridad), es capaz de brindar el mismo
servicio que ofrece el Servidor a los clientes, cuando éste por cualquier
motivo se encuentre de baja en las conexiones.
La réplica además de suplirlo en la conexión de una forma completamente
invisible para el Cliente, es a la vez, totalmente capaz de enviarle todas las
modificaciones que la base de datos haya sufrido en su ausencia, cuando éste
entra de nuevo a su papel de servidor central.
Tipos
de replicación
- Replicación
de Instantáneas
También conocida como replicación estática. Copia y
distribuye datos y objetos de base de datos exactamente como aparecen en
el momento en el que ocurren.
Características
- Los
cambios de datos en el subscritor no son actualizados continuamente.
- El
Subscritor actualiza los datos de forma completa y no de forma
transaccional.
¿Cuándo usarla?
- Datos/objetos
son estáticos o no cambian con frecuencia.
- La
cantidad de datos a ser replicados es pequeña.
- Los
usuarios trabajan desconectados, no siempre interesa la última
información.
- Replicación
Transaccional
También conocida como replicación dinámica.
Las modificaciones de la publicación en el publicador son propagadas al
subscritor de forma incremental.
Características
- Publicador
y subscritor siempre están sincronizados.
- Las
Transacciones son preservadas; Ej. si son modificados 5 registros de
datos, siempre serán los 5 registros propagados al subscriptor o no serán
propagados.
- El
publicador y el suscriptor deberán siempre estar conectados.
¿Cuándo usar la Replicación Transaccional?
La información que se replica será utilizada solo
de lectura. La información de ventas e inventarios de una Central son
replicados a las Sucursales.
El subscriptor siempre necesita la última
información
- Replicación
de Mezcla
Provee las ventajas de ambas replicaciones
anteriores. La instantánea inicial se aplica a los suscriptores; se hace un
seguimiento de los cambios realizados en los datos publicados en el publicador
y en los suscriptores. Los datos se sincronizan entre los servidores a una hora
programada o a petición.
Características
- Actualiza
los datos haciendo independiente a más de un servidor.
- Los
datos son mezclados basados en un calendario o en la demanda.
- Permite
a los usuarios trabajar online/offline y sincronizar más adelante las
modificaciones de datos realizadas en un resultado único y uniforme.
¿Cuándo usar la Replicación de Mezcla?
- La
autonomía del sitio es un factor crucial.
- Múltiples
subscriptores necesitan actualizar datos en diferentes ocasiones y
propagar los cambios al publicador y a otros suscriptores; los
suscriptores necesitan recibir datos, realizar cambios sin conexión y
sincronizar más adelante los cambios con el publicador y otros
suscriptores
Requisitos y consideraciones para el uso de la
replicación con la creación de reflejo de la base de datos
Se deben tener en cuenta los siguientes requisitos
y consideraciones al utilizar la replicación con la creación de reflejo de la
base de datos:
- Las
entidades de seguridad y reflejada deben compartir un distribuidor. Se
recomienda que éste sea un distribuidor remoto, ya que proporciona mayor
tolerancia a errores si se produce una conmutación por error imprevista en
el publicador.
- La
replicación admite la creación de reflejo de la base de datos de
publicación en la replicación de mezcla y en la replicación transaccional
con suscriptores de solo lectura o suscriptores de actualización en cola.
No se admiten suscriptores de actualización inmediata, publicadores de
Oracle, publicadores en una topología punto a punto ni republicación.
- Los
metadatos y los objetos que existen fuera de la base de datos, incluidos inicios
de sesión, trabajos, servidores vinculados, etc., no se copian en la
entidad reflejada. Si se requieren los metadatos y los objetos en la
entidad reflejada, se deben copiar manualmente. Para obtener más
información, vea Administración de inicios de sesión y trabajos tras la
conmutación de roles (SQL Server).
Configurar la replicación con la creación de
reflejo de la base de datos
La configuración de la replicación y la creación de
reflejo de la base de datos implican cinco pasos. Cada paso se describe en
detalle en la siguiente sección.
- Configurar
el publicador
- Configurar
la creación de reflejo de la base de datos
- Configurar
la entidad reflejada de manera que utilice el mismo distribuidor que la
entidad de seguridad
- Configurar
los agentes de replicación para la conmutación por error
- Agregar
las entidades de seguridad y reflejada al Monitor de replicación
El orden de los pasos 1 y 2 se puede invertir.
- Crear
una base de datos en la máquina –replica (Practica)
Se crea una base de datos en la máquina que se
utilizara como Réplica, la cual debe dejarse, totalmente vacía, ya que es, en
esta Base de Datos en donde se replicaran todas las tablas de la BD del
Servidor.
- Replicación
de la base de datos del servidor a la réplica.
Con la publicación y la suscripción se debe poder
visualizar las tablas replicadas de la base de datos que se encuentra en el
Servidor, para el ejemplo, se debe visualizar la tabla personal y sus tuplas,
dentro de la base REPLICACION en la réplica.
Se dispone a ver los datos en la base de datos
REPLICACION, de la maquina réplica.
Desde la máquina réplica, se agregaran nuevos
datos, los cuales tienen que verse reflejados en el servidor. Para lo cual se
deben esperar 60 segundos, en lo que las actualizaciones se hacen
efectivas entre ambos servidores.
Ahora se pueden comprobar los datos en la maquina
servidor.
Como se puede observar los códigos entre las tuplas
agregadas desde el servidor y de la réplica no llevan un orden
correlativo, pero esta característica es propia entre la replicación de SQL.
El mismo procedimiento se debe de seguir para el
caso de cuando se quiere eliminar datos de la base de datos, e igualmente
se deben reflejar los cambios entre ambos servidores. Los cuales también han
sido eliminados de la maquina replica.
Beneficios de la
réplica de Datos en un DBMS
- Disponibilidad.- El modo en que la replicación
incrementa la disponibilidad de los datos para los usuarios y
aplicaciones.
- Fiabilidad.- Al haber múltiples
copias de los datos disponibles en el sistema, se dispone de un mecanismo
excelente de recuperación cuando existan fallos en nodos.
- Rendimiento.- Se mejora para las
transacciones de consulta cuando se introduce la replicación en un sistema
que estuviera aquejado de sobrecarga de recursos centralizados.
- Reducción
de la carga.- Modo
en q se utiliza la replicación para distribuir datos en ubicaciones
remotas.
- Procesamiento
Desconectado.- Modo
en que la replicación puede implementarse mediante mecanismo instantáneas.
- Soporta
muchos usuarios.- Se puede crear múltiples instantáneas personalizadas que
satisfagan los requisitos de cada usuario o grupo de usuarios del sistema.
- Soporta
Aplicaciones Avanzadas.- Para OLPT(Online transaction
Processing), OLAP(Online Analitical Processing)
Archivo de log
Ø Identificador de la transacción
Ø Hora de modificación
Ø Identificador del registro afectado
Ø Tipo de acción
Ø Valor anterior del registro
Ø Nuevo valor del registro
Ø Información adicional
Checkpoint
Técnicas basadas en el registro histórico
Paginación en la sombra o páginas en espejo
Técnica de Recuperación Aries
Elementos y frecuencia de respaldo
Secuencia de registros que mantiene un rastro de las actualizaciones realizadas a la BD.
Registros de inicio de Tx, Registros de compromiso de una Tx, Registros de aborto de una Tx, Registros de actualización de una Tx:
Debe estar guardado en almacenamiento estable.
Se clasifican en:
Ø _ Técnica de actualización diferida
Ø _ Técnica de actualización inmediata
Retarda la actualización en la BD hasta que la transacción se compromete
(commit) parcialmente.
La base de datos se divide en un número determinado de bloques de tamaño fijo (páginas).
En memoria volátil se mantiene la tabla actual y en memoria estable una
tabla doble (sombra).
La idea principal es mantener dos tablas de páginas durante la vida de
una transacción.
Comandos para respaldo de datos
Para hacer una copia de respaldo de una base de datos se recomienda crear un dump.
Para hacer un dump de todas las bases de datos es necesario ejecutar el comando:
mysqldump --user=****** --password=****** -A > /Ruta/Hacia/archivo_dump.SQL
Para hacer un dump de sólo algunas bases de datos es necesario ejecutar el comando:
mysqldump --user=****** --password=****** db_1 db_2 db_n> /Ruta/Hacia/archivo_dump.SQL
Para hacer un dump de todas las tablas de una base de datos es necesario
ejecutar el comando:
mysqldump --user=****** --password=****** db >
/Ruta/Hacia/archivo_dump.SQL
Para hacer un dump de sólo ciertas tablas de una base de datos es
necesario ejecutar el comando:
mysqldump --user=****** --password=****** db --tablas tab1 tab2 >
/Ruta/Hacia/archivo_dump.SQL
Para cada uno de estos comando es necesario indicar un usuario (user) y
la contraseña (password) con derechos de administrador en la base de datos.
Restauración
Para restaurar un dump tan sólo hay que ejecutar el comando:
mysql --user=****** --password=****** db_nom <
/Ruta/Hacia/archivo_dump.SQL
5.4 METODOS DE RECUPERACION DE UN SGBD
La recuperación consiste en tres pasos principales:
Análisis: Identifica las páginas sucias y el conjunto de
transacciones activas en el momento de la caída y el punto del log apropiado
para empezar la operación REHACER
Rehacer: se replican las operaciones del
log.
Deshacer: Se recorre el log hacia atrás
y se deshacen las transacciones activas en el momento de la caída, o iniciadas
después, de las que no se ha encontrado confirmación.
Recuperación en Oracle Red Log Files:
dos o más archivos donde se registra cualquier modificación transaccional de
una memoria intermedia de la BD.
Archivos de control: metadatos
necesarios para operar en la base de datos, incluyendo información sobre copias
de seguridad. Segmento
Rollback: guarda las últimas sentencias
realizadas sobre la BD y sabe cuándo se ha confirmado o no una transacción. En
la Recuperación de un fallo: Recupera los datos con REHACER (Desde Redo Log
File).
Deshace las transacciones no
comprometidas con Deshacer (Desde el segmento de rollback).
Técnica de recuperación de
aires
Representa a los métodos actuales de recuperación.
Ø Usa números de secuencia del registro histórico (NSR) para
implementar varias optimizaciones que reducen el tiempo de recuperación.
Ø Estrategia robar/no forzar para la escritura en disco:
Ø Escritura anticipada en el log.
Ø Repetición de la historia.
Ø Anotación en el log de las modificaciones durante el deshacer
La recuperación consiste en tres pasos principales:
Ø Análisis: Identifica las páginas sucias y el conjunto de
transacciones activas en el momento de la caída y el punto del logapropiado
para empezar la operación REHACER
Ø Rehacer: se replican las operaciones del log.
Ø Deshacer: Se recorre el log hacia atrás y se deshacen las
transacciones activas en el momento de la caída, o iniciadas después, de las
que no se ha encontrado confirmación.
Ø
Comandos para recuperación
Mantenimiento y monitoreo de la base
|
Actividad |
Comando |
|
Revisar el estado de las tablas |
show table status; |
|
Los procesos que están ejecutándose |
show processlist; |
|
Variables con las que se está ejecutando la instancia |
show variables; |
|
Estado actual de innodb; |
show innodb status; |
Respaldos
La manera usual de hacer un respaldo es usando el comando mysqldump, que
posee muchas opciones que permiten duplicar todas las base, una base en
particular, una tabla, solo los datos, solo la estructura, etc.
Para obtener un respaldo completo de una base
[digital@pcproal digital]$
mysqldump --opt -u carlos -p prueba > prueba.bak
Para restaurar un respaldo completo de una base
[digital@pcproal digital]$
mysql -u carlos -p prueba < prueba.bak
Otra manera de hacer respaldos es através del comando "select
into" y restaurar los datos con "mysqlimport" o "load data
infile".
Redo Log Files: dos o más archivos donde se registra cualquier
modificación transacción al de una memoria intermedia de la BD.
Archivos de control: metadatos necesarios para operar en la Base de
Datos, incluyendo información sobre copias de seguridad. Guían la recuperación.
Segmento Rollback: guarda las últimas sentencias realizadas sobre la BD
y sabe cuándo se ha confirmado o no una transacción.
Procedimiento de Escritura:
1. Cuando se inicia una transacción ambas tablasson iguales.
2. Cuando se actualiza una página, se escribe la página actualizada en
una página no usada, y se actualiza la tabla actual para apuntar a ésta
(dejando la “sombra” sin modificar).
3. Cuando se confirma la transacción, la tabla depáginas actual pasa a
almacenamiento no volátil (se cambian las direcciones de las tablas).
4. Si se produce un fallo, la tabla “sombra” se copia en la “actual”.
5. No es necesario ni rehacer ni deshacer.
Aplicación de cada método
Ejemplo de recuperación de aires
En la fase REHACER, empezando desde el mínimo NSD en la tabla de páginas
sucias(min(NSD)=1)) se rehacen las actualizaciones del log (en este caso
NSD=1, 2, 6).
En la fase DESHACER, se deshacen las actualizaciones del log de las
transacciones no confirmadas (T3) (i.e.NSD=6).
Recuperación postgresql
Ø Recuperación basada en WAL (Write – AheadLogging) con
fases de Rehacer y Deshacer similares a Aries.
Ø El directorio pg_xlog contiene los diarios de escritura
adelantada (WAL).
Ø Un archivo pg_clog registra el estado actual de cada
transacción
5.5 MIGRACION DE LA BASE DE DATOS
La
migración de bases de datos es generalmente una tarea compleja que no sólo
supone transferir datos entre tipos de almacenaje y formatos de un servidor de
base de datos a otro; sino que también supone reescribir sentencias SQL o
incluso procedimientos (SPL) de lógica de negocio. En comparación con los esquemas
estándares de migración a mano, ofrecemos una potente gama de herramientas
desarrolladas de probada eficacia en complejos módulos de bases de datos
relacionales. Estas herramientas y nuestros especialistas pueden asegurar que
las transiciones de las bases de datos se realicen perfectamente,
independientemente de la naturaleza del sistema. Desde la experiencia, estamos
familiarizados con la complejidad, el coste que supone una larga migración de
bases de datos y los problemas que aparecen durante el proceso cuando se
emplean métodos inapropiados; ya que siempre comprobamos con los clientes
potenciales que el uso de nuestras herramientas y métodos pueda ofrecer una
ventaja significativa.
HERRAMIENTAS DE
MIGRACIÓN
En
comparación con la consultoría estándar de migraciones, la cual puede ofrecer
poco más que soporte a la base de datos, nosotros tenemos gran experiencia en
escribir grandes aplicaciones para empresas en sintaxis de la base de datos
nativa y cross. Además, enseñamos a los equipos de las empresas una metodología
y les proporcionamos una potente gama de herramientas para reducir costes y
optimizar el proceso de migración.
Los
conceptos esenciales de la migración describen cambios realizados en el soporte
para el desarrollo de aplicaciones, cambios el soporte de nuevas funciones,
funciones no soportadas y funciones en desuso que pueden afectar a las
aplicaciones de base de datos, scripts y herramientas.
Migración
de aplicaciones de BD dentro de DB2
Cambios
en el soporte de los sistemas operativos
Cambios
en los controladores de las aplicaciones
Cambios
en el soporte del software de desarrollo
Cambios
en las API de DB2 y en los mandatos de DB2
Cambios
en la sintaxis de las sentencias de SQL
Cambios
en las vistas y rutinas administrativas de SQL y en las vistas de catálogo
Paquetes
de base de datos
Cambios
en el soporte de 32 bits y 64 bits
Cambios
en el comportamiento del servidor DB2
Soporte
de conectividad de clientes DB2
No hay comentarios:
Publicar un comentario