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:
- 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
- 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.
- 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)
- 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:
- 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.
- 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.
- 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.
- 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.