¿Qué prácticas o herramientas permiten la implementación continua de bases de datos?

La entrega continua o la implementación continua de infraestructura y código es comparativamente simple en comparación con probar los mismos enfoques para las bases de datos, específicamente los RDBMS. El código y la infraestructura no cambiarán ni evolucionarán una vez que se haya completado la implementación. Sin embargo, las bases de datos tendrán nuevos datos agregados, lo que hará que los datos, si no el esquema, sean componentes inherentemente mutables.

Soy consciente de que existen prácticas como agregar solo objetos de base de datos, es decir, tablas y columnas, nunca modificarlos o eliminarlos; esta forma puramente aditiva de abordar esquemas de bases de datos tiene la ventaja de garantizar que los esquemas sean compatibles con versiones anteriores a costa de ser cada vez más complicados esquemas

Del mismo modo, hay productos como Flyway y Ready Roll que ayudan a escribir las migraciones que se escribirán entre versiones de un esquema.

¿Qué otras prácticas y herramientas existen actualmente para permitir la implementación continua de esquemas de bases de datos en un entorno de producción donde la integridad de los datos es una preocupación?

Pramod Sadalage y Scott Ambler escribieron un libro Refactoring Databases: Evolutionary Database Design que es una cartilla increíblemente sólida para el tema de DBs en un CD org / team.

Los desafios

Soy consciente de que existen prácticas como agregar solo objetos de base de datos, es decir, tablas y columnas, nunca modificarlos o eliminarlos

En una empresa para la que trabajé, una ventana móvil de datos en bruto equivalía a unos 6 meses y consumía 10 TB. Luego, los datos se procesaron en un formato RDBMS que costó 6 TB de datos utilizables que representaron aproximadamente 10 años de datos reportables. El punto es que a escala, este tipo de prácticas simplemente no son prácticas. El almacenamiento es costoso, probablemente el mayor gasto informático. Esto proporciona varios desafíos interesantes:

1. Copias de seguridad : los complementos innodb son geniales y todo, pero los tiempos de copia de seguridad en esa cantidad de datos simplemente no son tan prácticos
2. Tiempos de restauración , para grandes conjuntos de datos, especialmente si necesita replicación para ponerse al día después de que una restauración vuelva a un estado operativo puede llevar días o incluso semanas.
3. Crear / sembrar nuevas instancias : a menudo, el trabajo que puede estar haciendo en desarrollo / prueba involucra trabajos ETL (Extraer, Transformar y Cargar) en su conjunto de datos. Estos deben validarse utilizando unidades de prueba de control de calidad, pero esto debe hacerse de una manera no destructiva para que se conserve el conjunto de datos de producción original. Mientras esté en un desastre, puede estar dispuesto a lidiar con un largo tiempo de restauración en el entendimiento de que las copias de seguridad son una póliza de seguro y la intención es evitarlas, el flujo de trabajo de desarrollo de DevOps requiere que, esencialmente, pueda realizar una restauración o copia de sus datos de forma regular (tal vez varias veces al día)
4. Capacidad : analizar esa cantidad de datos en la escala que acabo de describir puede ser muy intensiva en E / S. No solo necesita abordar los problemas descritos en 1-3, sino que debe hacerlo de una manera que no cause interrupciones o retrasos en el rendimiento de sus sistemas de producción.

Si bien las consideraciones anteriores pueden no ser una preocupación a escalas más pequeñas, a escalas más grandes, estos se convierten en grandes problemas. Esto significa que es extremadamente importante que defina sus requisitos y pronostique el tamaño de su conjunto de datos.

Definiendo requisitos

Como resultado, debe definir varios requisitos:

1. RTO : el objetivo de tiempo de restauración o RTO para las copias de seguridad es uno de los impulsores más importantes de las soluciones de copia de seguridad de bases de datos. Si bien, al principio, puede no parecer relevante para la mayoría de los otros problemas, se vuelve extremadamente relevante cuando pregunta "¿Qué sucede si utilizo mi solución de respaldo para crear o sembrar nuevas instancias?". Cubriré algunas técnicas para hacerlo en la siguiente sección.
2. RPO : el objetivo de punto de restauración o RPO para las copias de seguridad define A) qué tan atrás puede restaurar (minutos, horas, días, semanas, meses o años) B) El intervalo de copia de seguridad en diferentes niveles y C) qué tan granularmente puede restaurar . Por ejemplo, para las bases de datos de correo electrónico, a menudo se buscan copias de seguridad a nivel de mensaje (restauración de un correo electrónico específico). Del mismo modo, es posible que los datos de unos pocos días sean completamente inútiles, por lo que no tiene sentido restaurar un año atrás.
3. Tamaño de su conjunto de datos : esto es importante porque para una base de datos de 1 MB, su RTO se puede lograr con la mayoría de los productos y soluciones de respaldo. Sin embargo, para una base de datos de 10 TB, encontrará que una copia de seguridad completa a nivel de fila en cinta LTO 3 probablemente no alcanzará su RTO y podría interferir con su RPO porque las copias de seguridad comienzan a exceder su ventana de copia de seguridad. No puede hacer exactamente un mysqldump en este conjunto de datos tan grande, sino que probablemente podría salirse con la suya en la base de datos de 1 MB.
4. Consistencia de la base de datos : una última cosa que marca una gran diferencia en la implementación continua, la confiabilidad del sitio, la escalabilidad y la alta disponibilidad cuando se trabaja con bases de datos es su necesidad (o falta de ella) de consistencia. Hay tres tipos básicos: consistencia inmediata, consistencia Just-In-Time (JIT) y consistencia eventual

Además de las consideraciones principales anteriores, también debe tener en cuenta los requisitos de licencia y soporte (código abierto o código cerrado; soporte interno, soporte de terceros o soporte de proveedor) requisitos de idioma / aplicación (los conectores para muchas bases de datos pueden ser importantes; es su aplicación compilada? ¿Tiene acceso al código fuente? ¿Puede volver a compilarlo o es proporcionado por un proveedor? ¿O se ejecuta en un idioma interpretado?) requisitos políticos (¿Su organización solo confía en Oracle? ¿Odian Oracle? ¿No confían en MySql? ¿Cómo se siente con MariaDB o Postgres? está integrado en el motor oracle! ¿Cómo podríamos pasar a MariaDB?!?)

Todas estas cosas (significativamente) impactan las herramientas disponibles para usted.

Algunas opciones para la gestión de datos interna

Nota: Lo siguiente no es exhaustivo, y otros usuarios de SE deben intervenir con sugerencias adicionales.

Sin tener en cuenta las consideraciones genéricas, permítame proporcionarle algunas técnicas y tecnologías para abordar lo anterior. Primero, pregúntese si realmente necesita usar un RDBMS o si los datos no estructurados con algo como Hadoop, CouchDB o incluso el almacenamiento orientado a objetos (algo así como rápido) es una opción.

Segundo, considere buscar una solución basada en la nube. Esto externaliza parte de este dolor de cabeza y deja los problemas complicados a personas altamente calificadas (y remuneradas). Sin embargo, a escala, puede encontrar que esto realmente se adapta a su presupuesto (los proveedores de la nube SÍ obtienen ganancias con esto, y en cierta escala, simplemente puede darse el lujo de contratar a estos expertos usted mismo) o si está trabajando bajo seguridad específica o política requisitos (léase: no podemos hacer nubes) considere un NFS / FibreChannel Filer híbrido. La mayoría de estos archivadores, como los de NetApp, Pure Storage y Tegile, admiten una técnica de captura y clonación basada en delta que puede ser muy útil para A) tomar copias de seguridad, B) Restaurar copias de seguridad y C) Sembrar nuevas copias de seguridad.

En este punto, debo tener en cuenta que no soy un experto en copias de seguridad y almacenamiento, por lo que hay algunas partes de este problema que nunca pude resolver antes de pasar a otros problemas (y pastos más verdes).

Pero dicho esto, estos productos le permiten tomar instantáneas diferenciales debajo de su base de datos. Deberá crear una secuencia de comandos completa de "tablas de bloqueo con bloqueo de lectura" en una de las instancias de su base de datos (se recomienda un esclavo de solo lectura) y volcar su posición binlog o GTID, pero para estos archivadores, una vez que lo haga, podrá usar estas instantáneas para crear nuevas instancias de su base de datos. Deberá colocar binlogs en una partición separada y colocar solo los datos de su base de datos en estas particiones. Una vez que lo haga, podrá clonar estas particiones (en NetApps, esto se conoce como " FlexClone "

Esto se debe a que para cada bloque leído, el archivador debe determinar si los datos residen en la instantánea original congelada o en el delta. Para volúmenes / tiendas con múltiples instantáneas, es posible que esto deba verificarse varias veces. Puede superar esto actualizando los datos (es decir, deseche su instantánea y cléela nuevamente periódicamente, lo que podría suceder de forma natural y orgánica para un buen entorno de implementación continua) O dividiendo permanentemente el volumen (conocido como "División flexible" en la terminología de NetApp) ) que tomará un momento para resolver permanentemente los deltas y crear un volumen completamente nuevo y separado.

Estos clones delta tienen el beneficio adicional de reducir su requisito de almacenamiento general: puede generar varios clones o instancias de los datos de su base de datos de producción para realizar su desarrollo, prueba y validación. Si solo conserva una copia de su gran conjunto de datos más los (lo que probablemente sean) pequeños deltas, reducirá el costo total de almacenamiento y la huella.

El único truco aquí es que esto puede no constituir una solución de copia de seguridad completa ya que la "copia de seguridad" aún reside en su archivador. Para esto, es posible que necesite usar algo que NetApp llama Snap Mirror, que reflejará los datos (utilizando la tecnología de estilo rsync) entre los archivadores e incluso los centros de datos, o usar algún tipo de solución de respaldo integrada que pueda respaldar para grabar una de sus instantáneas delta o una clon flexible.

Sin embargo, esto tiene una falla importante: todos sus datos: desarrollo, prueba y producción todavía usan E / S en el mismo archivador y cabezal de almacenamiento. Para solucionar este problema, considere crear una instancia de base de datos esclava en un segundo archivador que puede ser el punto de partida para su archivador de prueba y / o dev, o considere usar un controlador de entrega de equilibrador de carga / aplicación para su capa de aplicación para reflejar las solicitudes de producción en su entorno (s) de prueba (y / o desarrollo). Esto tiene el beneficio adicional de lanzar tráfico de producción a su entorno de control de calidad / prueba antes de pasar a producción por problemas que podrían no notarse de inmediato. Luego puede verificar sus registros en busca de errores basados ​​en el tráfico de producción y el comportamiento del usuario.

Esto debería permitirle usar algunas secuencias de comandos para generar y destruir programáticamente conjuntos de datos completos (y grandes) para usar con metodologías de implementación continua.

Escalabilidad y alta disponibilidad

Mientras que pediste acerca de la implementación continua, DevOps se conserned con más de simplemente implementación continua - por lo que voy a incluir algunos bits sobre la redundancia, escalabilidad y alta disponibilidad.

Mencioné, JIT, consistencia inmediata y eventual. Aquí es donde entran en juego los vastos motores RDBMS. La consistencia eventual es relativamente fácil simplemente configurando la replicación asincrónica circular. Sin embargo, esto puede causar algunas colisiones * (¿qué sucede si la capa de aplicación actualiza los datos en un lado del clúster y en el otro lado del clúster antes de que se complete la replicación?) Para obtener consistencia inmediata, observe el clúster Galera que forzará la replicación sincrónica, pero causa problemas de escalabilidad (¿cómo se replicará en su sitio de recuperación ante desastres o equilibrará la carga geográficamente sin incurrir en una latencia significativa debido al retraso de la propagación en la capa de red?) También puede ver si puede hacer una replicación sincrónica dentro del centro de datos y una replicación asincrónica entre sitios, pero esto parece lo peor de ambos mundos.

Sin embargo, por lo general, la mayoría de las personas no necesitan una replicación totalmente síncrona; por lo general, esto solo se necesita para entornos de escritura alta muy específicos (y exóticos) en los que se necesita multimaestro con fragmentación de tabla. La mayoría de las aplicaciones pueden lidiar con la coherencia Just-In-Time utilizando un proxy de base de datos. Por ejemplo, ScaleArc supervisará el estado de la replicación y rastreará dónde se acaban las escrituras (para enviar solicitudes de lectura posteriores hasta que la replicación se ponga al día) para proporcionar la coherencia Just-In-Time y la aparienciade consistencia de la base de datos. ScaleArc es compatible con Postgres, MySQL, MariaDB, Oracle y MSSQL y puede usar expresiones regulares para particionar / particionar sus bases de datos para aplicaciones que no pueden utilizar claves de particiones. También tiene una API REST robusta para que su software de administración de configuración interactúe, y su equipo de soporte es excepcional

Del mismo modo, es posible que desee considerar una alternativa gratuita, MaxScale desarrollado por el equipo de MariaDB para MariaDB. Sin embargo, carece de la GUI y algunas de las características de almacenamiento en caché de ScaleArc.

Finalmente, el tejido MySQL (y el Clúster MySQL solo en RAM, si puede permitirse tanta RAM) son otros potenciales, especialmente con el nuevo proxy de MySQL. Esto puede proporcionar el componente de escalabilidad y redundancia a su entorno.

Postgres y Oracle deberían tener las características de replicación y fragmentación que necesita, pero ScaleArc se emparejará bien si necesita un proxy.

En última instancia, todas estas partes se suman a un entorno altamente flexible adecuado para la implementación y el desarrollo continuos si no puede simplemente usar un entorno basado en la nube y dejar que su proveedor de nube se encargue de los problemas anteriores por usted.

Utilizamos Flyway en el trabajo para administrar los esquemas de Postgres en la aplicación, y Pillar para administrar los esquemas de Cassandra. Lo hemos encontrado mejor si la aplicación gestiona su propio esquema.

Tuvimos una experiencia horrible tener ansible gestionar esquemas antes de que las aplicaciones gestionan sus propios esquemas.

Yo diría que una herramienta por sí sola no ayudará realmente a menos que transfiera la responsabilidad del esquema al equipo de aplicación.

Hacemos uso Liquibase o ruta de vuelo en el trabajo, donde el equipo de aplicación es responsable de crear los conjuntos de cambios.

Junto con esto, puede evitar una forma puramente aditiva.
Se requiere que cada aplicación sea compatible con su versión precedente, cuando se debe hacer una alteración del esquema, entonces la aplicación integrará una nueva columna en el esquema, escribirá en ella y aún leerá y escribirá desde / hacia la columna anterior (permitiendo versión anterior para tener los mismos datos).
La próxima versión de la aplicación puede dejar de actualizar la columna anterior y solo la tercera versión podrá eliminar la columna ahora no utilizada.

Obviamente, se necesitan copias de seguridad regulares en caso de que algo salga mal.
También es una buena idea un subconjunto de datos adecuado que pueda crear problemas en las pruebas de integración para evitarlos en la producción. El caso ideal es obtener un subconjunto anónimo de datos de producción.

Usamos liquibase en nuestro trabajo y hablaré muy bien por ello. También lo utiliza nuestra herramienta de control de calidad QASymphony .

Lo estamos utilizando contra bases de datos MSSQL y Oracle internamente y QASymphony lo usa / lo ha usado con ambas instancias postgres + mysql.

Para responder a esta pregunta en el contexto de un entorno de mainframe y específico para las bases de datos DB2, generalmente hay 2 alternativas comúnmente utilizadas (no baratas ...) para elegir:

• Administración de objetos para DB2 , de BMC. Aquí hay algunos detalles al respecto (cita de la página vinculada):

  Realizar cambios en los objetos de su base de datos, o incluso simplemente realizar tareas administrativas de rutina, puede ser un trabajo difícil y riesgoso. Hay docenas de tareas para realizar un seguimiento, y un solo paso en falso podría tener un impacto desastroso en la disponibilidad y la integridad de los datos. Puede reducir tanto el esfuerzo como el riesgo con BMC Object Administration para DB2 11, una colección de herramientas para ayudarlo a:

  • Reduzca el tiempo requerido para administrar entornos complejos y dispares de DB2.
  • Automatice las tareas de rutina a lo largo del ciclo de vida de la aplicación para mejorar la integridad.
  • Mejore la productividad con la navegación simplificada del catálogo de DB2 y la gestión de cambios.
  • Mejore la disponibilidad de la aplicación realizando cambios y mantenimiento con interrupciones mínimas.

• Herramienta de administración de DB2 para z / OS , de IBM.

  Simplifica las tareas complejas asociadas con la gestión segura de objetos y esquemas de DB2 durante todo el ciclo de vida de la aplicación con el menor impacto posible en la disponibilidad.

  • Permite a los usuarios navegar por el catálogo de DB2 rápida y fácilmente
  • Crea y ejecuta sentencias SQL dinámicas sin conocer la sintaxis exacta de SQL
  • Gestiona y realiza un seguimiento de los cambios realizados en las definiciones de objetos de DB2 para resolver posibles conflictos antes de la ejecución
  • Ayuda a construir comandos de DB2 para ejecutar contra bases de datos y tablas
  • Permite a los usuarios crear, alterar, migrar, soltar y aplicar ingeniería inversa a objetos de DB2
  • Crea y ejecuta trabajos de servicios públicos, lo que permite a los usuarios aprovechar las LISTDEF y las PLANTILLAS para aumentar la productividad

Integración con herramientas SCM

Hace un tiempo, un cliente me retó a "integrar" la alternativa BMC en su ciclo de vida SCM (administrado por SERENA ChangeMan ZMF ). La idea detrás de dicha integración es " Considere a nuestro equipo DBA de DB2 (haciendo cosas con DDL) como un caso especial de un equipo de desarrollo, usando accidentalmente algún editor exótico (la herramienta BMC) para producir el código (DDL) que se migrará ".

El único desafío (¡pero real !) De esta integración fue también facilitar la "reiniciabilidad", que es uno de los beneficios clave de dicha herramienta DBA:

• La reiniciabilidad significa que cuando esta herramienta DBA está haciendo lo suyo (a través de trabajos a veces largos, según la naturaleza del trabajo a completar), pueden suceder cosas inesperadas (puntos muertos, interrupciones del tiempo, etc.).

• Si alguna de esas cosas sucede, y no desea reiniciar desde su copia de seguridad (antes de comenzar), la herramienta DBA espera que reinicie desde el punto (check-) desde el cual las cosas comenzaron a salir mal (y desde dónde quieres que todo se vuelva a ejecutar).

• Mejor aún (¿o debería decir "aún peor"?), Si un nuevo usuario de la herramienta DBA no sabe cómo reiniciar desde dicho punto de control, y simplemente intenta de nuevo (desde el principio), entonces la herramienta DBA simplemente fallará con algún tipo de error del usuario. Y esto con una indicación con algo como " Hasta que me digas cómo quieres que proceda después de mi último punto de falla, me niego a hacer algo (para no empeorar las cosas) ".

• Al final, la pista real para implementar esta reiniciabilidad en la herramienta SCM que se usaba, requería que la herramienta SCM también se ajustara. En realidad, para permitir que se use para reiniciar procedimientos SCM fallidos (generalmente relacionados con entregas a entornos de prueba / producción objetivo) ... en lugar de simplemente enviar el procedimiento SCM fallido nuevamente (que es la forma en que esas herramientas SCM se recuperan de tales situaciones) )

Bonificación: después de que se completó la integración SCM de la alternativa BMC, el cliente decidió cambiar su herramienta DBA a la alternativa IBM. Y a pesar de que ambas alternativas no se ven realmente iguales, el impacto de esto en la integración de SCM fue bastante mínimo: simplemente fue cuestión de reemplazar (en alguna personalización de SCM reutilizable) algunas llamadas a la alternativa de BMC por las llamadas equivalentes a IBM alternativa ... que (usando la terminología de DevOps) se implementó mediante feature-flags / feature-toggles .