¿Es esta una estrategia de respaldo válida para MongoDB?

11

Tengo un único servidor dedicado con una base de datos MongoDB de alrededor de 10 GB. Necesito hacer copias de seguridad diarias, pero no puedo tener tiempo de inactividad con la base de datos. ¿Es posible usar una réplica configurada en un solo disco (con 2 instancias de mongod ejecutándose en diferentes puertos), y simplemente desconectar el secundario y hacer una copia de seguridad de los archivos de datos en un almacenamiento externo como S3 (el diario está activado)? ¿O sería mejor usar maestro / esclavo que un conjunto de réplica?

¿Es esto viable y, de ser así, qué problemas potenciales podría tener? Si no, ¿cómo conceptualizo esto para que funcione?

backup database-backup mongodb James Simpson
fuente

Respuestas:

6

ReplicaSet funcionará en este escenario. Sin embargo, no puedo decir si tener dos instancias MongoDB en el mismo servidor es una buena idea, esto depende del hardware / software del servidor y de la carga.

Para asegurarse de que su backupnodo MongoDB no se convierta en maestro, establezca su priorityparámetro en 0, p. Ej.

rs.add({_id: 1, host: "localhost:<port>", priority: 0})

NOTA : si no puede tener tiempo de inactividad, DEBE tener al menos 2 nodos MongoDB primarios en ReplicaSet, vea el artículo

Alexander Azarov
fuente
2

Una estrategia a considerar es usar la opción "oculta" en el nodo de respaldo en su conjunto de réplicas. Del blog de MongoDB:

Los servidores ocultos no aparecerán en los resultados de isMaster (). Esto también significa que no se utilizarán si un conductor distribuye automáticamente las lecturas a los esclavos. Un servidor oculto debe tener una prioridad de 0 (no puede tener un primario oculto). Para agregar un miembro oculto, ejecute:

rs.add ({"_ id": num, "host": nombre de host, "prioridad": 0, "oculto": verdadero})

Travis Dunn
fuente
1

Los conjuntos de réplicas son preferidos en general, pero también en este caso simplemente por su funcionalidad de recuperación automática y resincronización automática. El método de respaldo que está describiendo suena perfectamente razonable y también se ha utilizado anteriormente con otras bases de datos.

El único problema potencial que veo es que, bajo ciertas circunstancias, su secundaria puede ser promovida a su primaria y usted a) necesitará tomar su copia de seguridad de la nueva secundaria, o b) hacer que su script de copia de seguridad sea lo suficientemente inteligente como para indicar esa instancia de MongoDB a renunciar.

La buena noticia es que debería ser bastante trivial para

  1. Consulte su fuente de respaldo para averiguar qué instancia es primaria y cuál es secundaria ( db.isMaster())
  2. Convencer ejemplo de copia de seguridad en el paso hacia abajo usando los rs.freeze()y rs.stepDown()comandos o de reconexión a la secundaria
Charles Hooper
fuente
¿No es una opción establecer la prioridad en 0 como sugiere Alexander para que el secundario nunca se convierta en el primario?
James Simpson
Tendría que hacer algunas pruebas, pero no estoy seguro de si el secundario solo estará en espera si, por algún motivo, el proceso primario deja de funcionar. Siempre quise que mis secundarias se hicieran cargo;)
Charles Hooper
1
>> su secundaria puede ser promovida a su primaria: como se mencionó, establecer la secundaria en prioridad 0 evitará que cambie a maestra.
Jonesome Reinstate Monica
Puede conectarse a cualquiera de los pares de su lista de nodos pares (podría ser cualquier nodo primario, secundario, árbitro o oculto), preguntar a ese par quiénes son los secundarios ( rs.status()y recorrer result["members"]) y conectarse a uno de los secundarios para realizar la copia de seguridad.
yfeldblum