One place for hosting & domains

      Replicas

      Como Gerenciar Réplicas e Clientes no Redis


      Introdução

      O Redis é um armazenamento de dados open-source de chave-valor na memória. Um dos seus recursos mais procurados é o suporte à replicação: qualquer servidor Redis pode replicar seus dados para qualquer número de réplicas, permitindo alta escalabilidade de leitura e forte redundância de dados. Além disso, o Redis foi projetado para permitir que muitos clientes (até 10000, por padrão) se conectem e interajam com os dados, tornando-o uma boa opção para casos em que muitos usuários precisam acessar o mesmo dataset ou conjunto de dados.

      Este tutorial aborda os comandos usados para gerenciar clientes e réplicas Redis.

      Como Usar Este Guia

      Este guia foi escrito como uma consulta rápida com exemplos independentes. Recomendamos que você pule para qualquer seção que seja relevante para a tarefa que você está tentando concluir.

      Os comandos mostrados neste guia foram testados em um servidor Ubuntu 18.04 executando a versão do Redis 4.0.9. Para configurar um ambiente semelhante, você pode seguir o Passo 1 do nosso guia Como Instalar e Proteger o Redis no Ubuntu 18.04. Vamos demonstrar como esses comandos se comportam executando-os com redis-cli, a interface de linha de comando do Redis. Observe que se você estiver usando uma interface Redis diferente — Redli, por exemplo — a saída exata de certos comandos pode ser diferente.

      Alternativamente, você pode provisionar uma instância de banco de dados Redis gerenciada para testar esses comandos, mas observe que, dependendo do nível de controle permitido pelo seu provedor de banco de dados, alguns comandos neste guia podem não funcionar como descrito. Para provisionar um banco de dados gerenciado na DigitalOcean, siga nossa documentação do produto Managed Databases. Em seguida, você deve instalar o Redli ou configurar um túnel TLS para conectar-se ao banco de dados gerenciado via TLS.

      Nota: O projeto Redis usa os termos “master” e “slave” em sua documentação e em vários comandos para identificar diferentes funções na replicação, embora os colaboradores do projeto estejam tomando medidas para alterar essa linguagem nos casos onde isso não cause problemas de compatibilidade. A DigitalOcean geralmente prefere usar os termos alternativos “primary” e “replica”.

      Este guia assumirá o padrão “primary” e “replica” sempre que possível, mas observe que existem algumas circunstâncias em que os termos “master” e “slave” inevitavelmente aparecem.

      Gerenciando Réplicas

      Um dos recursos que mais se destaca no Redis é sua replicação embutida. Ao usar a replicação, o Redis cria cópias exatas da instância primária. Essas instâncias secundárias se reconectam à primária sempre que suas conexões quebram e sempre procurarão permanecer como uma cópia exata da primária.

      Se você não tiver certeza se a instância do Redis à qual você está conectado atualmente é uma instância primária ou uma réplica, verifique com o comando role:

      Este comando retornará master ou slave ou, potencialmente, sentinel se você estiver usando Redis Sentinel.

      Para designar uma instância do Redis como uma réplica de outra instância em tempo real, execute o comando replicaof. Este comando usa o nome do host ou o endereço IP do servidor primário pretendido e a porta como argumentos:

      • replicaof hostname_ou_IP porta

      Se o servidor já era uma réplica de outro primário, ele interromperá a replicação do servidor antigo e começará a sincronizar imediatamente com o novo. Ele também descartará o dataset antigo.

      Para promover uma réplica de volta para ser primária, execute o seguinte comando replicaof:

      Isso impedirá a instância de replicar o servidor primário, mas não descartará o dataset que já foi replicado. Essa sintaxe é útil nos casos em que o primário original falha. Depois de executar replicaof no one em uma réplica do primário com falha, a réplica anterior pode ser usada como o novo primário e ter suas próprias réplicas como um mecanismo de proteção a falhas.

      Nota: Antes da versão 5.0.0, o Redis incluía uma versão deste comando chamada slaveof.

      Gerenciando Clientes

      Um cliente é qualquer máquina ou software que se conecta a um servidor para acessar um serviço. O Redis vem com vários comandos que ajudam a rastrear e gerenciar conexões de clientes.

      O comando client list retorna um conjunto de informações legíveis sobre as conexões atuais de cliente:

      Output
      "id=18165 addr=[2001:db8:0:0::12]:47460 fd=7 name=jerry age=72756 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=18166 addr=[2001:db8:0:1::12]:47466 fd=8 name= age=72755 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info
id=19381 addr=[2001:db8:0:2::12]:54910 fd=9 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client
"

      Aqui está o que cada um desses campos significa:

      • id: um ID de cliente exclusivo de 64 bits
      • name: o nome da conexão do cliente, conforme definido por um comando anterior client setname
      • addr: o endereço e a porta a partir da qual o cliente está se conectando
      • fd: o descritor de arquivo que corresponde ao soquete no qual o cliente está se conectando
      • age: a duração total da conexão do cliente, em segundos
      • flags: um conjunto de uma ou mais flags de caractere simples que fornecem detalhes mais granulares sobre os clientes; veja a documentação do comando client list para mais detalhes
      • db: o número atual do ID do banco de dados ao qual o cliente está conectado (pode ser de 0 a 15)
      • sub😮 número de canais aos quais o cliente está inscrito
      • psub: o número de subscrições correspondentes ao padrão do cliente
      • mutli: o número de comandos que o cliente enfileirou em uma transação (mostrará -1 se o cliente não iniciou uma transação ou 0 se apenas iniciou uma transação e não colocou nenhum comando na fila)
      • qbuf😮 tamanho do buffer de consulta do cliente, com “0” significando que não há consultas pendentes
      • qbuf-free: a quantidade de espaço livre no buffer de consulta do cliente, com “0” significando que o buffer de consulta está cheio
      • obl: o comprimento do buffer de saída do cliente
      • oll: o comprimento da lista de saída do cliente, onde as respostas são colocadas na fila quando o buffer está cheio
      • omem: a memória usada pelo buffer de saída do cliente
      • events: eventos do descritor de arquivo do cliente, eles podem ser r para “legível”, w para “gravável” ou ambos
      • cmd: o último comando executado pelo cliente

      Definir nomes de clientes é útil para debugar vazamentos de conexão em qualquer aplicativo que esteja usando o Redis. Toda nova conexão é iniciada sem um nome atribuído, mas client setname pode ser usado para criar um para a conexão atual do cliente. Não há limite para o tamanho dos nomes dos clientes, embora o Redis normalmente limite os comprimentos de string de caracteres para 512 MB. Observe, porém, que os nomes dos clientes não podem incluir espaços:

      Para obter o nome de uma conexão de cliente, use o comando client getname:

      Output
      "elaine"

      Para buscar o ID de conexão de um cliente, use o comando client id:

      Output
      (integer) "19492"

      Os IDs de clientes Redis nunca são repetidos e são monotonicamente incrementais. Isso significa que, se um cliente tiver um ID maior que outro, então ele foi estabelecido posteriormente.

      Bloqueando Clientes e Fechando Conexões de Cliente

      Os sistemas de replicação são normalmente descritos como sendo síncronos ou assíncronos. Na replicação síncrona, sempre que um cliente adiciona ou altera dados, ele deve receber algum tipo de reconhecimento de um certo número de réplicas para que a alteração seja registrada como confirmada. Isso ajuda a impedir que os nodes tenham conflitos de dados, mas tem um custo de latência, já que o cliente deve esperar para executar outra operação até receber uma resposta de um certo número de réplicas.

      Na replicação assíncrona, por outro lado, o cliente vê uma confirmação de que a operação é concluída assim que os dados são gravados no armazenamento local. No entanto, pode haver um atraso entre isso e quando as réplicas realmente gravam os dados. Se uma das réplicas falhar antes de poder gravar a alteração, essa gravação será perdida para sempre. Portanto, embora a replicação assíncrona permita que os clientes continuem executando operações sem a latência causada pela espera das réplicas, isso pode levar a conflitos de dados entre nodes e pode exigir trabalho extra por parte do administrador do banco de dados para resolver esses conflitos.

      Devido ao seu foco no desempenho e na baixa latência, o Redis implementa a replicação assíncrona por padrão. No entanto, você pode simular a replicação síncrona com o comando wait. O wait bloqueia a conexão do cliente atual por um período de tempo especificado (em milissegundos) até que todos os comandos de gravação anteriores sejam transferidos e aceitos com sucesso por um número especificado de réplicas. Este comando usa a seguinte sintaxe:

      • wait número_de_réplicas número_de_milisegundos

      Por exemplo, se você deseja bloquear a sua conexão de cliente até que todas as gravações anteriores sejam registradas por pelo menos três réplicas dentro de um tempo limite de 30 milissegundos, sua sintaxe wait se parecerá com esta:

      O comando wait retorna um número inteiro que representa o número de réplicas que reconheceram os comandos de gravação, mesmo que nem todas as réplicas o façam:

      Output
      2

      Para desbloquear uma conexão de cliente que foi bloqueada anteriormente, seja de um comando wait, brpop ou xread, você pode executar um comando client unblock com a seguinte sintaxe:

      Para suspender temporariamente todos os clientes atualmente conectados ao servidor Redis, você pode usar o comando client pause. Isso é útil nos casos em que você precisa fazer alterações na configuração do Redis de maneira controlada. Por exemplo, se você estiver promovendo uma de suas réplicas como a instância primária, poderá pausar todos os clientes com antecedência para promover a réplica e fazer com que os clientes se conectem a ela como o novo primário sem perder nenhuma operação de gravação no processo.

      O comando client pause exige que você especifique a quantidade de tempo (em milissegundos) que deseja suspender os clientes. O exemplo a seguir suspenderá todos os clientes por um segundo:

      A sintaxe do client kill permite que você feche uma única conexão ou um conjunto de conexões específicas com base em vários filtros diferentes. A sintaxe é assim:

      • client kill filtro_1 valor_1 ... filtro_n valor_n

      Nas versões do Redis 2.8.12 e posteriores, os seguintes filtros estão disponíveis:

      • addr: permite fechar uma conexão de cliente a partir de um endereço IP e porta especificados
      • client-id: permite fechar uma conexão de cliente com base em seu campo de ID exclusivo
      • type: fecha todo cliente de um determinado tipo, que pode ser normal, master, slave ou pubsub
      • skipme: as opções de valor para este filtro são yes e no:
        • se no for especificado, o cliente que chama o comando client kill não será ignorado e será eliminado se os outros filtros se aplicarem a ele
        • se yes for especificado, o cliente executando o comando será ignorado e o comando kill não terá efeito no cliente. skipme é sempreyes por padrão

      Conclusão

      Este guia detalha vários comandos usados para gerenciar clientes e réplicas Redis. Se houver outros comandos, argumentos ou procedimentos relacionados que você gostaria de ver descritos neste guia, peça ou faça sugestões nos comentários abaixo.

      Para obter mais informações sobre comandos Redis, consulte nossa série de tutoriais sobre Como gerenciar um banco de dados Redis.



      Source link

      How To Manage Replicas and Clients in Redis


      Introduction

      Redis is an open-source, in-memory key-value data store. One of its most sought-after features is its support for replication: any Redis server can replicate its data to any number of replicas, allowing for high read scalability and strong data redundancy. Additionally, Redis was designed to allow many clients (up to 10000, by default) to connect and interact with data, making it a good choice for cases where many users need access to the same dataset.

      This tutorial goes over the commands used to manage Redis clients and replicas.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To set up a similar environment, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Alternatively, you could provision a managed Redis database instance to test these commands, but note that depending on the level of control allowed by your database provider, some commands in this guide may not work as described. To provision a DigitalOcean Managed Database, follow our Managed Databases product documentation. Then, you must either install Redli or set up a TLS tunnel in order to connect to the Managed Database over TLS.

      Note: The Redis project uses the terms “master” and “slave” in its documentation and in various commands to identify different roles in replication, though the project’s contributors are taking steps to change this language in cases where it doesn’t cause compatibility issues. DigitalOcean generally prefers to use the alternative terms “primary” and “replica”.

      This guide will default to “primary” and “replica” whenever possible, but note that there are a few instances where the terms “master” and “slave” unavoidably come up.

      Managing Replicas

      One of Redis’s most distinguishing features is its built-in replication. When using replication, Redis creates exact copies of the primary instance. These secondary instances reconnect to the primary any time their connections break and will always aim to remain an exact copy of the primary.

      If you’re not sure whether the Redis instance you’re currently connected to is a primary instance or a replica, you can check by running the role command:

      This command will return either master or slave, or potentially sentinel if you’re using Redis Sentinel.

      To designate a Redis instance as a replica of another instance on the fly, run the replicaof command. This command takes the intended primary server’s hostname or IP address and port as arguments:

      • replicaof hostname_or_IP port

      If the server was already a replica of another primary, it will stop replicating the old server and immediately start synchronizing with the new one. It will also discard the old dataset.

      To promote a replica back to being a primary, run the following replicaof command:

      This will stop the instance from replicating the primary server, but will not discard the dataset it has already replicated. This syntax is useful in cases where the original primary fails. After running replicaof no one on a replica of the failed primary, the former replica can be used as the new primary and have its own replicas as a failsafe.

      Note: Prior to version 5.0.0, Redis instead included a version of this command named slaveof.

      Managing Clients

      A client is any machine or software that connects to a server in order to access a service. Redis comes with several commands that help with tracking and managing client connections.

      The client list command returns a set of human-readable information about current client connections:

      Output
      "id=18165 addr=[2001:db8:0:0::12]:47460 fd=7 name=jerry age=72756 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=18166 addr=[2001:db8:0:1::12]:47466 fd=8 name= age=72755 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info
id=19381 addr=[2001:db8:0:2::12]:54910 fd=9 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client
"

      Here is what each of these fields mean:

      • id: a unique 64-bit client ID
      • name: the name of the client connection, as defined by a prior client setname command
      • addr: the address and port from which the client is connecting
      • fd: the file descriptor that corresponds to the socket over which the client is connecting
      • age: the total duration of the client connection, in seconds
      • flags: a set of one or more single-character flags that provide more granular detail about the clients; see the client list command documentation for more details
      • db: the current database ID number that the client is connected to (can be from 0 to 15)
      • sub: the number of channels the client is subscribed to
      • psub: the number of the client’s pattern-matching subscriptions
      • mutli: the number of commands the client has queued in a transaction (will show -1 if the client hasn’t begun a transaction or 0 if it has only started a transaction and not queued any commands)
      • qbuf: the client’s query buffer length, with 0 meaning it has no pending queries
      • qbuf-free: the amount of free space in the client’s query buffer, with 0 meaning that the query buffer is full
      • obl: the client’s output buffer length
      • oll: the length of the client’s output list, where replies are queued when its buffer is full
      • omem: the memory used by the client’s output buffer
      • events: the client’s file descriptor events, these can be r for “readable”, w for “writable,” or both
      • cmd: the last command run by the client

      Setting client names is useful for debugging connection leaks in whatever application is using Redis. Every new connection starts without an assigned name, but client setname can be used to create one for the current client connection. There’s no limit to how long client names can be, although Redis usually limits string lengths to 512 MB. Note, though, that client names cannot include spaces:

      To retrieve the name of a client connection, use the client getname command:

      Output
      "elaine"

      To retrieve a client’s connection ID, use the client id command:

      Output
      (integer) "19492"

      Redis client IDs are never repeated and are monotonically incremental. This means that if one client has an ID greater than another, then it was established at a later time.

      Blocking Clients and Closing Client Connections

      Replication systems are typically described as being either synchronous or asynchronous. In synchronous replication, whenever a client adds or changes data it must receive some kind of acknowledgement from a certain number of replicas for the change to register as having been committed. This helps to prevent nodes from having data conflicts but it comes at a cost of latency, since the client must wait to perform another operation until it has heard back from a certain number of replicas.

      In asynchronous replication, on the other hand, the client sees a confirmation that the operation is finished as soon as the data is written to local storage. There can, however, be a lag between this and when the replicas actually write the data. If one of the replicas fails before it can write the change, that write will be lost forever. So while asynchronous replication allows clients to continue performing operations without the latency caused by waiting for replicas, it can lead to data conflicts between nodes and may require extra work on the part of the database administrator to resolve those conflicts.

      Because of its focus on performance and low latency, Redis implements asynchronous replication by default. However, you can simulate synchronous replication with the wait command. wait blocks the current client connection for a specified amount of time (in milliseconds) until all the previous write commands are successfully transferred and accepted by a specified number of replicas. This command uses the following syntax:

      • wait number_of_replicas number_of_milliseconds

      For example, if you want to block your client connection until all the previous writes are registered by at least 3 replicas within a 30 millisecond timeout, your wait syntax would look like this:

      The wait command returns an integer representing the number of replicas that acknowledged the write commands, even if not every replica does so:

      Output
      2

      To unblock a client connection that has been previously blocked, whether from a wait, brpop, or xread command, you can run a client unblock command with the following syntax:

      To temporarily suspend every client currently connected to the Redis server, you can use the client pause command. This is useful in cases where you need to make changes to your Redis setup in a controlled way. For example, if you’re promoting one of your replicas to be the primary instance, you might pause every client beforehand so you can promote the replica and have the clients connect to it as the new primary without losing any write operations in the process.

      The client pause command requires you to specify the amount of time (in milliseconds) you’d like to suspend the clients. The following example will suspend all clients for one second:

      The client kill syntax allows you to close a single connection or a set of specific connections based on a number of different filters. The syntax looks like this:

      • client kill filter_1 value_1 ... filter_n value_n

      In Redis versions 2.8.12 and later, the following filters are available:

      • addr: allows you to close a client connection from a specified IP address and port
      • client-id: allows you to close a client connection based on its unique ID field
      • type: closes every client of a given type, which can be either normal, master, slave, or pubsub
      • skipme: the value options for this filter are yes and no:
        • if no is specified, the client calling the client kill command will not get skipped, and will be killed if the other filters apply to it
        • if yes is specified, the client running the command will be skipped and the kill command will have no effect on the client. skipme is always yes by default

      Conclusion

      This guide details a number of commands used to manage Redis clients and replicas. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link

      Forgot Your Password ?