Log Shipping

Objetivos

Implementar un Log Shipping

Contenido

Leccion 1: Sobre el Log Shipping
Leccion 2: Inicializando el Log Shipping
Leccion 3: Diseñando estrategia de de conmitacion de errores y recurepacion.

Leccion 1

Escenarios de Log Shipping

Que es Log Shipping
Proporciona un medio para mantener un servidor secundario de forma automatizada con una cadena de copias de seguridad del registro de transacciones

También le permite configurar un servidor de supervisión que pueda verificar la salud

 

Cuadrantes de Escenarios

-XY: Informe de activades de descarga
XY: Inicialización de base de datos en espejo
-X-Y: Actualizando versiones para migrar a una nueva plataforma
X-Y: Habilitar una solucion primaria o secundaria

Cuadrante -XY

1. Modo Standby
2. Reporting Services
3. Sentencias de Select

Usted puede utilizar el log shiping para mantener un servidor de informes.

En lugar de restaurar copias de seguridad del registro de transacciones con la opción de No Recovery Option, se puede especificar en Standby en su lugar. Las bases de datos restauradas en Standby Mode habilitar las conexiones, así como las sentencias SELECT que se publicará.

Las operaciones de restauración no se les permite, mientras que las conexiones a la base de datos existe. Para reducir al mínimo el tiempo de inactividad, la base de datos secundaria debe tener una latencia muy poco con los database.Estos son los principales  requisitos a considerar, descartar modo de espera como una opción de alta disponibilidad.

 

Cuadrante XY

1. Minimizar los tiempos
2. Respaldo del principal (director)
3. El principal y el secundario son sincronizados

De inicializar la creación de reflejo de base de datos de copias de seguridad de la principal. Después de todo las copias de seguridad de las principales son restauradas, y el director y el espejo se sincronizan, iniciando la sesión de reflejo de base de datos requiere sólo uno o dos segundos. Un ejemplo muy común de la inicialización de una sesión de reflejo de base de datos es utilizar el trasvase para obtener el espejo principal y muy cerca en el tiempo de modo que sólo unos segundos son necesarios para que la base de datos en línea de reflejo sesión. Esto minimiza el tiempo requerido para iniciar el reflejo de base antes de que las aplicaciones pueden seguir para procesar transacciones.

 

Cuadrante -X-Y

1. Mover las bases de datos
2. Construir una nueva instancia
3. Una breve interrupcion con la aplicación.

 

Un lado a lado de actualización es muy similar a la migración a una nueva plataforma. En ambos casos, se construye la nueva instancia y luego mover las bases de datos. Si usted necesita para reducir al mínimo el tiempo de inactividad de las aplicaciones, puede utilizar el trasvase de registros de aplicar una cadena de registros de transacciones a la nueva instancia. Luego, bastaría con una breve interrupción en las aplicaciones, mientras que el resto de las copias de seguridad de registro de transacciones se aplican antes de las aplicaciones se puede cambiar a la nueva instancia.

 

Cuadrante X-Y

1. Que las aplicaciones puedan alternar
2. Bases de datos secundarias
3. Una interrupcion en la base de datos principal

El ámbito de aplicación de envío de registro se limita a una base de datos

SQL Server no permite transacciones multi base

el trasvase de registros se rompe esta integridad en bases de datos múltiples

 

 

Componentes de Log Shipping

 

Modo Standby Secundaria (sentencias SELECT) o ninguna recuperación. No puede restaurar registros de transacciones cuando los usuarios se conectan a la base de datos, por lo que no se debe utilizar el modo de espera para la alta disponibilidad de arquitecturas.

El servidor de supervisión, que es opcional dentro de una arquitectura de trasvase de registros, contiene un conjunto de trabajos que envían alertas cuando la sesión de trasvase de registros que se consideren fuera de sincronía.

 

 

 

 

Tipos de Log Shipping

1. Store Procedure and Tables
2. SQL Server Agent jobs
3. Copy the backups and execute a restore

Leccion 2: Inicializacion Log Shipping

Inicializacion de Log Shipping

1. Crear un recurso compartido en tanto primaria como secundaria, porque las copias de seguridad necesitan ser accedidos a través de servidores.
2. Crear puestos de trabajo para copias de seguridad de registros de transacciones, registros de copia a la secundaria, y restaurar los registros.
3. Restaurar una copia de seguridad completa de la base de datos secundaria.
4. Restaurar todos los registros de transacciones posteriores.
5. Poner en marcha los trabajos para automatizar la recuperación de los registros.
6. Copie todos los objetos de instancia en la que la base de datos secundaria depende en aplicaciones de servicio.

Creando un Job

Hay dos herramientas para crear los puestos de trabajo que se utilizan para ejecutar el trasvase de registros: Microsoft SQL ServerManagement Studio (SSMS) o Transact-SQL.

Tres puestos de trabajo se crean al configurar el trasvase de registros:

• La tarea de respaldo
• El trabajo de copia
• La tarea de restauración

La tarea de copia de seguridad siempre se ejecuta en el primario. La tarea de restauración siempre se ejecuta en el secundario.
El trabajo de copia se puede ejecutar en el primario o el secundario. El trabajo de copia también se suele configurar para ejecutarse en el secundario.

Restaurando un Respaldo

Durante la configuracion

Generalmente, no se recomienda tener el trasvase de registros generar una copia de seguridad completa.
Esto puede tener un impacto muy grande en un entorno existente, sobre todo si tiene bases de datos de más de alrededor de 10 gigabytes (GB) de tamaño.

El proceso de inicialización de envío de registro es la siguiente:

1. Copie la última copia de seguridad completa de la secundaria y restaurar dejando la base de datos, ya sea en el modo sin recuperación o modo de espera
2. Copiar y restaurar el último respaldo diferencial al secundario, dejando la base de datos ineither No Modo de recuperación o modo de espera.
3. Copiar y restaurar las copias de seguridad del registro de transacciones desde la última diferencial, dejando la base de datos, ya sea en el modo sin recuperación o modo de espera.
4. Desactive el trabajo existente para respaldar los registros de transacciones.
5. Copiar y restaurar las copias de seguridad de registro de transacciones adicional al secundario
6. Inicie el trasvase de registros

 

El plan de mantenimiento crea un conjunto de copias de seguridad del registro de transacciones, y los trabajos de trasvase de registros crear otro conjunto de copias de seguridad del registro de transacciones. Cada juego es sólo una parte de lo que necesita ser restaurado.

Antes de configurar el trasvase de registros, debe cambiar los planes de mantenimiento que realizan copias de seguridad de registro de transacciones de excluir a la base de datos primaria.

Copias de seguridad completas y diferenciales no afectan el trasvase de registros

 

Planes de Mantenimiento

 

Antes de configurar el trasvase de registros, debe cambiar los planes de mantenimiento que realizan copias de seguridad de registro de transacciones de excluir a la base de datos primaria.
Copias de seguridad completas y diferenciales no afectan trasvase de registros.

Copiando Objetos a nivel de Instancia

Los objetos que existen a nivel de instancia son necesarios para una aplicación funcione si necesita conmutar por error a la secundaria.

Objetos de Seguridad

SSIS tiene una tarea que se puede utilizar para transferir los inicios de sesión de una instancia a otra

Servidores Ligados

Paquetes de SSIS

Cualquier paquete SSIS que dependen de la base de datos principal tiene que ser re-creado en el secundario.
Tenga cuidado para asegurar que las dependencias cruzadas se eliminan de estos paquetes

Endpoints

Cualquier extremo que se usan con la base de datos primaria necesario volver a crear en el secundario.
Para controlar el acceso a la secundaria, cada uno de estos criterios de valoración debe ser configurado con STATE = DETENIDO.

Agente SQL Server

Cualquier trabajo que dependen de la base de datos principal tiene que ser re-creado en el secundario (categorías, horarios, operadores, alertas).
Cada uno de estos puestos de trabajo deben ser desactivados para asegurar que los trabajos no se ejecutan.

DDL Triggers

A nivel de instancia desencadenadores DDL necesario volver a crear en el secundario

Replicacion

Tras la conmutación por error a la secundaria, es necesario planificar en la reconfiguración de la arquitectura de replicación después de la secundaria está en línea (editor, suscriptor y distribuidor).

Leccion 3: Diseñando estrategia de de conmitacion de errores y recurepacion.

Log Shipping Failover

La detección de fallos y conmutación por error de proceso son operaciones manuales.

El proceso general para que conmute a un secundario es la siguiente:

1. Restaurar, ningún registro de transacciones, para hacer el secundario lo más actualizada posible
2. Restaurar el último registro de transacciones con la opción WITH RECOVERY
3. Ejecute ALTER LOGIN, para cada inicio de sesión de SQL Server en el secundario para volver a asignar los usuarios a inicios de sesión de base de datos correspondientes.
4. Si es necesario, inicie ningún extremo
5. Compruebe los permisos de seguridad
6. Cambiar las cadenas de conexión para aplicaciones para apuntar a la secundaria
7. Iniciar los trabajos que sean necesarios, tales como el trabajo para iniciar la copia de la base de datos

Usted, vuelva a habilitar el trasvase de registros, con el primario original que se está relegado a un segundo.
Esto restablece la redundancia a través de trasvase de registros sin incurrir en un corte de luz adicional a la aplicación.
Después de que el principal original se repara y vuelve a conectar, vuelva a habilitar el trasvase de registros, con el principal original de ser degradado a una secundaria. Esto restablece la redundancia a través de trasvase de registros, sin incurrir en una interrupción adicional a la aplicación.
Log Shipping Failback

Cuando el servidor no se repara y vuelve a conectar, debe asumir la función de espera.

Una conmutación por recuperación al primario original debe ocurrir sólo por dos razones:

• Dictados de Gestión, que las aplicaciones se ejecutan en un servidor particular.
• Tolerancia de rendimiento o fallos se degrada cuando la aplicación está conectada al secundario.

Puede hacerlo con un mínimo de tiempo de inactividad de las aplicaciones mediante los pasos siguientes:

1. Reinicializar el primario con una copia de seguridad desde el modo de espera, asegúrese de especificar la opción de recuperación No.
2. Aplicar la copia de seguridad diferencial de base de datos más reciente y las copias de seguridad de registro de transacciones adicional al primario, especificando la opción de recuperación no para todos restauraciones.
3. Copie todos los objetos de instancia que ha creado o cambiado en el modo de espera, de vuelta a la primaria.
4. Continúe repitiendo el paso 2 hasta que, usted está preparado para cambiar de aplicación de nuevo a la primaria.
5. Detener el registro de transacciones tarea de respaldo en el primario
6. Desconecte todas las aplicaciones desde el modo de espera y evitar el acceso al desactivar los inicios de sesión utilizando el siguiente comando: ALTER LOGIN DISABLE <loginname>;
7. Realice una copia de seguridad del registro de la última transacción en el modo de espera
8. Restaurar el último registro de transacciones a la principal mediante la opción WITH RECOVERY
9. Reconfigurar las aplicaciones para conectarse a la primaria.
10. Elimine la configuración de trasvase de registros desde el modo de espera
11. Vuelva a crear la configuración de trasvase de registros en el primario y reiniciar el modo de espera
12. Habilite los inicios de sesión en el modo de espera.

Una alternativa automatizada a los cuatro primeros pasos de este proceso es la creación de trasvase de registros, desde el modo de espera, de vuelta a la primaria.