![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/valkey-cluster-failover-v1.webp\")
<\/p>\n<\/p>\n
Um Valkey sozinho aguenta muita coisa, mas quando cai leva junto o cache, as sess\u00f5es e as filas da aplica\u00e7\u00e3o. O modo cluster resolve os dois problemas de uma vez: divide os dados entre v\u00e1rios prim\u00e1rios e deixa uma r\u00e9plica pronta para assumir cada peda\u00e7o quando um servidor morre. Neste guia montamos um cluster com 3 prim\u00e1rios e 3 r\u00e9plicas, derrubamos um prim\u00e1rio de prop\u00f3sito e medimos quanto tempo as escritas ficaram paradas. Tamb\u00e9m adicionamos e removemos n\u00f3s, ligamos persist\u00eancia, ACL e TLS, configuramos o servi\u00e7o com systemd e ligamos o Valkey Admin no cluster. Tudo foi executado de verdade num laborat\u00f3rio em Docker com o Valkey 9.1.2, e as sa\u00eddas mostradas abaixo sa\u00edram desse teste.<\/p>\n
Em mar\u00e7o de 2024 a Redis Inc. trocou a licen\u00e7a do Redis, que era BSD, por licen\u00e7as source available<\/em>. No dia 28 daquele m\u00eas a Linux Foundation anunciou o Valkey<\/a>, um fork criado por mantenedores e colaboradores antigos do projeto a partir do Redis 7.2.4. O Valkey continua com a licen\u00e7a BSD de 3 cl\u00e1usulas<\/a> e tem governan\u00e7a aberta. AWS, Google Cloud, Oracle, Ericsson e Snap apoiaram o projeto desde o an\u00fancio. O protocolo continua o mesmo, ent\u00e3o clientes e ferramentas feitos para o Redis em geral funcionam sem altera\u00e7\u00e3o.<\/p>\n Vers\u00f5es em 23\/09\/2026, conferidas nas releases do GitHub<\/a> e na p\u00e1gina de download<\/a>:<\/p>\n Novidades das duas \u00faltimas vers\u00f5es maiores que mudam a opera\u00e7\u00e3o de um cluster, segundo os an\u00fancios oficiais do Valkey 9.0<\/a> e do Valkey 9.1<\/a>:<\/p>\n O Valkey Cluster divide o espa\u00e7o de chaves em 16384 hash slots<\/strong>. O slot de uma chave \u00e9 As duas op\u00e7\u00f5es entregam alta disponibilidade, mas resolvem problemas diferentes:<\/p>\n\n
\n
CLUSTER MIGRATESLOTS<\/code>, que usamos mais abaixo.<\/li>\nSELECT 1<\/code> passou a funcionar em cluster. No Redis e nas vers\u00f5es anteriores do Valkey, o cluster s\u00f3 aceitava o db 0.<\/li>\nHEXPIRE<\/code>, HSETEX<\/code> e HGETEX<\/code>.<\/li>\nACL SETUSER app ... db=0,1<\/code> restringe um usu\u00e1rio a alguns bancos.<\/li>\nINFO<\/code> e autentica\u00e7\u00e3o por SAN URI.<\/li>\nlog-format json<\/code> no valkey.conf<\/code>.<\/li>\nHGETDEL<\/code> e MSETEX<\/code>.<\/li>\n<\/ul>\nComo o cluster funciona<\/h2>\n
CRC16(chave) mod 16384<\/code>, e cada prim\u00e1rio \u00e9 dono de uma faixa de slots. Com 3 prim\u00e1rios, a divis\u00e3o padr\u00e3o fica assim: 0\u20135460, 5461\u201310922 e 10923\u201316383. Cada prim\u00e1rio tem uma ou mais r\u00e9plicas<\/strong>, que recebem os dados por replica\u00e7\u00e3o ass\u00edncrona e ficam prontas para assumir.<\/p>\n\n
cluster-node-timeout<\/code>, quem percebe o marca como PFAIL<\/code> (falha prov\u00e1vel). Quando a maioria dos prim\u00e1rios relata o mesmo, ele vira FAIL<\/code> e essa informa\u00e7\u00e3o se espalha pelo cluster.<\/li>\nFAIL<\/code> pede votos aos outros prim\u00e1rios. Com a maioria dos votos, ela se promove, incrementa o config epoch<\/em> e passa a servir os slots do prim\u00e1rio que caiu.<\/li>\nMOVED <slot> <ip:porta><\/code>. Um cliente cluster-aware<\/em> atualiza o mapa de slots e vai direto ao n\u00f3 certo.<\/li>\n{...}<\/code>, s\u00f3 o trecho entre chaves entra no c\u00e1lculo do slot. {pedido:42}:itens<\/code> e {pedido:42}:total<\/code> caem no mesmo slot e podem ser usadas juntas em MSET<\/code>, transa\u00e7\u00f5es e scripts.<\/li>\n<\/ul>\n![\"Topologia](\"\/wp-content\/uploads\/2026\/09\/valkey-cluster-topologia.webp\")
<\/p>\nCluster ou Sentinel?<\/h2>\n
![\"Linha](\"\/wp-content\/uploads\/2026\/09\/valkey-cluster-failover-medido.webp\")
<\/p>\n