A medida que el negocio se expande y la cantidad de datos se acumula, la capacidad de datos y la potencia informática del sistema de base de datos se irán desbordando gradualmente, por lo que un sistema de base de datos excelente debe tener una buena escalabilidad. Los nodos de datos en el clúster DolphinDB integran la computación y el almacenamiento, por lo tanto, para mejorar la potencia de computación y la capacidad de los datos, solo necesita apuntar a los nodos de datos. DolphinDB admite tanto la expansión horizontal, lo que significa agregar nodos, como la expansión vertical, lo que significa aumentar el almacenamiento de nodos.
Antes de expandir el clúster, debe tener un concepto básico del clúster DolphinDB. El clúster de DolphinDB se compone de 3 roles: controlador, agente y nodo de datos. Las tareas asignadas a cada rol son las siguientes:
- El nodo de control es responsable de administrar los metadatos y proporcionar herramientas de administración de clústeres web.
- El nodo de agente es responsable del inicio y la parada del nodo, y debe haber un nodo de agente en cada servidor.
- El nodo de datos es responsable del cálculo y almacenamiento.
Los archivos de configuración relacionados con el clúster generalmente se encuentran en el directorio de configuración:
controller.cfg: Ubicado en el servidor donde se ubica el nodo de control, es responsable de definir la configuración relevante del nodo de control, como IP, número de puerto y límite superior del número de conexiones del nodo de control.
cluster.cfg: Ubicado en el servidor donde se ubica el nodo de control, se encarga de definir la configuración personalizada de cada nodo del cluster, como ruta de almacenamiento, número de conexiones, límite de memoria, etc.
cluster.nodes: ubicado en el servidor donde se encuentra el nodo de control, el archivo de configuración de miembros del clúster, incluida la IP del nodo, el puerto, el alias del nodo y el rol.
agent.cfg: contiene la IP y el puerto del nodo del agente y la IP y el puerto del nodo de control. Cada servidor físico debe tener un nodo de agente.
Si el clúster se escala horizontalmente, es necesario modificar el archivo de configuración de miembros (cluster.nodes) del clúster. Si el nodo de datos está ubicado en un nuevo servidor físico, se debe implementar un nuevo nodo de agente (agent.cfg) para que sea responsable del nodo en la nueva máquina física. Inicie y detenga, y luego reinicie el nodo de control para cargar el nuevo nodo de datos. Cuando se inicia un nuevo nodo de datos, la potencia informática del nodo se incluirá inmediatamente en la planificación de recursos informáticos del clúster, pero los datos que se han almacenado en el clúster no se ajustarán al nuevo nodo de datos, y el sistema asignará los siguientes datos recién ingresados de acuerdo con la estrategia. Varios nodos de datos.
Si se trata de un clúster expandido verticalmente, solo necesita modificar el archivo de configuración (cluster.cfg) del nodo de datos para agregar una ruta al parámetro de volumen del nodo especificado.
Los pasos para expandir el clúster se describen en detalle a continuación.
1. Instrucciones de configuración del clúster
Para la implementación de clústeres, consulte el tutorial Implementación de clústeres de servidores multifísicos .
El clúster de ejemplo tiene 3 nodos de datos, cada nodo de datos está ubicado en un servidor físico y el nodo de control está ubicado en otro servidor físico:
Nodo de control: 172.18.0.10
Nodo de datos 1: 172.18.0.11
Nodo de datos 2: 172.18.0.12
Nodo de datos 3: 172.18.0.13
La información de cada archivo de configuración es la siguiente:
controller.cfg
localSite = 172.18.0.10: 8990: ctl8990
cluster.nodes
localSite, modo 172.18.0.11:8701:agent1,agent 172.18.0.12:8701:agent2,agent 172.18.0.13:8701:agent3,agent 172.18.0.11:8801:node1,datanode 172.18.0.12:8802:node2,datanode 172.18. 0.13: 8803: nodo3, nodo de datos
Agent.cfg en el servidor físico donde se encuentra el nodo de datos 1
localSite = 172.18.0.11: 8701: agent1 controllerSite = 172.18.0.10: ctl8900
Para reflejar el efecto expandido, primero establecemos
Cree una base de datos distribuida en el grupo y escriba datos:
data = table (1..1000 como id, rand (`A`B`C, 1000) como nombre)
// Se reserva una reserva de 1000 para particiones y se utiliza para pruebas de escritura posteriores.
db = database (" dfs: //scaleout_test_db",RANGE,cutPoints(1..2000,10))
tb = db.createPartitionedTable (datos, "scaleoutTB", `id)
tb.append! (datos)
Después de la ejecución, observe la distribución de datos a través de DFS Explorer en la Web:
Después de expandir el clúster, podemos observar si el nuevo nodo o almacenamiento está habilitado agregando nuevos datos.
2. Expansión horizontal
Debido al aumento en el volumen de datos comerciales, la capacidad de almacenamiento y computación del clúster no puede cumplir con los requisitos, ahora se agrega un nuevo servidor y se agrega al clúster original como un nuevo nodo. La dirección IP del servidor recién agregada es 172.18.0.14, el número de puerto es 8804 y el alias es node4. El nuevo servidor necesita implementar el nodo del agente, utilizando el puerto 8701, el alias es agent4.
Proceder de la siguiente:
(1) Implementar nuevos nodos de agentes
Copie el paquete de instalación de DolphinDB en el nuevo servidor y descomprímalo. Agregue una nueva carpeta de configuración en la carpeta del servidor y cree agent.cfg, agregando el siguiente contenido:
#Especifique la ip y el puerto del propio Agente localSite = 172.18.0.14: 8701: agent4 #Dígale al Agente la ubicación del controlador de este clúster controllerSite = 172.18.0.10: 8990: ctl8990 mode = agent
(2) Modificar la configuración de los miembros del clúster
Vaya al servidor físico donde se encuentra el nodo de control, modifique config / cluster.nodes y agregue la información de los miembros del clúster. Los contenidos del archivo modificado son:
localSite, modo 172.18.0.11:8701:agent1,agent 172.18.0.12:8701:agent2,agent 172.18.0.13:8701:agent3,agent 172.18.0.14:8701:agent4,agent 172.18.0.11:8801:node1,datanode 172.18. 0.12: 8802: nodo2, nodo de datos 172.18.0.13:8803:nodo3,datanode 172.18.0.14:8804:nodo4,datanode
(3) Reinicie el clúster
En el entorno Linux, use el comando pkill dolphindb para cerrar el clúster. Después de esperar a que se liberen los recursos del puerto, reinicie el controlador y cada agente. El comando es el siguiente:
Inicie el controlador:
nohup ./dolphindb -console 0 -mode controller -script dolphindb.dos -config config / controller.cfg -logFile log / controller.log -nodesFile config / cluster.nodes &
Inicie el agente:
./dolphindb -mode agent -datos de inicio -script dolphindb.dos -config config / agent.cfg -logFile log / agent.log
Ingrese la IP y el número de puerto del nodo de control en la barra de direcciones del navegador, como 172.18.0.10:8990, para acceder a la Web, podemos ver que se ha iniciado el nuevo nodo de agente agent4 y que el nodo de datos node4 está cerrado.
Inicie cada nodo y el clúster se puede utilizar normalmente.
A continuación, escribimos algunos datos en la base de datos dfs: // scaleout_test_db en el clúster para verificar si se ha habilitado el nuevo nodo de datos.
tb = database ("dfs: // scaleout_test_db") .loadTable ("scaleoutTB")
tb.append! (table (1001..1500 como id, rand (`A`B`C, 500) como nombre))
Observe el Explorador de DFS, puede ver que hay datos distribuidos al nuevo nodo node4.
A veces nos encontraremos con que algunos datos se migrarán a otros nodos. Esto está relacionado con el mecanismo de recuperación de DolphinDB. El clúster DolphinDB admite la recuperación automática de datos. Cuando el sistema detecta que algunos nodos del clúster no han tenido un latido durante mucho tiempo, se determina que está inactivo y los datos se restaurarán automáticamente a partir de otras copias y la cantidad de copias de todo el clúster se mantendrá estable. Esta es la razón por la que los datos migrarán cuando un nodo no se haya iniciado durante mucho tiempo. El mecanismo de recuperación de DolphinDB está relacionado con los siguientes parámetros de configuración del nodo de control:
# El número de copias de cada dato en el clúster, el valor predeterminado es 2 dfsReplicationFactor = 2 #Replica la política de seguridad, se permite que existan más de 0 copias en un nodo 1 Se deben almacenar múltiples copias en diferentes nodos, el valor predeterminado es 0 dfsReplicaReliabilityLevel = 1 # ¿ Cuánto tiempo se detiene el latido del nodo e inicia la recuperación , No habilitado por defecto, unidad ms dfsRecoveryWaitTime = 30000
dfsRecoveryWaitTime controla el inicio de la recuperación. Si este parámetro no está configurado, la función de recuperación se desactivará. El valor predeterminado es desactivado. La configuración del tiempo de espera es principalmente para evitar una recuperación innecesaria causada por algunas paradas y mantenimiento planificados, y debe ser configurado por el usuario de acuerdo con la situación real de operación y mantenimiento.
En términos de estabilidad, cuantas más réplicas, es menos probable que se pierdan datos accidentalmente, pero demasiadas réplicas también conducirán a un rendimiento deficiente cuando el sistema guarda datos, por lo que no se recomienda que el valor de dfsReplicationFactor sea inferior a 2, pero las configuraciones específicas requieren usuarios Considere de manera integral en función de la cantidad de nodos en el clúster general, los requisitos de estabilidad de datos y los requisitos de rendimiento de escritura del sistema.
Se recomienda que dfsReplicaReliabilityLevel se establezca en 1 en un entorno de producción, es decir, varias réplicas se encuentran en diferentes servidores.
3. Expansión vertical
Suponiendo que el espacio en disco del servidor donde se encuentra node3 es insuficiente, ahora se agrega un disco con la ruta / dev / disk2, que debe incluirse en el almacenamiento de node3. La ruta de almacenamiento del nodo de datos se especifica mediante el parámetro de volumen en el archivo de configuración. Si el clúster inicial no especifica el parámetro de volumen, la ruta de almacenamiento predeterminada es [HomeDir] / DataNodeAlias] / storage, es decir, la ruta de almacenamiento predeterminada de node3 es data / node3 / storage .
Agregue el siguiente contenido al archivo cluster.cfg del nodo de control:
node3.volumes = data / node3 / storage, / dev / disk2 / node3
Tenga en cuenta que si necesita agregar una ruta de almacenamiento después de la ruta predeterminada, debe establecer explícitamente la ruta predeterminada; de lo contrario, se perderán los metadatos de la ruta predeterminada.
Después de modificar la configuración, solo necesita reiniciar el nodo de datos, no el nodo de control.
A continuación, escriba nuevos datos en el clúster para ver si los datos se escriben en el nuevo disco.
tb = database ("dfs: // scaleout_test_db") .loadTable ("scaleoutTB")
tb.append! (table (1501..2000 como id, rand (`A`B`C, 500) como nombre))
Vaya al disco para observar si los datos están escritos:
No existe un límite superior claro en el tamaño de los datos que DolphinDB puede admitir, y depende completamente de la cantidad de recursos invertidos.