实现数据库镜像

关键词：

Olá Pessoal,
Neste artigo vou falar sobre Database Mirror, uma nova funcionalidade do SQL Server 2005 para alta disponibilidade.Database Mirror consiste em basicamente um espelhamento de um banco de dados, uma solução que fornece quase em tempo real failover a nível de banco de dados,sem qualquer necessidade de compatibilidade de hardware e baixo custo.

Com o failover fornecido pelo Database Mirror é possível subir uma segunda base de dados de forma automática em menos de 3 segundos,tudo isso transparente para a aplicação.
É sem dúvida uma solução fantástica, de qual representa uma ótima justificativa para uma migração a partir de uma versão anterior.

Com o Database Mirror é espelhado todo o banco de dados para um separado servidor, uma cópia completa quer será mantida e atualizada em tempo real utilizando a tecnologia Copy-on-Write (Cópia na Escrita).Como toda solução existem custos que devem ser levados em consideração como o volume de espaço em disco no segundo servidor deve ser equivalente ao servidor principal.

Database Mirror trabalha através do Transaction Log do banco de dados principal (O banco de dados de qual terá seus dados espelhados). Para implementar o database mirror é preciso configurar o banco de dados para o Recovery Model Full,onde as entradas do Transaction Log são copiadas imediatamente para o banco de dados espelho a cada nova alteração nos dados,uma vez a transação é confirmada no banco de dados espelho este emite um aviso ao banco de dados principal e assim a transação é confirmada e completa.
Repare que com a cópia da transação para o banco de dados espelho cria uma certa proteção da informação,de forma que a cada alteração ou inserção é mantido cópias redundantes em ambos servidores.Esta é a tecnologia Copy-on-Write!

Em um cenário típico do Database Mirror existem basicamente três componentes que são eles:

Principal Database Server: É o servidor na qual armazena o banco de dados principal, ou seja, de qual terá suas informações espelhadas. É possível espelhar mais de um banco de dados da mesma instancia para outra instancia SQL Server, mas não é possível espelhar um banco de dados para outro na mesma instancia.

Mirror Database Server: É o servidor na qual armazena o banco de dados espelho, ou seja, o banco de dados que atuará como standby do servidor principal, recebendo transações. O Mirror Database permanece em estado de Restore e não pode ser acessado diretamente, pelo fato deste permanecer sempre recebendo registros de transações a partir do Principal Database.

Witness Database Server: É um opcional servidor que será a testemunha (Witness) na qual ficará monitorando caso tenha alguma falha no servidor principal, este ajudará tomar a decisão de realizar o failover para o servidor mirror. Quando ocorre alguma falha no servidor principal o servidor mirror e o servidor witness percebem a falha e juntos decidem que o servidor mirror deve substituir o servidor principal, assumindo a regra de servidor principal, respondendo requisições da aplicação.


Sem o servidor Witness não existe o failover automático, no momento da falha o servidor mirror percebe que a conexão com o servidor principal foi perdida, mas não pode tomar a decisão de assumir a regra de principal sozinho, desta forma o failover deve ser manual, a partir do servidor mirror.
A ilustração a seguir demonstra os componentes citados acima:


1. Uma transação é escrita através da aplicação para o transaction log do banco de dados AdventureWorks no servidor principal.

2. Imediatamente esta transação é copiada para o transaction log do banco de dados do servidor mirror, este então confirma a transação e envia para o servidor principal uma confirmação de escrita com sucesso.

3. Apos receber a confirmação do servidor mirror, o servidor principal confirma a transação em seu transaction log e retorna o aviso de confirmação para a transação.
O Database Mirror pode ser configurado para executar em modos de operação de quais podem priorizar a performance da aplicação ou segurança dos dados.Os modos de operação são high availability,high-protection e high-performance.Cada modo de operação opera de acordo com as configurações abaixo.
Synchronous operations (Operações Síncronas): Com operações síncronas a transação é confirmada em ambos os parceiros de replicação, banco de dados principal e mirror, claro que com este modo de operação irá gerar um custo adicional na transação pois que a transação somente é completada quando esta é confirmada em ambos os parceiros.O modo High-availability e high-protection usam operações síncronas.
Asynchronous operations (Operações Assíncronas): Com operações assíncronas a transação é confirmada no banco de dados principal sem esperar que o banco de dados no servidor espelho escreve a transação para seu log de transação no disco. Com esse modo de operação a performance da aplicação é melhorada,já que a transação não precisa do custo adicional de confirmar em ambos servidores para completar,porém temos uma falta de segurança na informação.O modo de High Performance utiliza este modo de operação.Para finalizar o nosso conceito sobre Database Mirror,precisamos entender os tipos de Failover disponíveis e seus requisitos.
Failover Automático: O Failover Automático é necessário o ambiente de três instancias de quais desempenham as três regras de Principal Server, Mirror Server e Witness Server, com o Failover automático caso aconteça um problema com a instancia principal o Mirror Server assume o papel de Principal de forma automática, sem intervenção humana, isto é o modo de High Availability.
Failover Manual: O Failover Manual é composto apenas das instancias Principal Server e Mirror Server, sem a o servidor Witness e com o modo de operação síncrona, a alteração da regra deve ser manual. Isto é o modo de High Availability e High Protection.
Forced Service: Serviço forçado é quando ocorre alguma falha com o servidor principal, mas o servidor mirror não esta disponível, porém os dados não estão totalmente sincronizados. Com isso é preciso forçar a alteração da regra para o servidor mirror, isso significa perca de dados, pois as transações não estão sincronizadas. Isto é o modo high-protection ou high-performance.Configurando o Database Mirror.
Agora que já vimos os conceitos e componentes associados ao Database Mirror, vamos entender e configurar nosso ambiente.A conexão entre os servidores envolvidos no Database Mirror é feita através de Endpoints, para os endpoints atribuímos uma conta de serviço do Windows para sua autenticação, caso estejamos em um ambiente com um domínio do Active Directory poderíamos criar uma conta exclusiva para os endpoints e utilizar esta de qual seria válidas em todos os servidores.

No nosso exemplo, iremos configurar uma conta de usuário local do Windows de qual será exclusiva para os endpoints em todos as três instancias.Atribuiremos portas diferentes para os endpoints em cada instancia.
Devemos verificar também se em todas as nossas instancias estar aplicado o Service Pack 1 ou superior,pois este é requerido pelo Database Mirror.

Em nosso exemplo usaremos as edições Enterprise Edition, o Database Mirror somente é suportado nas edições Enterprise, Standard e Develop. A edição Workgroup e Express não são suportadas, somente desempenhando a regra de servidor Witness.Criaremos um banco de dados de teste chamado Livraria.
A ilustração abaixo resume as configurações do nosso ambiente:



O Servidor Server01 atuando

Olá Pessoal,
Neste artigo vou falar sobre DATABASE Mirror, uma nova funcionalidade do SQL Server 2005 para alta disponibilidade.Database Mirror consiste em basicamente um espelhamento de um banco de dados, uma solução que fornece quase em tempo REAL failover a nível de banco de dados,sem qualquer necessidade de compatibilidade de hardware e baixo custo.
 
Com o failover fornecido pelo DATABASE Mirror é possível subir uma segunda base de dados de forma automática em menos de 3 segundos,tudo isso transparente para a aplicação.
É sem dúvida uma solução fantástica, de qual representa uma ótima justificativa para uma migração a partir de uma versão anterior.
 
Com o DATABASE Mirror é espelhado todo o banco de dados para um separado servidor, uma cópia completa quer será mantida e atualizada em tempo REAL utilizando a tecnologia Copy-on-WRITE (Cópia na Escrita).Como toda solução existem custos que devem ser levados em consideração como o volume de espaço em disco no segundo servidor deve ser equivalente ao servidor principal.
 
DATABASE Mirror trabalha através do TRANSACTION Log do banco de dados principal (O banco de dados de qual terá seus dados espelhados). Para implementar o DATABASE mirror é preciso configurar o banco de dados para o Recovery Model FULL,onde AS entradas do TRANSACTION Log são copiadas imediatamente para o banco de dados espelho a cada nova alteração nos dados,uma vez a transação é confirmada no banco de dados espelho este emite um aviso ao banco de dados principal e assim a transação é confirmada e completa.
Repare que com a cópia da transação para o banco de dados espelho cria uma certa proteção da informação,de forma que a cada alteração ou inserção é mantido cópias redundantes em ambos servidores.Esta é a tecnologia Copy-on-WRITE!
 
Em um cenário típico do DATABASE Mirror existem basicamente três componentes que são eles:
 
Principal DATABASE Server: É o servidor na qual armazena o banco de dados principal, ou seja, de qual terá suas informações espelhadas. É possível espelhar mais de um banco de dados da mesma instancia para outra instancia SQL Server, mas não é possível espelhar um banco de dados para outro na mesma instancia.
 
Mirror DATABASE Server: É o servidor na qual armazena o banco de dados espelho, ou seja, o banco de dados que atuará como standby do servidor principal, recebendo transações. O Mirror DATABASE permanece em estado de Restore e não pode ser acessado diretamente, pelo fato deste permanecer sempre recebendo registros de transações a partir do Principal DATABASE.
 
Witness DATABASE Server: É um opcional servidor que será a testemunha (Witness) na qual ficará monitorando caso tenha alguma falha no servidor principal, este ajudará tomar a decisão de realizar o failover para o servidor mirror. Quando ocorre alguma falha no servidor principal o servidor mirror e o servidor witness percebem a falha e juntos decidem que o servidor mirror deve substituir o servidor principal, assumindo a regra de servidor principal, respondendo requisições da aplicação.
 
 
Sem o servidor Witness não existe o failover automático, no momento da falha o servidor mirror percebe que a conexão com o servidor principal foi perdida, mas não pode tomar a decisão de assumir a regra de principal sozinho, desta forma o failover deve ser manual, a partir do servidor mirror.
A ilustração a seguir demonstra os componentes citados acima:
 
 
1. Uma transação é escrita através da aplicação para o TRANSACTION log do banco de dados AdventureWorks no servidor principal.
 
2. Imediatamente esta transação é copiada para o TRANSACTION log do banco de dados do servidor mirror, este então confirma a transação e envia para o servidor principal uma confirmação de escrita com sucesso.
 
3. Apos receber a confirmação do servidor mirror, o servidor principal confirma a transação em seu TRANSACTION log e retorna o aviso de confirmação para a transação.
O DATABASE Mirror pode ser configurado para executar em modos de operação de quais podem priorizar a performance da aplicação ou segurança dos dados.Os modos de operação são high availability,high-protection e high-performance.Cada modo de operação opera de acordo com AS configurações abaixo.
Synchronous operations (Operações Síncronas): Com operações síncronas a transação é confirmada em ambos os parceiros de replicação, banco de dados principal e mirror, claro que com este modo de operação irá gerar um custo adicional na transação pois que a transação somente é completada quando esta é confirmada em ambos os parceiros.O modo High-availability e high-protection usam operações síncronas.
Asynchronous operations (Operações Assíncronas): Com operações assíncronas a transação é confirmada no banco de dados principal sem esperar que o banco de dados no servidor espelho escreve a transação para seu log de transação no disco. Com esse modo de operação a performance da aplicação é melhorada,já que a transação não precisa do custo adicional de confirmar em ambos servidores para completar,porém temos uma falta de segurança na informação.O modo de High Performance utiliza este modo de operação.Para finalizar o nosso conceito sobre DATABASE Mirror,precisamos entender os tipos de Failover disponíveis e seus requisitos.
Failover Automático: O Failover Automático é necessário o ambiente de três instancias de quais desempenham AS três regras de Principal Server, Mirror Server e Witness Server, com o Failover automático caso aconteça um problema com a instancia principal o Mirror Server assume o papel de Principal de forma automática, sem intervenção humana, isto é o modo de High Availability.
Failover Manual: O Failover Manual é composto apenas das instancias Principal Server e Mirror Server, sem a o servidor Witness e com o modo de operação síncrona, a alteração da regra deve ser manual. Isto é o modo de High Availability e High Protection.
Forced Service: Serviço FORçado é quando ocorre alguma falha com o servidor principal, mas o servidor mirror não esta disponível, porém os dados não estão totalmente sincronizados. Com isso é preciso FORçar a alteração da regra para o servidor mirror, isso significa perca de dados, pois AS transações não estão sincronizadas. Isto é o modo high-protection ou high-performance.Configurando o DATABASE Mirror.
Agora que já vimos os conceitos e componentes associados ao DATABASE Mirror, vamos entender e configurar nosso ambiente.A conexão entre os servidores envolvidos no DATABASE Mirror é feita através de Endpoints, para os endpoints atribuímos uma conta de serviço do Windows para sua autenticação, caso estejamos em um ambiente com um domínio do Active Directory poderíamos criar uma conta exclusiva para os endpoints e utilizar esta de qual seria válidas em todos os servidores.
 
No nosso exemplo, iremos configurar uma conta de usuário LOCAL do Windows de qual será exclusiva para os endpoints em todos AS três instancias.Atribuiremos portas diferentes para os endpoints em cada instancia.
Devemos verificar também se em todas AS nossas instancias estar aplicado o Service Pack 1 ou superior,pois este é requerido pelo DATABASE Mirror.
 
Em nosso exemplo usaremos AS edições Enterprise Edition, o DATABASE Mirror somente é suportado nas edições Enterprise, Standard e Develop. A edição Workgroup e Express não são suportadas, somente desempenhando a regra de servidor Witness.Criaremos um banco de dados de teste chamado Livraria.
A ilustração abaixo resume AS configurações do nosso ambiente:
 
 
 
O Servidor Server01 atuando como Principal Server, servidor Server02 atuando como Mirror Server e o servidor 03 atuando como Witness Server (Express Edition). Para o endpoint do Server01 iremos configurar a porta 1400, Server02 com a porta 1450 e o Server03 com a porta 1500.
 
Agora com nosso ambiente planejado iremos partir para a configuração dos endpoints, podemos utilizar o SQL Server Management Studio ou código T-SQL para criar os endpoints, nesse exemplo usaremos códigos T-SQL para a criação.
Para a criação do Endpoint, se conecte no Server01 e utilize o comando abaixo para criar o endpoint:
 
–Cria o endpoint para DATABASE Mirror no Server01..
CREATE ENDPOINT ENDPOINT_MIRROR
STATE = STARTED
AS TCP(LISTENER_PORT = 1400,LISTENER_IP = ALL)
FOR DATA_MIRRORING(ROLE= PARTNER,AUTHENTICATION= WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM RC4)
No exemplo acima criamos o endpoint ENDPOINT_MIRROR com STATUS iniciado, com a porta TCP 1400, escutando em todos os endereços IP, endpoint do tipo DATA_MIRRORING, e com a ROLE (Regra definida como PARTNER de qual significa que este endpoint pode atua como um servidor principal ou espelho), utilizando autenticação do Windows e o algoritmo de criptografia RC4.
Se conecte no Server02 e utilize o mesmo comando listado acima para criar o endpoint. Lembre-se de alterar o número da porta para conexão como segue abaixo.
 
 
–Cria o endpoint para DATABASE Mirror no Server02..
CREATE ENDPOINT ENDPOINT_MIRROR
STATE = STARTED
AS TCP(LISTENER_PORT = 1450,LISTENER_IP = ALL)
FOR DATA_MIRRORING(ROLE= PARTNER,AUTHENTICATION= WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM RC4)
 
*Somente é possível criar um Endpoint para DATABASE Mirror por vez na mesma instancia.Se conecte no Server03 e crie o Endpoint como listado abaixo,alterando o número da porta,e a regra para Witness.
 
–Cria o endpoint para DATABASE Mirror no Server03..
CREATE ENDPOINT ENDPOINT_MIRROR
STATE = STARTED
AS TCP(LISTENER_PORT = 1500,LISTENER_IP = ALL)
FOR DATA_MIRRORING(ROLE= WITNESS,AUTHENTICATION= WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM RC4)
Após a criação dos Endpoints em todas AS instancias envolvidas na configuração do DATABASE Mirror,EXECUTE a query abaixo para listar os endpoints criados em cada instancia.
 
–Query lista os endpoints criados na instancia.
SELECT name
,type_desc
,port
,ip_address
FROM sys.tcp_endpoints
–Query lista AS informações sobre os endpoints como ROLE,descrição do STATUS,etc.
SELECT name
,role_desc
,state_desc
FROM sys.database_mirroring_endpoints
O resultado da query acima deve ser SIMILAR a este:
 
 
 
 
 
Para testar a conectividade entre os servidores  com AS portas especificadas nos endpoints,podemos usar o comando TELNET para verificar se os servidores estão escutando nas portas definidas.Segue o exemplo de testando a conexão do Server02,faça o teste em todos os servidores.
 
 
Agora que configuramos os endpoints em todas AS instancias associadas ao DATABASE Mirror, devemos criar o nosso usuário de qual iremos criar um login nas instancias SQL Server e atribuir a permissão de CONECT nos endpoints.
 
Crie o usuário em todos os três servidores com o mesmo nome e senha,lembrando de especificar que a senha deste usuário não deve expirar e o usuário não pode alterar a senha.Como disse anteriormente o procedimento de criar o mesmo usuário em todas os servidores é necessário quando não estamos em um ambiente com um domínio do Active Directory ,com isso criando o mesmo usuário em cada servidor estamos assegurando que o usuário é válido em todos os servidores.
 
Utilize o comando abaixo para criar o usuário em cada servidor, especificando o nome de usuário e senha, especificando a conta do usuário como ativa, usuário não deve alterar sua senha,e sua senha não expira.Essas são configurações normalmente utilizadas para contas de serviço.
 
 
Após criarmos o usuário em todos os servidores, vamos criar o login no SQL Server associado ao usuário recém criado, e atribuindo a permissão de CONNECT nos endpoints do DATABASE Mirror,com esta permissão o nosso usuário poderá se conectar nos endpoints para o acesso(novamente crie em todos os servidores).Segue o comando para criação do login e atribuição da permissão CONNECT.
–Conecte no Server01..
CREATE LOGIN [SERVER01SQLUser] FROM WINDOWS
GRANT CONNECT ON ENDPOINT::ENDPOINT_MIRROR TO [SERVER01SQLUser]
–Conecte no Server02..
CREATE LOGIN [SERVER02SQLUser] FROM WINDOWS
GRANT CONNECT ON ENDPOINT::ENDPOINT_MIRROR TO [SERVER02SQLUser]
–Conecte no Server03..
CREATE LOGIN [SERVER03SQLUser] FROM WINDOWS
GRANT CONNECT ON ENDPOINT::ENDPOINT_MIRROR TO [SERVER03SQLUser]
Após criarmos o usuário e o login correspondente,coloque a conta de usuário para executar o serviço SQL Server em todos os servidores através do SQL Server Configuration Manager.
Agora vamos criar o nosso banco de teste chamado Livraria,e duas tabelas com um relacionamento,segue o script.
 
–Criando o banco de dados Livraria
CREATE DATABASE Livraria
–Criando AS tabelas de exemplo Autores e Livros.
USE Livraria
CREATE TABLE dbo.Autores
(
     AutorID SMALLINT NOT NULL
    ,Nome VARCHAR(50)
    ,Email VARCHAR(50)
)
ALTER TABLE dbo.Autores
ADD CONSTRAINT [PK_COD_Autores] PRIMARY KEY(AutorID)
CREATE TABLE dbo.Livros
(
     LivroID SMALLINT NOT NULL
    ,AutorID SMALLINT
    ,Nome VARCHAR(50)
    ,Valor MONEY
)
ALTER TABLE Livros
ADD CONSTRAINT [PK_LivroID_Livros] PRIMARY KEY(LivroID)
–Criando o relacionamento entra AS tabelas.
ALTER TABLE Livros
ADD CONSTRAINT [FK_AutorID_Livros] FOREIGN KEY(AutorID)
REFERENCES dbo.Autores(AutorID)
ON DELETE CASCADE
ON UPDATE CASCADE
–Inserindo alguns valores para povoar nossa tabela de autores.
INSERT INTO Autores VALUES(1,‘Kalen Delaney’,‘[email protected].com’)
INSERT INTO Autores VALUES(2,‘Paul S Randal’,‘[email protected].com’)
–Inserindo alguns valores para povoar nossa tabela de Livros.
INSERT INTO Livros VALUES(1,1,‘SQL Server The Stogare Engine’,100)
INSERT INTO Livros VALUES(2,2,‘SQL Server FOR Develops’,80)
–Query para verificar o relacionamento entre AS tabelas.
SELECT   A.AutorID
        ,A.Nome
        ,A.Email
        ,L.Nome
        ,L.Valor
FROM Autores A INNER JOIN Livros L
ON A.AutorID = L.AutorID
 
Com o nosso banco criado,precisamos fazer o backup FULL e o restore em nosso servidor Mirror,especificando a opção NORECOVERY para manter o banco em estado de restoring,recebendo AS transações a partir do principal.Script para realizar o backup do banco de dados.
 
–Backup FULL para restore no banco de dados mirror.
BACKUP DATABASE [Livraria]
TO DISK = ‘C:BACKUPLivraria_Full.bak’
WITH INIT
–Backup do TRANSACTION Log para restore no banco de dados mirror.
BACKUP LOG [Livraria]
TO DISK = ‘C:BACKUPLivraria_Log.bak’
WITH INIT
 
Após o backup precisamos transferir os dispositivos para o servidor mirror e fazer o restore.
Se conecte no Server02 e EXECUTE os comandos abaixo para criar o banco de dados Livraria a partir do backup criado anteriormente.No exemplo abaixo estou referindo ao driver C: como o LOCAL de qual armazenei os dispositivos de backup,caso tenha salvo em outra localização especifique esta.
–Restore do backup FULL no servidor Mirror,especificando a opção NORECOVERY.
RESTORE DATABASE [Livraria]
FROM DISK = ‘C:BACKUPLivraria_Full.bak’
WITH NORECOVERY
–Restore do backup do log de transação no servidor Mirror,especificando a opção NORECOVERY,deixando o banco de dados em estado de restoring,de qual é requerido para configurar o DATABASE Mirror.
RESTORE LOG [Livraria]
FROM DISK = ‘C:BACKUPLivraria_Log.bak’
WITH NORECOVERY
Após recuperar nosso banco de dados no servidor Mirror,devemos configurar o espelhamento utilizando o comando ALTER DATABASE ,especificando assim AS regras exercidas por cada servidor.
O Script abaixo deve ser executado no servidor Mirror, indicando que seu “parceiro” será o servidor  principal que nosso exemplo é o server01.
No comando ALTER DATABASE especificando o FQDN do nosso servidor,para uma instalação em um ambiente Workgroup talvez seja necessário a configuração de um sufixo DNS para completar o nome da máquina,no meu exemplo configurei o sufixo chamado LOCAL.Apos o FQDN especificamos a porta configurada no ENDPOINT previamente criado,o comando completo segue abaixo.
–Especificando o server01 como parceiro
ALTER DATABASE Livraria
SET PARTNER = ‘TCP://server01.local:1400′
 
Agora precisamos definir em nosso servidor principal o server02 como parceiro e definir o server03 como Witness,usaremos o mesmo comando ALTER DATABASE.Se conecte no server01 e emita os comandos abaixo:
 
–Especificando o server02 como parceiro
ALTER DATABASE Livraria
SET PARTNER = ‘TCP://server02.local:1450′
 
–Especificando o server03 como Witness
ALTER DATABASE Livraria
SET WITNESS = ‘TCP://server01.local:1500′
Se ocorrer algum erro no momento da execução dos comandos abaixo,como problemas em encontrar algum dos parceiros envolvidos,teste AS conexões de rede,verifique a resolução de nome entre os servidores e caso não esteja utilizando um servidor DNS adicione ao arquivo Host localizado em %SystemRoot%system32driversetc AS entradas com os nomes dos servidores e seus FQDNs com seus respectivos IP´s como mostrado abaixo.
 
 
 
Com isso podemos verificar o STATUS,pausar,FORçar o failover e até mesmo remover  nossa configuração DATABASE Mirror,selecionando AS propriedades do banco de dados Livraria,na opção Mirroring como mostrado na figura abaixo.
 
 
No object Explorer se registrarmos os servidores Principal e Mirror podemos visualizar parcialmente o STATUS e qual regra determinado servidor estar atuando no momento como abaixo podemos visualizar o Servidor Principal Sincronizado.
 
 
Servidor Mirror Sincronizado e em estado de Restoring..
 
 
 
 
Pronto,neste momento estamos com nosso ambiente espelhado,caso ocorra algum problema com o server01, o server02 assumirá sua regra e passará a atuar como servidor principal,após restabelecer o server01 este irá assumir a regra de mirror e assim sucessivamente.Para testar a funcionalidade você pode simular um problema no server01 e verificar se o server02 passou a ser o Principal automáticamente.
 
Com isso concluo meu artigo sobre DATABASE Mirror,mostrando sua configuração e conceitos,espero ter demonstrado de forma clara e completa AS vantagems e benefícios desta solução disponível no SQL Server 2005 e 2008,bem como os passos necessários para realizar sua implementação com sucesso.
Obrigado e até o próximo post.

sqlserver2008-镜像数据库实施手册(双机)sql-server2014同样适用

SQLServer2008R2-镜像数据库实施手册(双机)SQLServer2014同样适用一、配置主备机1、 服务器基本信息主机名称为：HOST_A，IP地址为：192.168.1.155备机名称为：HOST_B，IP地址为：192.168.1.156二、主备实例互通实现互通可以使用域或证书来... 查看详情

网页镜像的原理

...什么1.最简单的方法:一台做主服务器,其它作镜像服务器,数据库存在主服务器上,镜像服务器使用远程调用功能读取主服务器的数据库.使用工具让主服务器上的网页文件和镜像服务器同步.优点:实现简单缺点:远程调用效率低,速度... 查看详情

用rsync实现网站镜像和备份

...作为应用平台的的中小型企业或网站来说，往往面临如何实现数据远程备份或者网站镜象的问题，虽然有商业化的备份和镜象产品可供选择，但这些产品的价格往往过于昂贵。因此如何利用自由软件高效实现远程备份和网站镜象... 查看详情

java递归实现镜像二叉树

输出给定二叉树的镜像二叉树？思路：镜像二叉树，顾名思义左右孩子与原来树对称。所以，就是从根结点开始不断交换左右孩子，publicclassBinnaryTree{//交换左右子树classTreeNode{intval;//数据域TreeNodeleft=null;TreeNoderight=null;publicTreeNode... 查看详情

swift-实现图片（uiimage）的水平翻转(镜像)，垂直翻转

参考技术ASwift-实现图片（UIImage）的水平翻转(镜像)，垂直翻转有时候我们需要对图片（UIImage）进行垂直翻转（上下翻转），或者水平翻转处理（即镜像处理）。如下图：通常有两种方式。1，实现原理UIImage有个属性叫imageOrientati... 查看详情

drbd基本（实现数据库高可用）

DRBD（实现数据库高可用）    DistributedReplicatedBlockDevice(DRBD)是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。    数据镜像：实时、透明、同步（所有服务器都成功后... 查看详情

drbd数据镜像与搭建

...时，数据也将会同步到同一网络的另一台主机的磁盘上，实现了本地 查看详情

在docker中使用dockerfile实现iso文件转化为完整版centos镜像，并搭建集群数据仓库(代码片段)

在Docker中使用Dockerfile实现ISO文件转化为完整版Centos镜像，并搭建集群数据仓库在上一篇文章中，我们提到了如何使用Docker官方版本的centos7搭建容器集群并实现同一ip下使用不同端口的ssh远程登录，但是其中遇到了非... 查看详情

什么是交换机端口镜像？

...来把一个或多个端口（VLAN）的数据转发到某一个端口来实现对网络的监听，是网络通信协议的一种方式。扩展资料：端口镜像的功能监视到进出网络的所有数据包，供安装了监控软件的管理服务器抓取数据,如网吧需提供此功能... 查看详情

sqlserver主体，已同步(代码片段)

...sp; https://www.cnblogs.com/gered/p/10601202.html目录SQLSERVER基于数据库镜像的主从同步...11、概念...21.1、服务器概念...21.2、模式概念...21.3、数据库镜像的优势...31.4、数据库镜像的不足...32、实施前提（基于证书访问实现）...43、实施... 查看详情

端口镜像

...来把一个或多个端口（VLAN）的数据转发到某一个端口来实现对网络的监听。端口镜像的别名端口镜像通常有以下几种别名：●PortMirroring通常指允许把一个端口的流量 查看详情

通过rsync+inotify实现数据的实时备份

我讲到过利用rsync实现数据的镜像和备份，但是要实现数据的实时备份，单独靠rsync还不能实现，本文就讲述下如何实现数据的实时备份。一、rsync的优点与不足 与传统的cp、tar备份方式相比，rsync具有安全性高、备份迅速、... 查看详情

ha_mirror数据库镜像

环境准备：　　虚拟机3台，INTER-DC,INTER-SQLA,INTER-SQLB　　创建域帐户INTERMSSQLSERVER.SERVICE，分别添加到INTER-SQLA和INTER-SQLB的本地管理员　　将两台SQL服务器的MSQLServer服务，启动帐号都设置为INTERMSSQLSERVER.SERVICE帐号说明：　　镜像是... 查看详情

rsync--数据镜像备份_转

...，这类似于cp命令，同样也优于cp命令。此外，rsync还可以实现类似rm的删除功能。功能介绍：https://www.samba.org 查看详情

(转)ibmaix系统为rootvg实现镜像

IBMAIX系统为rootvg实现镜像AIX系统安装的时候，没有选择安装镜像，因此在系统安装完成后，出于安全方面的考虑，决定为rootvg创建镜像。工具/原料AIXrootvglspvchdevextendvgbosbootbootlistbootinfo方法/步骤确定rootvg 没有镜像#lsvg-lrootvg... 查看详情

docker怎么实现镜像加速

参考技术A都说了不用，我在本地就用的是阿里云的docker镜像。你把daemon.json改下就行了 查看详情

docker镜像的实现原理

Docker镜像是怎么实现增量的修改和维护的？每个镜像都由很多层次构成，Docker使用UnionFS将这些不同的层结合到一个镜像中去。通常UnionFS有两个用途,一方面可以实现不借助LVM、RAID将多个disk挂到同一个目录下,另一个更常用的就是... 查看详情

docker镜像之存储管理(代码片段)

...用场景对存储的要求，docker提供了各种基于不同文件系统实现的存储驱动来管理实际镜像文件。本文我们就来介绍docker如何管理镜 查看详情