Comparação de alta disponibilidade de banco de dados - Replicação MySQL / MariaDB vs Oracle Data Guard

O que procurar

Principais tópicos de comparação

• Disponibilidade e consistência de dados
  • Gtid, scm
  • Mencione Replicação para vários modelos de espera, assíncrona + sincronização
  • Isolamento de espera de falhas de produção (por exemplo, replicação atrasada para mysql)
  • Evite a perda de dados (replicação de sincronização)
• Utilização de sistemas em espera
  • Uso do modo de espera
• Failover, Switchover e recuperação automática
  • Failover do banco de dados
  • Failover transparente do aplicativo (TAF vs ProxySQL, MaxScale)
• Segurança
• Facilidade de uso e gerenciamento (gerenciamento unificado de componentes pré-integrados)

Disponibilidade e consistência de dados

MySQL GTID

Oracle SCN

Modelos assíncronos + de sincronização

• Desempenho máximo - modo de operação padrão, permitindo que uma transação seja confirmada assim que os dados de redo necessários para recuperar essa transação forem gravados no log de redo local no mestre.
• Proteção máxima - sem perda de dados e o nível máximo de proteção. Os dados de redo necessários para melhorar cada operação devem ser gravados no redo log local on-line no mestre e no redo log de espera em pelo menos um banco de dados de espera antes da confirmação da transação (a Oracle recomenda pelo menos duas esperas). O banco de dados primário será encerrado se uma falha o impedir de gravar seu fluxo de redo em pelo menos um banco de dados de espera sincronizado.
• Disponibilidade máxima - semelhante à proteção máxima, mas o banco de dados primário não será encerrado se uma falha impedir que ele grave seu fluxo de redo.

• A aplicação de log binário assíncrono é o método padrão para replicação do MySQL. O mestre grava eventos em seu log binário e os escravos os solicitam quando estão prontos. Não há garantia de que qualquer evento chegará a qualquer escravo.
• A confirmação semi-síncrona no primário é atrasada até que o mestre receba uma confirmação do escravo semi-síncrono de que os dados foram recebidos e gravados pelo escravo. Observe que a replicação semi-síncrona requer a instalação de um plug-in adicional.

Utilização de sistemas em espera

Failover, alternância e recuperação automática

• Parar o módulo receptor (STOP SLAVE IO_THREAD)
• Mudar mestre (MUDAR MESTRE PARA )
• Inicie o módulo receptor (START SLAVE IO_THREAD)

• O comando SWITCHOVER TO é usado para realizar a operação de alternância. Após a operação de alternância bem-sucedida, as instâncias de banco de dados trocam de lugar e a replicação continua. Não é possível alternar quando o modo de espera não está respondendo ou está inativo.
• O comum FAILOVER TO é usado para executar o failover. Após a operação de failover, o servidor primário anterior requer recriação, mas o novo primário pode assumir a carga de trabalho do banco de dados.

Segurança

$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pem

….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';

mkdir /u01/app/wallet

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

Facilidade de uso e gerenciamento

DGMGRL> show configuration 
Configuration - orcl_s9s_config 

Protection Mode: MaxPerformance
  Members:

s9sp  - Primary database
    s9ss - Physical standby database 

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 12 seconds ago