antecedentes
Debido a que es un negocio de mensajes cortos, a medida que aumenta el negocio de la compañía, la presión sobre la base de datos también aumenta. El volumen de datos actual es de aproximadamente 7 mil millones, y Mongo solo almacena datos en una semana, que es casi 100 millones. Antes quería ahorrar costos, por lo que siempre ha sido una instancia única. Con el creciente número de clientes de acceso, la cantidad de mensajes de texto enviados todos los días también ha comenzado a aumentar significativamente. Lo más preocupante es pasar las vacaciones, y me ha preocupado si Mongo de repente cuelga, ¡jaja! Esa es la programación orientada a la muerte.
Enredado
Después de varias discusiones, finalmente se decidió utilizar el procesamiento de separación de lectura y escritura del conjunto de réplicas de Mongo, por lo que comenzó la transformación del servicio.
Listo
- Se han implementado varios servidores (192.168.0.101, 192.168.0.102, 192.168.0.103, 192.168.0.104) en máquinas Mongo, instalar Mongo referencia: Linux instalar Mongo
- Descripción de la máquina: Dos Mongo son bibliotecas esclavas, una solo es responsable de votar los nodos y no de procesar los nodos de datos (192.168.0.104)
potenciar
Archivo de clave
A través de la autenticación de archivo de claves , cada instancia de mongod en el conjunto de réplicas utiliza el contenido del archivo de claves como una contraseña compartida para autenticar a otros miembros en la implementación. Solo las instancias mongod con el archivo de clave correcto pueden unirse al conjunto de réplicas. La longitud del contenido del archivo de claves debe tener entre 6 y 1024 caracteres, y todos los miembros del conjunto de réplicas deben ser iguales.
openssl rand -base64 756 > /key/mongodb-keyfile
chmod 400 /key/mongodb-keyfileCopie el archivo de claves en cada servidor que aloje a los miembros del conjunto de réplicas. Asegúrese de que el usuario que ejecuta la instancia de mongod sea el propietario del archivo y pueda acceder al archivo de claves.
Modificar la configuración de Mongo de cada servicio
Primero, detenga la instancia única de Mongo (comando: systemctl stop mongod), modifique la información de configuración de red, seguridad y replicación en el archivo de configuración de mongo /etc/mongod.conf
net:
port: 27017
bindIp: 0.0.0.0 # 允许所有ip远程连接Mongo
security:
authorization: enabled # 用户只能访问已为其授予特权的数据库资源和操作。
keyFile: /key/mongodb-keyfile # 秘钥文件路径
replication:
replSetName: "S1" # 副本集名称
enableMajorityReadConcern: false # 以为有投票节点，禁用该功能以防止存储高速缓存压力使部署无法固定。
Iniciar Mongo
Use el comando (systemctl start mongo) para ingresar mongo (Mongo que espera ser el nodo maestro) y ejecute la configuración del conjunto de réplicas procesado
rs.initiate( {
_id : "s1",
members: [
{ _id: 0, host: "192.168.0.101:27017" },
{ _id: 1, host: "192.168.0.102:27017" },
{ _id: 2, host: "192.168.0.103:27017" },
{ _id: 3, host: "192.168.0.104:27017",arbiterOnly:true },
]
})Verifique la configuración del conjunto de réplicas, la actualización está completa (verificación de conexión remota)
rs.conf();Agregar miembros temporales al conjunto de réplicas
rs.add( { host: "192.168.0.105:27017", priority: 0, votes: 0 } )Nota:
Cuando los votos y la configuración de prioridad del nodo secundario recién agregado son mayores que cero, durante su sincronización inicial, incluso si el nodo secundario no puede proporcionar lectura o convertirse en el nodo primario, porque sus datos aún son inconsistentes, el nodo secundario aún se cuenta como miembro con derechos de voto. .
Esto puede resultar en una situación en la que la mayoría de los miembros votantes estén en línea pero no puedan elegir a los miembros principales. Para evitar esta situación, considere usar la prioridad: 0 y los votos: 0 para agregar nuevos servidores secundarios primero. Luego, una vez que el miembro haya pasado al estado SECUNDARIO , use rs.reconfig () para actualizar su prioridad y voto.
Si el documento de configuración devuelto por rs.conf () es el quinto elemento en la matriz de miembros para actualizar su prioridad y votar por él , use la siguiente secuencia de operaciones192.168.0.105:270171
var cfg = rs.conf();
cfg.members[4].priority = 1
cfg.members[4].votes = 1
rs.reconfig(cfg)Problema anormal
1. La autorización de lectura del archivo de clave secreta falló de manera anormal, lo que provocó un error de inicio
{"t":{"$date":"2020-10-17T14:38:26.085+08:00"},"s":"I", "c":"ACCESS", "id":20254, "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"Error reading file /key/mongodb-keyfile: Permission denied"}}}
solución:
Estaba pensando si los permisos eran demasiado pequeños, así que autoricé directamente los permisos 777 y descubrí que el error de archivo Permiso demasiado abierto se informó directamente, por lo que el programa de permisos se expandió directamente.
1. De forma predeterminada, MongoDB se mongodejecuta con una cuenta de usuario. Después de la creación, configure el propietario y el grupo del directorio en mongod:
sudo chown -R mongod:mongod /key/mongodb-keyfile2. De acuerdo con la documentación oficial, puede leer el archivo con éxito siempre que modifique el grupo de archivos, pero desafortunadamente todavía no puede leer el archivo. A través de varios materiales de búsqueda, la solución final se puede encontrar en el archivo de permisos del directorio oficial de Rad Hat Linux. Cambiar la configuración de la política de SELinux
chcon system_u:object_r:mongod_var_lib_t:s0 /key/mongodb-keyfile2. Error demasiado abierto al leer el archivo de clave secreta
solución:
1. Porque en los sistemas UNIX, el archivo de claves no debe tener permisos de grupo o mundiales. En los sistemas Windows, no se comprueban los permisos del archivo clave. Por lo tanto, solo necesita abrir el permiso de lectura, no se permite que el permiso sea demasiado grande
chmod 400 /key/mongodb-keyfileDocumentos de referencia:
https://docs.mongodb.com/manual/
https://stackoverflow.com/questions/28251531/permission-denied-to-read-file-owned-by-user