Del portátil al clúster con el mismo binario

El binario que usas para desarrollar es el mismo que corre en producción. Lo que cambia entre tu portátil y un clúster de tres máquinas son las opciones de arranque y la cadena de conexión, no tu aplicación. Lo que sigue recorre ese camino entero, con lo que ves en cada etapa y con lo que tienes que tocar al pasar de una a otra.

En tu máquina

teseladb dev --nodes 3
mongosh "mongodb://127.0.0.1:27017,127.0.0.1:27018,127.0.0.1:27019/"

teseladb dev arranca varios nodos en un solo proceso, con los datos en memoria, así que al pararlo no queda nada en disco. El nodo k escucha en el puerto de clientes más k, y por eso los tres nodos de la orden responden en los puertos del 27017 al 27019 de tu máquina. Cada uno escribe su línea ready en el log. Para pararlo, pulsa Ctrl+C en la terminal donde lo arrancaste. Sus datos se van con él. Este clúster de desarrollo no usa TLS ni usuarios. Por eso la cadena de mongosh no lleva ninguna opción.

Lo interesante es que son tres nodos completos, con el mismo reparto en rangos replicados con Raft que tendrás en producción. Cada rango tiene una réplica en cada nodo, una de ellas es la líder y las escrituras esperan a la mayoría. Si tu aplicación depende de algo que solo pasa con varios nodos, como una lectura de un seguidor o el orden de un find sin sort, lo ves ya en tu portátil.

Mirar lo que pasa dentro

teseladb admin --node 127.0.0.1:<puerto> nodes
teseladb admin --node 127.0.0.1:<puerto> --format json ranges --collection test.pedidos

El log de teseladb dev anota el puerto de administración de cada nodo, que elige el sistema al arrancar. Cualquiera de ellos responde por todo el clúster. La primera orden lista los tres nodos como votantes y dice cuál lidera Group 0. La segunda enseña los rangos de la colección con sus réplicas, en voters, y el nodo que lidera cada uno, en leaderHint. Con la colección test.pedidos recién creada verás un solo rango que la cubre entera, con los tres nodos en voters. Cuando crezca por encima de 64 MiB de datos vivos se dividirá en dos. A partir de ahí, el equilibrador irá moviendo líderes entre los nodos para repartir la carga. Son las mismas órdenes que usarás en producción, donde el puerto de administración es el 27200.

En tres máquinas

En producción, cada nodo es un teseladb start en su máquina, normalmente como servicio de systemd. El primero crea la autoridad de certificación del clúster y el usuario root con una contraseña al azar. Los demás entran con un token de alta de un solo uso, que caduca a la hora. Al entrar, cada uno recibe su certificado firmado por esa CA. El clúster reparte después los rangos y sus líderes entre los tres sin que muevas datos a mano.

Cada nodo usa tres puertos. El 27017 atiende a los drivers y tiene que llegar a tus aplicaciones. Por el 27100 se comunican los nodos entre ellos, así que basta con abrirlo entre las tres máquinas. El 27200 es el de administración y solo lo necesita tu equipo de operación, el que lanza teseladb admin. Separarlos así te deja cerrar en el cortafuegos todo lo que no sea el puerto de clientes hacia fuera.

Hay un detalle que conviene no olvidar. El certificado de cada nodo lleva localhost y los nombres que le das en --bind_ip, así que, si tus aplicaciones conectan a node-01 por su nombre, ese nombre tiene que estar en la opción de arranque. La guía de systemd lo resuelve con --bind_ip 0.0.0.0,%H, que añade el nombre de cada máquina.

En qué se diferencia el clúster de desarrollo

El clúster de teseladb dev se parece mucho al de producción. Tiene cuatro diferencias. Guarda los datos en memoria, así que sirve para pruebas y no para datos que quieras conservar. No usa TLS ni usuarios, y sus puertos de administración cambian en cada arranque. Por último, los tres nodos viven en un mismo proceso. No puedes tirar uno solo para ver cómo responde el clúster a una caída; para eso hacen falta procesos separados, como los contenedores de la guía de Docker Compose.

Lo que cambia en tu aplicación

desarrollo:  mongodb://127.0.0.1:27017,127.0.0.1:27018,127.0.0.1:27019/
producción:  mongodb://tienda-api:<contraseña>@node-01:27017,node-02:27017,node-03:27017/tienda?tls=true&tlsCAFile=./ca.pem&authSource=admin

Solo cambia la cadena de conexión. Pasa a llevar los tres nodos por su nombre, tls=true, la CA del clúster y un usuario con los roles que necesita la aplicación, más authSource=admin, porque los usuarios viven en la base admin. El código conserva sus consultas, sus índices y sus transacciones tal como estaban. Si lees la cadena de una variable de entorno, el paso a producción no toca ni una línea.

Por dónde seguir

Para el camino entero, sigue Inicio rápido con un clúster local y después Tres máquinas con systemd. Si quieres ver cómo se comporta el clúster cuando algo falla, Matar un nodo y verlo volver lo hace sobre tres nodos en Docker. Y si vienes de MongoDB, Diferencias con MongoDB recoge los comportamientos que cambian al pasar de un replica set a rangos.