MongoDB Tag Aware Sharding permite a los administradores controlar la distribución de datos en un clúster fragmentado definiendo rangos de clave de fragmento y etiquetarlos en uno o más fragmentos.
Este tutorial utiliza zonas junto con una implementación de clúster fragmentado de múltiples centros de datos y lógica del lado de la aplicación para soportar escrituras locales distribuidas, así como alta disponibilidad de escritura en caso de una elección de conjunto de réplicas o una falla del centro de datos.
Al definir las zonas y sus rangos antes de fragmentar una colección vacía o inexistente, la operación de recopilación de fragmentos crea fragmentos para los rangos de zona definidos, así como fragmentos adicionales para cubrir todo el rango de valores de clave de fragmento, y realiza una distribución inicial de fragmentos basada en los rangos de zona. Esta creación y distribución inicial de fragmentos permite una configuración más rápida de la fragmentación por zonas. Tras la distribución inicial, el balanceador gestiona la distribución de fragmentos en adelante.
Consulte Zonas predefinidas y rangos de zonas para una colección vacía o inexistente para ver un ejemplo.
Importante
Los conceptos comentados en este tutorial requieren una arquitectura de implementación específica y lógica a nivel de aplicación.
Estos conceptos requieren familiaridad con los clústeres fragmentados de MongoDB, los conjuntos de réplicas y el comportamiento general de las zonas.
Este tutorial asume una carga de trabajo de solo inserción o con un uso intensivo de la misma. Los conceptos y estrategias que se describen en este tutorial no son adecuados para casos de uso que requieren lecturas o actualizaciones rápidas.
Scenario
Considere una aplicación con un uso intensivo de inserciones, donde las lecturas son poco frecuentes y de baja prioridad en comparación con las escrituras. La aplicación escribe documentos en una colección fragmentada y requiere un tiempo de actividad casi constante de la base de datos para cumplir sus SLA o SLO.
Lo siguiente representa una vista parcial del formato de los documentos que la aplicación escribe en la base de datos:
{ "_id" : ObjectId("56f08c447fe58b2e96f595fa"), "message_id" : 329620, "datacenter" : "alfa", "userid" : 123, ... } { "_id" : ObjectId("56f08c447fe58b2e96f595fb"), "message_id" : 578494, "datacenter" : "bravo", "userid" : 456, ... } { "_id" : ObjectId("56f08c447fe58b2e96f595fc"), "message_id" : 689979, "datacenter" : "bravo", "userid" : 789, ... }
Clave de fragmento
La colección utiliza el { datacenter : 1, userid : 1 } índice compuesto como clave de fragmento.
El campo datacenter de cada documento permite crear un rango de etiquetas para cada valor de centro de datos. Sin el campo datacenter, no sería posible asociar un documento con un centro de datos específico.
El userid campo proporciona una cardinalidad alta y un componente de frecuencia baja a la clave del fragmento en relación datacenter con.
Arquitectura
La implementación consiste en dos centros de datos, alfa y bravo. Existen dos particiones, shard0000 y shard0001. Cada partición es un set de réplicas con tres miembros. shard0000 tiene dos nodos en alfa y un nodo de prioridad 0 en bravo. shard0001 tiene dos nodos en bravo y un nodo de prioridad 0 en alfa.
Etiquetas
Esta aplicación requiere una etiqueta por centro de datos. Cada fragmento tiene una etiqueta asignada según el centro de datos que contenga la mayoría de los miembros de su conjunto de réplicas. Hay dos rangos de etiquetas, uno para cada centro de datos.
alfaDatacenterEtiqueta los fragmentos con una mayoría de miembros en este centro de datos como
alfa.Crea un rango de etiquetas con:
un límite inferior de
{ "datacenter" : "alfa", "userid" : MinKey },un límite superior de
{ "datacenter" : "alfa", "userid" : MaxKey }, yla etiqueta
alfa
bravoDatacenterEtiqueta los fragmentos con una mayoría de miembros en este centro de datos como
bravo.Crea un rango de etiquetas con:
un límite inferior de
{ "datacenter" : "bravo", "userid" : MinKey },un límite superior de
{ "datacenter" : "bravo", "userid" : MaxKey }, yla etiqueta
bravo
Nota
Los valores MinKey y MaxKey son valores especiales reservados para comparaciones
Según las etiquetas y los rangos de etiquetas configurados, mongos enruta los documentos con datacenter : alfa al alfa centro de datos y los documentos con datacenter : bravo al bravo centro de datos.
Operaciones de escritura
Si un documento insertado o actualizado coincide con un rango de etiquetas configurado, solo se puede escribir en un fragmento con la etiqueta relacionada.
MongoDB puede escribir documentos que no coincidan con un rango de etiquetas configurado en ningún fragmento del clúster.
Nota
El comportamiento descrito anteriormente requiere que el clúster se encuentre en un estado estable sin fragmentos que infrinjan un rango de etiquetas configurado. Consulte la siguiente sección sobre el balanceador para obtener más información.
Balanceador
El balanceador migra los fragmentos etiquetados al fragmento correspondiente. Hasta la migración, los fragmentos pueden contener fragmentos que infrinjan los rangos de etiquetas y las etiquetas configuradas. Una vez completado el balanceo, los fragmentos solo deben contener fragmentos cuyos rangos no infrinjan las etiquetas ni los rangos de etiquetas asignados.
Añadir o eliminar etiquetas o rangos de etiquetas puede provocar migraciones de fragmentos. Según el tamaño del conjunto de datos y la cantidad de fragmentos afectados por un rango de etiquetas, estas migraciones pueden afectar el rendimiento del clúster. Considere ejecutar el balanceador durante períodos programados específicos.Consulte "Programar el período de balanceo" para obtener un tutorial sobre cómo configurar un período de programación.
Comportamiento de la aplicación
De forma predeterminada, la aplicación escribe en el centro de datos más cercano. Si el centro de datos local está inactivo o si no se confirman las escrituras en él dentro de un plazo determinado, la aplicación cambia al otro centro de datos disponible modificando el valor del campo datacenter antes de intentar escribir el documento en la base de datos.
La aplicación admite tiempos de espera de escritura. Utiliza Write Concern para establecer un tiempo de espera para cada operación de escritura.
Si la aplicación detecta un error de escritura o de tiempo de espera, modifica el datacenter campo en cada documento y realiza la escritura. Esto dirige el documento al otro centro de datos. Si ambos centros de datos están inactivos, las escrituras no se pueden realizar correctamente.Consulte Resolver errores de escritura.
La aplicación comprueba periódicamente la conectividad con los centros de datos marcados como "inactivos". Si se restablece la conectividad, la aplicación puede continuar realizando operaciones de escritura con normalidad.
Dada la lógica de conmutación, así como los balanceadores de carga o mecanismos similares implementados para gestionar el tráfico de clientes entre centros de datos, la aplicación no puede predecir en cuál de los dos centros de datos se escribió un documento determinado. Para garantizar que no se pierda ningún documento durante las operaciones de lectura, la aplicación debe realizar consultas de difusión sin incluir el datacenter campo en ninguna consulta.
La aplicación realiza lecturas utilizando una preferencia de lectura de para reducir nearest la latencia.
Es posible que una operación de escritura se complete correctamente a pesar de un error de tiempo de espera. La aplicación responde al error intentando reescribir el documento en el otro centro de datos; esto puede provocar la duplicación del documento en ambos centros de datos. La aplicación resuelve los duplicados como parte de la lógica de lectura.
Lógica de conmutación
La aplicación tiene la lógica para cambiar de centro de datos si uno o más guardados fallan o si los guardados no se confirman dentro de un periodo de tiempo determinado. La aplicación modifica el campo datacenter según la etiqueta del centro de datos objetivo para dirigir el documento hacia ese centro de datos.
Por ejemplo, una aplicación que intenta guardar en el centro de datos alfa podría seguir este procedimiento general:
Intente escribir el documento, especificando
datacenter : alfa.En caso de tiempo de espera de escritura o error, se registra
alfacomo momentáneamente inactivo.Intente escribir el mismo documento, modificando
datacenter : bravo.En caso de tiempo de espera de escritura o error, se registra
bravocomo momentáneamente inactivo.Si tanto
alfacomobravoestán inactivos, se deben registrar e informar los errores.
Procedimiento
Configurar etiquetas de fragmentos
Para continuar, debe estar conectado a un asociado mongos al clúster fragmentado de destino. No puede crear etiquetas conectándose directamente a un miembro del conjunto de réplicas de fragmentos.
Etiqueta cada fragmento.
Etiquete cada fragmento en el centro de datos alfa con la etiqueta alfa.
sh.addShardTag("shard0000", "alfa")
Etiquete cada fragmento en el centro de datos bravo con la etiqueta bravo.
sh.addShardTag("shard0001", "bravo")
Puede revisar las etiquetas asignadas a cualquier fragmento determinado sh.status() ejecutando.
Define rangos para cada etiqueta.
Defina el rango de la alfa base de datos y asócielo a la alfa etiqueta mediante el método. Este método sh.addTagRange() requiere:
El espacio de nombres completo de la colección de destino.
El límite inferior inclusivo del rango.
El límite superior exclusivo del rango.
El nombre de la etiqueta.
sh.addTagRange( "<database>.<collection>", { "datacenter" : "alfa", "userid" : MinKey }, { "datacenter" : "alfa", "userid" : MaxKey }, "alfa" )
Defina el rango de la bravo base de datos y asócielo a la bravo etiqueta mediante el método. Este método sh.addTagRange() requiere:
El espacio de nombres completo de la colección de destino.
El límite inferior inclusivo del rango.
El límite superior exclusivo del rango.
El nombre de la etiqueta.
sh.addTagRange( "<database>.<collection>", { "datacenter" : "bravo", "userid" : MinKey }, { "datacenter" : "bravo", "userid" : MaxKey }, "bravo" )
Los valoresMinKeyyMaxKeyson valores especiales reservados para comparaciones. MinKeysiempre se compara como menor que cualquier otro valor posible, mientras queMaxKeysiempre se compara como mayor que cualquier otro valor posible. Los rangos configurados capturan a todos los usuarios para cada datacenter.
Revisa los cambios.
La próxima vez que se ejecute el balanceador, migrará los datos a través de los fragmentos respetando las zonas configuradas.
Una vez finalizado el equilibrio, los fragmentos etiquetados como alfa solo deben contener documentos con datacenter : alfa, mientras que los fragmentos etiquetados como bravo solo deben contener documentos con datacenter : bravo.
Puedes revisar la distribución de fragmentos ejecutando sh.status().
Resolver fallo de escritura
Cuando el centro de datos predeterminado de la aplicación está inactivo o es inaccesible, la aplicación cambia el campo datacenter al otro centro de datos.
Por ejemplo, la aplicación intenta escribir el siguiente documento en el centro de datos alfa de forma predeterminada:
{ "_id" : ObjectId("56f08c447fe58b2e96f595fa"), "message_id" : 329620, "datacenter" : "alfa", "userid" : 123, ... }
Si la aplicación recibe un error al intentar escribir, o si el reconocimiento de escritura tarda demasiado, la aplicación registra el centro de datos como no disponible y modifica el campo datacenter para apuntar al centro de datos bravo.
{ "_id" : ObjectId("56f08c457fe58b2e96f595fb"), "message_id" : 329620, "datacenter" : "bravo", "userid" : 123, ... }
La aplicación comprueba periódicamente la conectividad del centro de datos alfa. Si se vuelve a poder acceder al centro de datos, la aplicación puede reanudar las escrituras normales.
Nota
Es posible que la escritura original en se haya datacenter : alfa realizado correctamente, especialmente si el error se debió a un tiempo de espera. De ser así, el documento con message_id : 329620 podría estar duplicado en ambos centros de datos. Las aplicaciones deben resolver los duplicados como parte de las operaciones de lectura.
Resolver documentos duplicados en las lecturas
La lógica de conmutación de la aplicación permite la posible duplicación de documentos. Al realizar lecturas, la aplicación resuelve cualquier documento duplicado en la capa de aplicación.
La siguiente consulta busca documentos donde userid 123es. Tenga en cuenta que, si bien userid forma parte de la clave de fragmento, la consulta no incluye el datacenter campo y, por lo tanto, no realiza una operación de lectura específica.
db.collection.find( { "userid" : 123 } )
Los resultados muestran que el documento con message_id de 329620 se ha insertado en MongoDB dos veces, probablemente como resultado de un reconocimiento de escritura retrasado.
{ "_id" : ObjectId("56f08c447fe58b2e96f595fa"), "message_id" : 329620 "datacenter" : "alfa", "userid" : 123, data : {...} } { "_id" : ObjectId("56f08c457fe58b2e96f595fb"), "message_id" : 329620 "datacenter" : "bravo", "userid" : 123, ... }
La aplicación puede ignorar los duplicados y tomar uno de los dos documentos o puede intentar recortar los duplicados hasta que solo quede un único documento.
Un método para eliminar duplicados es usar el método para extraer la marca de tiempo ObjectId.getTimestamp() del _id campo. La aplicación puede entonces conservar el primer o el último documento insertado. Esto supone que el _id campo usa MongoDB.ObjectId()
Por ejemplo, al usar en el documento con getTimestamp() se ObjectId("56f08c447fe58b2e96f595fa") devuelve:
ISODate("2016-03-22T00:05:24Z")
getTimestamp() El uso de en el documento con ObjectId("56f08c457fe58b2e96f595fb") devuelve:
ISODate("2016-03-22T00:05:25Z")