sql >> Base de Datos >  >> RDS >> MariaDB

Comparación de alta disponibilidad de bases de datos:replicación de MySQL/MariaDB frente a Oracle Data Guard

En el "Estado del mercado DBMS de código abierto, 2018", Gartner predice que para 2022, el 70 por ciento de las nuevas aplicaciones internas se desarrollarán en una base de datos de código abierto. Y el 50% de las bases de datos comerciales existentes se habrán convertido. Entonces, DBA de Oracle, prepárense para comenzar a implementar y administrar nuevas bases de datos de código abierto, junto con sus instancias de Oracle heredadas. A menos que ya lo estés haciendo.

Entonces, ¿cómo se compara la replicación de MySQL o MariaDB con Oracle Data Guard? En este blog, compararemos los dos desde el punto de vista de una solución de base de datos de alta disponibilidad.

Qué buscar

Una arquitectura de replicación de datos moderna se basa en diseños flexibles que permiten la replicación de datos unidireccional y bidireccional, así como una conmutación por error rápida y automatizada a bases de datos secundarias en caso de interrupción del servicio no planificada. La conmutación por error también debe ser fácil de ejecutar y confiable para que no se pierdan las transacciones comprometidas. Además, idealmente, la conmutación o la conmutación por error deberían ser transparentes para las aplicaciones.

Las soluciones de replicación de datos deben ser capaces de copiar datos con una latencia muy baja para evitar cuellos de botella en el procesamiento y garantizar el acceso a los datos en tiempo real. Las copias en tiempo real se pueden implementar en una base de datos diferente que se ejecuta en hardware de bajo costo.

Cuando se utiliza para la recuperación ante desastres, el sistema debe validarse para garantizar el acceso de la aplicación al sistema secundario con una interrupción mínima del servicio. La solución ideal debería permitir realizar pruebas periódicas del proceso de recuperación ante desastres.

Temas principales de comparación

  • Disponibilidad y coherencia de los datos
    • Gtid, scm
    • Mencione la replicación en varios modelos en espera, asíncronos + sincronizados
    • Aislamiento de standby de fallas de producción (por ejemplo, replicación retrasada para mysql)
    • Evite la pérdida de datos (replicación sincronizada)
  • Utilización de los sistemas de reserva
    • Uso del modo de espera
  • Failover, Switchover y recuperación automática
    • Conmutación por error de la base de datos
    • Conmutación por error de aplicaciones transparente (TAF frente a ProxySQL, MaxScale)
  • Seguridad
  • Facilidad de uso y gestión (gestión unificada de componentes preintegrados)

Disponibilidad y coherencia de los datos

GTID de MySQL

La replicación de MySQL 5.5 se basaba en eventos de registro binario, donde todo lo que un esclavo sabía era el evento preciso y la posición exacta que acababa de leer del maestro. Cualquier transacción individual de un maestro puede haber terminado en varios registros binarios de diferentes esclavos, y la transacción generalmente tendría diferentes posiciones en estos registros. Era una solución simple que venía con limitaciones, los cambios de topología podrían requerir que un administrador detuviera la replicación en las instancias involucradas. Estos cambios podrían causar otros problemas, por ejemplo, un esclavo no se puede mover hacia abajo en la cadena de replicación sin una reconstrucción que requiere mucho tiempo. La reparación de un enlace de replicación roto requeriría determinar manualmente un nuevo archivo de registro binario y la posición de la última transacción ejecutada en el esclavo y reanudar desde allí, o una reconstrucción total. Todos hemos tenido que sortear estas limitaciones mientras soñamos con un identificador de transacción global.

MySQL versión 5.6 (y MariaDB versión 10.0.2) introdujeron un mecanismo para resolver este problema. GTID (Identificador de transacción global) proporciona un mejor mapeo de transacciones entre nodos.

Con GTID, los esclavos pueden ver una transacción única proveniente de varios maestros y esto se puede asignar fácilmente a la lista de ejecución de esclavos si necesita reiniciar o reanudar la replicación. Entonces, el consejo es usar siempre GTID. Tenga en cuenta que MySQL y MariaDB tienen diferentes implementaciones de GTID.

Oracle SCN

En 1992, con la versión 7.3, Oracle introdujo una solución para mantener una copia sincronizada de una base de datos en espera, conocida como Data Guard a partir de la versión 9i, versión 2. Una configuración de Data Guard consta de dos componentes principales, una única base de datos principal y una base de datos en espera. (hasta 30). Los cambios en la base de datos principal se pasan a través de la base de datos en espera y estos cambios se aplican a la base de datos en espera para mantenerla sincronizada.

Oracle Data Guard se crea inicialmente a partir de una copia de seguridad de la base de datos principal. Data Guard sincroniza automáticamente la base de datos principal y todas las bases de datos en espera al transmitir la rehacer de la base de datos principal (la información utilizada por cada base de datos de Oracle para proteger las transacciones) y aplicarla a la base de datos en espera. Oracle utiliza un mecanismo interno llamado SCN (número de cambio del sistema). El número de cambio del sistema (SCN) es el reloj de Oracle, cada vez que nos comprometemos, el reloj se incrementa. El SCN marca un punto consistente en el tiempo en la base de datos que es un punto de control que es el acto de escribir bloques sucios (bloques modificados del caché del búfer al disco). Podemos compararlo con GTID en MySQL.

Los servicios de transporte de Data Guard manejan todos los aspectos de la transmisión de rehacer desde una base de datos principal a una de reserva. A medida que los usuarios realizan transacciones en el principal, se generan registros de rehacer y se escriben en un archivo de registro local en línea. Los servicios de transporte de Data Guard transmiten simultáneamente la misma rehacer directamente desde el búfer de registro de la base de datos principal (memoria asignada dentro del área global del sistema) a la(s) base(s) de datos en espera donde se escribe en un archivo de registro de rehacer en espera.

Existen algunas diferencias principales entre la replicación de MySQL y Data Guard. La transmisión directa de Data Guard desde la memoria evita la sobrecarga de E/S del disco en la base de datos principal. Es diferente de cómo funciona MySQL:la lectura de datos de la memoria disminuye la E/S en una base de datos principal.

Data Guard transmite solo rehacer la base de datos. Está en marcado contraste con la duplicación remota de almacenamiento, que debe transmitir cada bloque modificado en cada archivo para mantener la sincronización en tiempo real.

Modelos asíncronos + sincronizados

Oracle Data Guard ofrece tres modelos diferentes para la aplicación de rehacer. Modelos adaptativos que dependen del hardware disponible, los procesos y, en última instancia, las necesidades comerciales.

  • Rendimiento máximo:modo de operación predeterminado, que permite confirmar una transacción tan pronto como los datos de rehacer necesarios para recuperar esa transacción se escriben en el registro de rehacer local en el maestro.
  • Máxima protección:sin pérdida de datos y el máximo nivel de protección. Los datos de rehacer necesarios para mejorar cada operación deben escribirse tanto en el registro de rehacer en línea local en el maestro como en el registro de rehacer en espera en al menos una base de datos en espera antes de que se confirme la transacción (Oracle recomienda al menos dos en espera). La base de datos principal se cerrará si una falla le impide escribir su flujo de rehacer en al menos una base de datos en espera sincronizada.
  • Máxima disponibilidad:similar a Máxima protección, pero la base de datos principal no se cerrará si una falla impide que escriba su flujo de rehacer.

Cuando se trata de elegir la configuración de replicación de MySQL, puede elegir entre replicación asíncrona o replicación semisincrónica.

  • La aplicación binlog asincrónica es el método predeterminado para la replicación de MySQL. El maestro escribe eventos en su registro binario y los esclavos los solicitan cuando están listos. No hay garantía de que ningún evento llegue a ningún esclavo.
  • La confirmación semisíncrona en el primario se retrasa hasta que el maestro recibe un reconocimiento del esclavo semisíncrono de que el esclavo recibe y escribe los datos. Tenga en cuenta que la replicación semisincrónica requiere la instalación de un complemento adicional.

Uso de sistemas de reserva

MySQL es bien conocido por su simplicidad y flexibilidad de replicación. De forma predeterminada, puede leer o incluso escribir en sus servidores en espera/esclavos. Afortunadamente, MySQL 5.6 y 5.7 trajeron muchas mejoras significativas a la replicación, que incluyen ID de transacciones globales, sumas de verificación de eventos, esclavos de subprocesos múltiples y esclavos/maestros a prueba de fallas para hacerlo aún mejor. Los DBA acostumbrados a las lecturas y escrituras de replicación de MySQL esperarían una solución similar o incluso más simple de su hermano mayor, Oracle. Desafortunadamente no por defecto.

La implementación de espera física estándar para Oracle está cerrada para cualquier operación de lectura y escritura. De hecho, Oracle ofrece una variación lógica pero tiene muchas limitaciones y no está diseñado para HA. La solución a este problema es una función paga adicional llamada Active Data Guard, que puede usar para leer datos desde el modo de espera mientras aplica registros de rehacer.

Active Data Guard es una solución adicional de pago para el software gratuito de recuperación ante desastres Data Guard de Oracle disponible solo para Oracle Database Enterprise Edition (licencia de mayor costo). Ofrece acceso de solo lectura, mientras aplica continuamente los cambios enviados desde la base de datos principal. Como base de datos en espera activa, ayuda a descargar consultas de lectura, informes y copias de seguridad incrementales de la base de datos principal. La arquitectura del producto está diseñada para permitir que las bases de datos en espera estén aisladas de las fallas que pueden ocurrir en la base de datos principal.

Una característica interesante de la base de datos Oracle 12c y algo que Oracle DBA perdería es la validación de corrupción de datos. Se realizan verificaciones de corrupción de Oracle Data Guard para garantizar que los datos estén alineados exactamente antes de que se copien en una base de datos en espera. Este mecanismo también se puede utilizar para restaurar bloques de datos en la base de datos principal directamente desde la base de datos en espera.

Conmutación por error, conmutación y recuperación automática

Para mantener su configuración de replicación estable y en funcionamiento, es crucial que el sistema sea resistente a las fallas. Las fallas son causadas por errores de software, problemas de configuración o problemas de hardware, y pueden ocurrir en cualquier momento. En caso de que un servidor se caiga, necesita una notificación de alarma sobre la configuración degradada. El administrador puede realizar la conmutación por error (promoción de un esclavo a maestro), quien debe decidir qué esclavo promover.

El administrador necesita información sobre la falla, el estado de sincronización en caso de que se pierdan datos y, finalmente, los pasos para realizar la acción. Idealmente, todo debería estar automatizado y visible desde una sola consola.

Hay dos enfoques principales para la conmutación por error de MySQL, automática y manual. Ambas opciones tienen sus fans, describimos los conceptos en otro artículo.

Con el GTID, la conmutación por error manual se vuelve mucho más fácil. Consta de pasos como:

  • Detenga el módulo receptor (STOP SLAVE IO_THREAD)
  • Cambiar maestro (CAMBIAR MAESTRO A )
  • Inicie el módulo receptor (START SLAVE IO_THREAD)

Oracle Data Guard viene con una solución dedicada de conmutación por error/conmutación:Data Guard Broker. El bróker es un marco de gestión distribuida que automatiza y centraliza la creación, el mantenimiento y la supervisión de las configuraciones de Oracle Data Guard. Con el acceso a la herramienta de intermediario de DG, puede realizar cambios de configuración, conmutaciones, conmutaciones por error e incluso pruebas en seco de su configuración de alta disponibilidad. Las dos acciones principales son:

  • El comando CAMBIAR A se utiliza para realizar la operación de conmutación. Después de la operación de cambio exitosa, las instancias de la base de datos cambian de lugar y la replicación continúa. No es posible cambiar cuando el modo de espera no responde o está inactivo.
  • El error común TO se utiliza para realizar la conmutación por error. Después de la operación de conmutación por error, el servidor principal anterior requiere recreación, pero el nuevo servidor principal puede asumir la carga de trabajo de la base de datos.

Hablando de conmutación por error, debemos considerar cuán transparente puede ser la conmutación por error de su aplicación. En el caso de una interrupción planificada o no planificada, ¿qué tan eficientemente se pueden dirigir las sesiones de los usuarios a un sitio secundario, con una interrupción mínima del negocio?

El enfoque estándar para MySQL sería usar uno de los Load Balancers disponibles. A partir de HAProxy, que se usa ampliamente para la conmutación por error de HTTP o TCP/IP, hasta Maxscale o ProxySQL con base de datos.

En Oracle, este problema se soluciona mediante TAF (Transparent Application Failover). Una vez que se produce el cambio o la conmutación por error, la aplicación se dirige automáticamente al nuevo principal. TAF permite que la aplicación se vuelva a conectar de forma automática y transparente a una nueva base de datos, si la instancia de la base de datos a la que se realiza la conexión falla.

Seguridad

La seguridad de los datos es un tema candente para muchas organizaciones en estos días. Para aquellos que necesitan implementar estándares como PCI DSS o HIPAA, la seguridad de la base de datos es imprescindible. Los entornos WAN cruzados pueden generar preocupaciones sobre la privacidad y la seguridad de los datos, especialmente a medida que más empresas tienen que cumplir con las regulaciones nacionales e internacionales. Los registros binarios de MySQL utilizados para la replicación pueden contener datos confidenciales fáciles de leer. Con la configuración estándar, robar datos es un proceso muy fácil. MySQL admite SSL como mecanismo para cifrar el tráfico tanto entre servidores MySQL (replicación) como entre servidores MySQL y clientes. Una forma típica de implementar el cifrado SSL es utilizar certificados autofirmados. La mayoría de las veces, no se requiere obtener un certificado SSL emitido por la Autoridad de Certificación. Puede usar openssl para crear certificados, ejemplo a continuación:

$ 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

Luego modifique la replicación con parámetros para SSL.

….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';

Para una opción más automatizada, puede usar ClusterControl para habilitar el cifrado y administrar las claves SSL.

En Oracle 12c, el transporte de rehacer de Data Guard se puede integrar con un conjunto de funciones de seguridad dedicadas denominadas Oracle Advanced Security (OAS). La seguridad avanzada se puede utilizar para habilitar los servicios de encriptación y autenticación entre los sistemas primario y en espera. Por ejemplo, habilitar el algoritmo de cifrado AES (Advanced Encryption Standard) requiere solo unos pocos cambios de parámetros en el archivo sqlnet.ora para cifrar el redo (similar al binlog de MySQL). No se requiere la configuración de un certificado externo y solo requiere un reinicio de la base de datos en espera. La modificación en sqlnet.ora y wallet es tan simple como:

Crear un directorio de billetera

mkdir /u01/app/wallet

Editar sqlnet.ora

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

Crear un almacén de claves

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

Abrir tienda

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Crear una clave maestra

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

En espera

copie los archivos p12 y .sso en el directorio de la billetera y actualice el archivo sqlnet.ora similar al nodo principal.

Para obtener más información, siga el documento técnico de TDE de Oracle, puede aprender del documento técnico cómo cifrar el archivo de datos y hacer que la billetera esté siempre abierta.

Facilidad de uso y administración

Cuando administra o implementa la configuración de Oracle Data Guard, es posible que descubra que hay muchos pasos y parámetros que buscar. Para responder a eso, Oracle creó DG Broker.

Sin duda, puede crear una configuración de Data Guard sin implementar DG Broker, pero puede hacer que su vida sea mucho más cómoda. Cuando se implementa, la utilidad de línea de comando del Broker - DGMGRL es probablemente la opción principal para el DBA. Para aquellos que prefieren la GUI, Cloud Control 13c tiene una opción para acceder a DG Broker a través de la interfaz web.

Las tareas con las que Broker puede ayudar son el inicio automático de la recuperación gestionada, un comando para la conmutación por error/conmutación, la supervisión de la replicación de DG, la verificación de la configuración y muchas otras.

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

MySQL no ofrece una solución similar a Oracle DG Broker. Sin embargo, puede ampliar su funcionalidad utilizando herramientas como Orchestrator, MHA y balanceadores de carga (ProxySQL, HAProxy o Maxscale). La solución para administrar bases de datos y balanceadores de carga es ClusterControl. ClusterControl Enterprise Edition le brinda un conjunto completo de funciones de administración y escalado además de las funciones de implementación y monitoreo que se ofrecen como parte de Community Edition gratuita.