One place for hosting & domains

      Banco

      Como gerenciar e utilizar acionadores de banco de dados do MySQL no Ubuntu 18.04


      O autor selecionou a Apache Software Foundation para receber uma doação como parte do programa Write for DOnations.

      Introdução

      No MySQL, um acionador é um comando SQL definido por usuário que é chamado automaticamente durante uma operação INSERT, DELETE, ou UPDATE. O código de acionador está associado a uma tabela e é destruído assim que uma tabela for descartada. Você pode especificar um momento de ação do acionador e definir se ele será ativado antes ou após o evento de banco de dados definido.

      Os acionadores possuem várias vantagens. Por exemplo, você pode usá-los para gerar o valor de uma coluna derivada durante uma instrução de INSERT. Outro caso de uso é a aplicação da integridade referencial, onde é possível utilizar um acionador para salvar um registro em várias tabelas relacionadas. Outros benefícios dos acionadores incluem o registro de ações do usuário para auditar tabelas, bem como cópias de dados em tempo real em diferentes esquemas de bancos de dados para fins de redundância, com o objetivo de evitar um único ponto de falha.

      Você também pode utilizar acionadores para manter as regras de validação no nível do banco de dados. Isso ajuda no compartilhamento da fonte de dados em vários aplicativos, sem quebrar a lógica de negócios. Isso também reduz bastante os testes de viagem de ida e volta para o servidor de banco de dados, o que, portanto, melhora o tempo de resposta dos seus aplicativos. Como o servidor de banco de dados executa os acionadores, eles podem aproveitar-se de recursos de servidor melhorados, como RAM e CPU.

      Neste tutorial, você criará, utilizará e excluirá vários tipos de acionadores no seu banco de dados do MySQL.

      Pré-requisitos

      Antes de começar, certifique-se de ter o seguinte:

      Passo 1 — Criando um banco de dados de amostra

      Neste passo, você criará um banco de dados de clientes de amostra com várias tabelas para demonstrar como os acionadores do MySQL funcionam.

      Para entender melhor sobre as consultas do MySQL, leia nossa Introdução às consultas no MySQL.

      Primeiro, faça login no seu servidor do MySQL como raiz:

      Digite sua senha raiz do MySQL quando solicitado e clique em ENTER para continuar. Quando você vir o prompt do mysql>, execute o seguinte comando para criar um banco de dados test_db:

      Output

      Query OK, 1 row affected (0.00 sec)

      Em seguida, mude para o test_db com:

      Output

      Database changed

      Você começará criando uma tabela de customers. Essa tabela terá os registros dos clientes, incluindo a customer_id, o customer_name e o level. Haverá dois níveis de clientes: BASIC e VIP.

      • Create table customers(customer_id BIGINT PRIMARY KEY, customer_name VARCHAR(50), level VARCHAR(50) ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.01 sec)

      Agora, adicione alguns registros à tabela customers. Para fazer isso, execute os comandos um a um:

      • Insert into customers (customer_id, customer_name, level )values('1','JOHN DOE','BASIC');
      • Insert into customers (customer_id, customer_name, level )values('2','MARY ROE','BASIC');
      • Insert into customers (customer_id, customer_name, level )values('3','JOHN DOE','VIP');

      Você verá o seguinte resultado após executar cada um dos comandos INSERT:

      Output

      Query OK, 1 row affected (0.01 sec)

      Para garantir que os registros de amostra foram inseridos com sucesso, execute o comando SELECT:

      Output

      +-------------+---------------+-------+ | customer_id | customer_name | level | +-------------+---------------+-------+ | 1 | JOHN DOE | BASIC | | 2 | MARY ROE | BASIC | | 3 | JOHN DOE | VIP | +-------------+---------------+-------+ 3 rows in set (0.00 sec)

      Você criará também outra tabela para reter informações relacionadas sobre a conta customers. A tabela terá os campos customer_id e status_notes.

      Execute o seguinte comando:

      • Create table customer_status(customer_id BIGINT PRIMARY KEY, status_notes VARCHAR(50)) ENGINE=INNODB;

      Em seguida, você criará uma tabela de sales (vendas). Esta tabela terá os dados de vendas relacionados a diferentes clientes através da coluna customer_id:

      • Create table sales(sales_id BIGINT PRIMARY KEY, customer_id BIGINT, sales_amount DOUBLE ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.01 sec)

      Você adicionará os dados da amostra aos dados de sales nos passos próximos, enquanto testa os acionadores. Em seguida, crie uma tabela audit_log para registrar as atualizações feitas para a tabela de sales quando você implementar o acionador AFTER UPDATE no Passo 5:

      • Create table audit_log(log_id BIGINT PRIMARY KEY AUTO_INCREMENT, sales_id BIGINT, previous_amount DOUBLE, new_amount DOUBLE, updated_by VARCHAR(50), updated_on DATETIME ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.02 sec)

      Com o banco de dados test_db e as quatro tabelas em funcionamento, siga em frente para trabalhar com os vários acionadores do MySQL no seu banco de dados.

      Passo 2 — Criando um acionador antes de inserir

      Neste passo, você examinará a sintaxe de um acionador do MySQL, antes da aplicação dessa lógica para criar um acionador BEFORE INSERT, que valida o campo sales_amount quando os dados são inseridos na tabela de sales.

      A sintaxe geral para a criação de um acionador do MySQL é mostrada no exemplo a seguir:

      DELIMITER //
      CREATE TRIGGER [TRIGGER_NAME]
      [TRIGGER TIME] [TRIGGER EVENT]
      ON [TABLE]
      FOR EACH ROW
      [TRIGGER BODY]//
      DELIMITER ;
      

      A estrutura do acionador inclui:

      DELIMITER //: o delimitador padrão do MySQL é o ; — ele é necessário para modificá-lo para outra coisa, de modo a permitir que o MySQL trate as linhas seguintes como um comando até que ele atinja seu delimitador personalizado. Neste exemplo, o delimitador é alterado para // e, em seguida, o delimitador ; é redefinido no final.

      [TRIGGER_NAME]: um acionador deve ter um nome e é aqui que você inclui o valor.

      [TRIGGER TIME]: um acionador pode ser chamado durante diferentes intervalos de tempo. O MySQL permite que você defina se o acionador iniciará antes ou após uma operação de banco de dados.

      [TRIGGER EVENT]: os acionadores são chamados apenas por operações de INSERT, UPDATE e DELETE. Você pode utilizar qualquer valor aqui, dependendo do que quiser fazer.

      [TABLE]: qualquer acionador que você criar no seu banco de dados do MySQL deve estar associado a uma tabela.

      FOR EACH ROW: essa instrução diz ao MySQL para executar o código do acionador para cada linha que o acionador afeta.

      [TRIGGER BODY]​​​: o código que é executado quando o acionador é chamado tem o nome de trigger body. Pode ser uma única instrução do SQL ou vários comandos. Note que, se estiver executando várias instruções do SQL no corpo do acionador, você deve envolvê-las entre um bloco BEGIN... END.

      Nota: ao criar o corpo do acionador, você pode utilizar as palavras-chave OLD e NEW para acessar os valores de coluna antigos e novos inseridos durante uma operação INSERT, UPDATE e DELETE. Em um acionador de DELETE, apenas a palavra-chave OLD pode ser usada (que você usará no Passo 4).

      Agora, você criará seu primeiro acionador BEFORE INSERT. Este acionador estará associado à tabela de sales e será chamado antes de um registro ser inserido para validar o sales_amount. A função do acionador é a de verificar se o sales_amount que está sendo inserido no quadro de vendas é maior do que 10000 e de gerar um erro, caso isso seja verdadeiro.

      Certifique-se de estar logado no servidor do MySQL. Em seguida, digite os comandos do MySQL seguintes um de cada vez:

      • DELIMITER //
      • CREATE TRIGGER validate_sales_amount
      • BEFORE INSERT
      • ON sales
      • FOR EACH ROW
      • IF NEW.sales_amount>10000 THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'Sale has exceeded the allowed amount of 10000.';
      • END IF//
      • DELIMITER ;

      Você está usando a instrução IF... THEN... END IF para avaliar se a quantidade que está sendo fornecida durante a instrução INSERT está dentro da sua faixa. O acionador consegue extrair o novo valor de sales_amount que está sendo fornecido, usando a palavra-chave NEW.

      Para gerar uma mensagem de erro genérica, use as linhas seguintes para informar o usuário sobre o erro:

      SIGNAL SQLSTATE '45000'
      SET MESSAGE_TEXT = 'Sale has exceeded the allowed amount of 10000.';
      

      Em seguida, insira um registro com um sales_amount de 11000 para a tabela de sales para verificar se o acionador interromperá a operação:

      • Insert into sales(sales_id, customer_id, sales_amount) values('1','1','11000');

      Output

      ERROR 1644 (45000): Sale has exceeded the allowed amount of 10000.

      Este erro mostra que o código do acionador está funcionando como esperado.

      Agora, teste um novo registro com um valor de 7500 para verificar se o comando será bem-sucedido:

      • Insert into sales(sales_id, customer_id, sales_amount) values('1','1','7500');

      Como o valor está dentro da faixa recomendada, você verá o seguinte resultado:

      Output

      Query OK, 1 row affected (0.01 sec)

      Para confirmar que os dados foram inseridos, execute o seguinte comando:

      O resultado confirma que os dados estão na tabela:

      Output

      +----------+-------------+--------------+ | sales_id | customer_id | sales_amount | +----------+-------------+--------------+ | 1 | 1 | 7500 | +----------+-------------+--------------+ 1 row in set (0.00 sec)

      Neste passo, você testou os acionadores para validar dados antes da inserção deles em um banco de dados.

      Em seguida, você trabalhará com o acionador AFTER INSERT para salvar informações relacionadas em tabelas diferentes.

      Passo 3 — Criando um acionador após inserir

      Os acionadores AFTER INSERT são executados quando os registros são inseridos com sucesso em uma tabela. Essa funcionalidade pode ser usada para executar outras lógicas relacionados a negócios de maneira automática. Por exemplo, em um aplicativo bancário, um acionador AFTER INSERT pode fechar uma conta de empréstimo quando um cliente terminar de pagar o empréstimo. O acionador pode monitorar todos os pagamentos inseridos em uma tabela de transação e fechar o empréstimo automaticamente assim que o saldo do empréstimo se tornar zero.

      Neste passo, você trabalhará com sua tabela de customer_status usando um acionador AFTER INSERT para digitar registros de clientes relacionados.

      Para criar o acionador AFTER INSERT, digite os comandos a seguir:

      • DELIMITER //
      • CREATE TRIGGER customer_status_records
      • AFTER INSERT
      • ON customers
      • FOR EACH ROW
      • Insert into customer_status(customer_id, status_notes) VALUES(NEW.customer_id, 'ACCOUNT OPENED SUCCESSFULLY')//
      • DELIMITER ;

      Output

      Query OK, 0 rows affected (0.00 sec)

      Aqui, você instruirá o MySQL para salvar outro registro para a tabela customer_status assim que um novo registro de cliente for inserido na tabela customers.

      Agora, insira um novo registro na tabela customers para confirmar que seu código do acionador será chamado:

      • Insert into customers (customer_id, customer_name, level )values('4','DAVID DOE','VIP');

      Output

      Query OK, 1 row affected (0.01 sec)

      Como o registro foi inserido com sucesso, verifique se um novo registro de status foi inserido na tabela customer_status:

      • Select * from customer_status;

      Output

      +-------------+-----------------------------+ | customer_id | status_notes | +-------------+-----------------------------+ | 4 | ACCOUNT OPENED SUCCESSFULLY | +-------------+-----------------------------+ 1 row in set (0.00 sec)

      O resultado confirma que o acionador foi executado com sucesso.

      O acionador AFTER INSERT é útil no monitoramento do ciclo de vida de um cliente. Em um ambiente de produção, as contas dos clientes podem ser submetidas a diferentes etapas, como a abertura da conta, a suspensão da conta e o fechamento da conta.

      Nos passos a seguir, você trabalhará com os acionadores de UPDATE.

      Passo 4 — Criando um acionador antes de atualizar

      Um acionador BEFORE UPDATE é semelhante ao acionador BEFORE INSERT—a diferença é o momento onde eles são chamados. Você pode utilizar o acionador BEFORE UPDATE para verificar uma lógica de negócios antes de um registro ser atualizado. Para testar isso, você utilizará a tabela customers, na qual você já inseriu alguns dados.

      Você tem dois níveis para seus clientes no banco de dados. Neste exemplo, assim que uma conta de cliente for atualizada para o nível VIP, a conta não poderá ser rebaixada para o nível BASIC. Para aplicar essa regra, você criará um acionador BEFORE UPDATE que executará antes da instrução UPDATE, como mostrado a seguir. Se um usuário de banco de dados tentar rebaixar um cliente do nível VIP para o nível BASIC, será acionada uma exceção definida pelo usuário.

      Digite os comandos SQL seguintes um de cada vez para criar o acionador BEFORE UPDATE:

      • DELIMITER //
      • CREATE TRIGGER validate_customer_level
      • BEFORE UPDATE
      • ON customers
      • FOR EACH ROW
      • IF OLD.level='VIP' THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'A VIP customer can not be downgraded.';
      • END IF //
      • DELIMITER ;

      Use a palavra-chave OLD para capturar o nível que o usuário está fornecendo ao executar o comando UPDATE. Novamente, use a instrução IF... THEN… END IF para sinalizar uma instrução de erro genérica para o usuário.

      Em seguida, execute o comando SQL a seguir, que tenta rebaixar uma conta de cliente associada ao customer_id de 3:

      • Update customers set level='BASIC' where customer_id='3';

      Você verá o seguinte resultado, fornecendo o SET MESSAGE_TEXT:

      Output

      ERROR 1644 (45000): A VIP customer can not be downgraded.

      Se executar o mesmo comando para um cliente de nível BASIC e tentar atualizar a conta para o nível VIP, o comando será executado com sucesso:

      • Update customers set level='VIP' where customer_id='1';

      Output

      Rows matched: 1 Changed: 1 Warnings: 0

      Você usou o acionador BEFORE UPDATE para aplicar uma regra de negócios. Agora, siga em frente para usar um acionador AFTER UPDATE para log de auditoria.

      Passo 5 — Criando um acionador após atualizar

      Um acionador AFTER UPDATE é chamado assim que um registro de banco de dados for atualizado com sucesso. Este comportamento torna o acionador adequado para o log de auditoria. Em um ambiente de muitos usuários, o administrador pode querer exibir um histórico de usuários atualizando os registros em uma tabela específica para fins de auditoria.

      Você criará um acionador que registra a atividade de atualização da tabela sales. Nossa tabela audit_log terá as informações sobre os usuários do MySQL atualizando a tabela de sales, a date da atualização e os valores old e new da sales_amount.

      Para criar o acionador, execute os comandos SQL seguintes:

      • DELIMITER //
      • CREATE TRIGGER log_sales_updates
      • AFTER UPDATE
      • ON sales
      • FOR EACH ROW
      • Insert into audit_log(sales_id, previous_amount, new_amount, updated_by, updated_on) VALUES (NEW.sales_id,OLD.sales_amount, NEW.sales_amount,(SELECT USER()), NOW() )//
      • DELIMITER ;

      Insira um novo registro para a tabela audit_log. Use a palavra-chave NEW para recuperar o valor do sales_id e o novo sales_amount. Além disso, use a palavra-chave OLD para recuperar o sales_amount anterior, já que deseja registrar ambos os montantes para fins de auditoria.

      O comando SELECT USER() recupera o usuário atual que executa a operação e a instrução NOW() recupera o valor da data e hora atual do servidor MySQL.

      Agora, caso um usuário tente atualizar o valor de qualquer registro na tabela sales, o acionador log_sales_updates inserirá um novo registro para a tabela audit_log.

      Vamos criar um novo registro de vendas com uma sales_id aleatória de 5 e tentar atualizá-lo. Primeiro, insira o registro de vendas com:

      • Insert into sales(sales_id, customer_id, sales_amount) values('5', '2','8000');

      Output

      Query OK, 1 row affected (0.00 sec)

      Em seguida, atualize o registro:

      • Update sales set sales_amount='9000' where sales_id='5';

      Você verá o seguinte resultado:

      Output

      Rows matched: 1 Changed: 1 Warnings: 0

      Agora, execute o comando a seguir para verificar se o acionador AFTER UPDATE conseguiu registrar um novo registro na tabela audit_log:

      O acionador registrou a atualização Seu resultado mostra o sales_amount e o new amount previamente registrados com o usuário que atualizou os registros:

      Output

      +--------+----------+-----------------+------------+----------------+---------------------+ | log_id | sales_id | previous_amount | new_amount | updated_by | updated_on | +--------+----------+-----------------+------------+----------------+---------------------+ | 1 | 5 | 8000 | 9000 | root@localhost | 2019-11-07 09:28:36 | +--------+----------+-----------------+------------+----------------+---------------------+ 1 row in set (0.00 sec)

      Você também tem a data e hora que a atualização foi realizada, que são valiosos para fins de auditoria.

      Em seguida, você usará o acionador DELETE para aplicar a integridade da referenciação no nível de banco de dados.

      Passo 6 — Criando um acionador antes de excluir

      Acionadores do BEFORE DELETE são chamados antes que uma instrução DELETE seja executada em uma tabela. Normalmente, esses tipos de acionadores são usados para aplicar a integridade referencial em diferentes tabelas relacionadas. Por exemplo, cada registro da tabela de sales se relaciona a um customer_id da tabela customers. Se um usuário excluísse um registro da tabela customers que tem um registro relacionado na tabela sales, você não teria como saber qual era o cliente associado àquele registro.

      Para evitar isso, é possível criar um acionador BEFORE DELETE para aplicar sua lógica. Execute os comandos SQL a seguir, um de cada vez:

      • DELIMITER //
      • CREATE TRIGGER validate_related_records
      • BEFORE DELETE
      • ON customers
      • FOR EACH ROW
      • IF OLD.customer_id in (select customer_id from sales) THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'The customer has a related sales record.';
      • END IF//
      • DELIMITER ;

      Agora, tente excluir um cliente que tenha um registro de vendas relacionado a ele:

      • Delete from customers where customer_id='2';

      Como resultado, você verá a seguinte saída:

      Output

      ERROR 1644 (45000): The customer has a related sales record.

      O acionador BEFORE DELETE pode evitar a exclusão acidental de informações relacionadas em um banco de dados.

      No entanto, em algumas situações, você pode querer excluir todos os registros associados a um registro em específico de diferentes tabelas relacionadas. Nesta situação, você usaria o acionador AFTER DELETE, que será testado no próximo passo.

      Passo 7 — Criando um acionador após excluir

      Os acionadores AFTER DELETE são ativados assim que um registro tenha sido excluído com sucesso. Um exemplo de como se pode utilizar um acionador AFTER DELETE é uma situação em que o nível de desconto que um determinado cliente recebe é determinado pelo número de vendas realizadas durante um período definido. Se alguns dos registros do cliente forem excluídos da tabela de sales, o nível de desconto de cliente terá que ser rebaixado.

      Outro uso do acionador AFTER DELETE é o de excluir as informações relacionadas de outra tabela assim que um registro de uma tabela base for excluído. Por exemplo, você definirá um acionador que exclui o registro de clientes se os registros de vendas com o customer_id relacionado forem excluídos da tabela de sales. Execute o comando a seguir para criar seu acionador:

      • DELIMITER //
      • CREATE TRIGGER delete_related_info
      • AFTER DELETE
      • ON sales
      • FOR EACH ROW
      • Delete from customers where customer_id=OLD.customer_id;//
      • DELIMITER ;

      Em seguida, execute o seguinte comando para excluir todos os registros de vendas associados a um customer_id de 2:

      • Delete from sales where customer_id='2';

      Output

      Query OK, 1 row affected (0.00 sec)

      Agora, verifique se há registros para o cliente na tabela de sales:

      • Select * from customers where customer_id='2';

      Você receberá um resultado em um Empty Set, já que o registro de cliente associado ao customer_id de 2 foi excluído pelo acionador:

      Output

      Empty set (0.00 sec)

      Agora, você usou cada uma das diferentes formas de acionadores para realizar funções específicas. Em seguida, você verá como remover um acionador do banco de dados caso não precise mais dele.

      Passo 8 — Excluindo acionadores

      De maneira similar a qualquer outro objeto, você pode excluir acionadores utilizando o comando DROP. A seguir temos a sintaxe para excluir um acionador:

      Drop trigger [TRIGGER NAME];
      

      Por exemplo, para excluir o último acionador AFTER DELETE que você criou, execute o comando a seguir:

      • Drop trigger delete_related_info;

      Output

      Query OK, 0 rows affected (0.00 sec)

      A necessidade de excluir acionadores surge quando você quiser recriar a estrutura deles. Em tal caso, você pode remover o acionador e redefinir um novo com os diferentes comandos de acionador.

      Conclusão

      Neste tutorial, você criou, utilizou e excluiu diferentes tipos de acionadores de um banco de dados do MySQL. Utilizando um exemplo de banco de dados relacionados a clientes, você implementou acionadores para diferentes casos de uso, como validação de dados, aplicação de lógica de negócios, log de auditoria e aplicação da integridade referencial.

      Para obter mais informações sobre como utilizar seu banco de dados do MySQL, confira o seguinte:



      Source link

      Como Migrar Dados do Redis para um Banco de Dados Gerenciado na DigitalOcean


      Introdução

      Existem vários métodos que você pode usar para migrar dados de uma instância Redis para outra, tais como a replicação ou o snapshotting. No entanto, as migrações podem ficar mais complicadas quando você está movendo dados para uma instância Redis gerenciada por um provedor de nuvem, uma vez que os bancos de dados gerenciados muitas vezes limitam o controle que você tem sobre a configuração dos mesmos.

      Este tutorial descreve um método que você pode usar para migrar dados para uma instância do Redis gerenciada pela DigitalOcean. O método usa o comando interno migrate do Redis para transmitir dados com segurança por um túnel TLS configurado com o stunnel. Este guia também abordará algumas outras estratégias de migração comumente usadas, e por que elas são problemáticas ao migrar para um Banco de dados gerenciado na DigitalOcean.

      Pré-requisitos

      Para concluir este tutorial, você precisará de:

      Nota: Para ajudar a manter as coisas claras, este guia fará referência à instância Redis hospedada no seu servidor Ubuntu como a “origem”. Da mesma forma, ele se referirá à instância gerenciada pela DigitalOcean como o “destino” ou o “Banco de Dados Gerenciado”.

      Coisas a Considerar ao Migrar Dados do Redis para um Banco de Dados Gerenciado

      Existem vários métodos que você pode empregar para migrar dados de uma instância Redis para outra. No entanto, algumas dessas abordagens apresentam problemas ao migrar dados para uma instância Redis gerenciada pela DigitalOcean.

      Por exemplo, você pode usar a replicação para transformar sua instância Redis de destino em uma cópia exata da origem. Para fazer isso, você se conectaria ao servidor Redis de destino e executaria o comando replicaof com a seguinte sintaxe:

      • replicaof ip_ou_hostname_da_origem porta_da_origem

      Isso fará com que a instância de destino replique todos os dados mantidos na origem sem destruir nenhum dado que estava armazenado anteriormente nela. Depois disso, você promoveria a réplica de volta a ser uma instância primária com o seguinte comando:

      No entanto, as instâncias Redis gerenciadas pela DigitalOcean são configuradas para se tornarem somente réplicas de leitura. Se você tiver clientes gravando dados no banco de dados de origem, você não poderá configurá-los para gravar na instância gerenciada, pois ela está replicando dados. Isso significa que você perderia todos os dados enviados pelos clientes após promover a instância gerenciada como uma réplica e antes de configurá-los para começar a gravar dados nela, tornando a replicação uma solução de migração ineficiente.

      Outro método para migrar dados do Redis é tirar um snapshot ou instantâneo dos dados mantidos em sua instância de origem com um dos comandos save ou bgsave do Redis. Ambos os comandos exportam o snapshot para um arquivo que termina em .rdb, que você então transfere para o servidor de destino. Depois disso, você reiniciaria o serviço Redis para que ele possa carregar os dados.

      No entanto, muitos provedores de bancos de dados gerenciados — incluindo a DigitalOcean — não permitem acessar o sistema de arquivos subjacente do servidor de banco de dados gerenciado. Isso significa que não há como fazer upload do arquivo de snapshot ou fazer as alterações necessárias no arquivo de configuração do banco de dados de destino para permitir que os Redis importe os dados.

      Como a configuração dos bancos de dados gerenciados da DigitalOcean limita a eficácia tanto da replicação e quanto do snapshotting como meio de migração de dados, este tutorial utilizará o comando migrate do Redis para mover dados da origem para o destino. O comando migrate é projetado para mover apenas uma chave de cada vez, mas vamos usar alguns truques de linha de comando para mover um banco de dados Redis inteiro com um único comando.

      Este passo opcional envolve o carregamento da instância Redis de origem com alguns dados de amostra para que você possa experimentar a migração de dados para o banco de dados Redis gerenciado. Se você já possui dados que deseja migrar para sua instância de destino, você pode avançar para o Passo 2.

      Para começar, execute o seguinte comando para acessar o seu servidor Redis:

      Se você configurou seu servidor Redis para exigir autenticação por senha, execute o comando auth seguido da sua senha Redis:

      Em seguida, execute os seguintes comandos. Isso criará um número de chaves contendo algumas strings, um hash, uma lista e um set:

      • mset string1 "Redis" string2 "is" string3 "fun!"
      • hmset hash1 field1 "Redis" field2 "is" field3 "fast!"
      • rpush list1 "Redis" "is" "feature-rich!"
      • sadd set1 "Redis" "is" "free!"

      Além disso, execute os seguintes comandos expire para fornecer um tempo limite para algumas dessas chaves. Isso as tornará voláteis, o que significa que o Redis as excluirá após o período especificado, 7500 segundos:

      • expire string2 7500
      • expire hash1 7500
      • expire set1 7500

      Com isso, você tem alguns dados de exemplo que podem ser exportados para sua instância Redis de destino. Você pode manter o prompt do redis-cli aberto por enquanto, pois executaremos mais alguns comandos a partir dele no próximo passo para fazer backup desses dados.

      Passo 2 — Fazendo Backup dos Seus Dados

      Anteriormente, discutimos o uso do comando bgsave do Redis para tirar uma snapshot de um banco de dados Redis e migrá-lo para outra instância. Embora não utilizemos o bgsave como meio de migrar os dados do Redis, vamos usá-lo aqui para fazer backup dos dados, caso encontremos um erro durante o processo de migração.

      Se você ainda não o tiver aberto, comece abrindo a interface de linha de comandos do Redis:

      Além disso, se você configurou o seu servidor Redis para exigir autenticação por senha, execute o comando auth seguido da sua senha Redis:

      Em seguida, execute o comando bgsave. Isso criará um snapshot do seu data set atual e o exportará para um arquivo de dump cujo nome termina em .rdb:

      Nota: Conforme mencionado na seção anterior Coisas a Considerar, você pode tirar um snapshot do seu banco de dados Redis com os comandos save ou bgsave. A razão pela qual usamos o comando bgsave aqui é que o comando save é executado de forma síncrona, o que significa que ele bloqueará quaisquer outros clientes conectados ao banco de dados. Por isto, a documentação do comando save recomenda que esse comando quase nunca seja executado em um ambiente de produção.

      Em vez disso, ela sugere o uso do comando bgsave, que executa de forma assíncrona. Isso fará com que o Redis faça um fork do banco de dados em dois processos: o processo pai continuará a servir os clientes enquanto o filho salva o banco de dados antes de sair:

      Observe que se os clientes adicionarem ou modificarem dados enquanto a operação bgsave estiver em execução ou após a conclusão, essas alterações não serão capturadas no snapshot.

      Depois disso, você pode fechar a conexão com sua instância Redis executando o comando exit:

      Se você precisar no futuro, você poderá encontrar este arquivo de dump no seu diretório de trabalho da instalação do Redis. Se você não tiver certeza de qual diretório é esse, pode verificar abrindo seu arquivo de configuração Redis com o seu editor de texto preferido. Aqui, usaremos o nano:

      • sudo nano /etc/redis/redis.conf

      Navegue até a linha que começa com dbfilename. Por padrão, ele se apresentará assim:

      /etc/redis/redis.conf

      . . .
      # The filename where to dump the DB
      dbfilename dump.rdb
      . . .
      

      Esta diretiva define o arquivo para o qual o Redis exportará snapshots. A próxima linha (após qualquer comentário) ficará assim:

      /etc/redis/redis.conf

      . . .
      dir /var/lib/redis
      . . .
      

      A diretiva dir define o diretório de trabalho do Redis onde os snapshots são armazenados. Por padrão, isso é definido como /var/lib/redis, como mostrado neste exemplo.

      Feche o arquivo redis.conf. Supondo que você não tenha alterado o arquivo, você pode fazer isso pressionando CTRL+X.

      Em seguida, liste o conteúdo do seu diretório de trabalho Redis para confirmar que ele está mantendo o arquivo de dump de dados exportado:

      Se o arquivo de dump foi exportado corretamente, você o verá na saída deste comando:

      Output

      dump.rdb

      Depois de confirmar que você fez backup dos seus dados com êxito, você pode iniciar o processo de migração para o seu Banco de Dados Gerenciado.

      Passo 3 — Migrando os Dados

      Lembre-se de que este guia usa o comando interno migrate do Redis para mover as chaves uma a uma do banco de dados de origem para o destino. No entanto, ao contrário dos passos anteriores deste tutorial, não executaremos este comando no prompt redis-cli. Em vez disso, vamos executá-lo diretamente no prompt bash do servidor. Isso nos permitirá usar alguns truques do bash para migrar todas as chaves no banco de dados de origem com um comando.

      Nota: Se você tiver clientes gravando dados na sua instância Redis de origem, agora seria um bom momento para configurá-los para também gravar dados no seu Banco de Dados Gerenciado. Dessa forma, você pode migrar os dados existentes da origem para o seu destino sem perder nenhuma gravação que ocorra após a migração.

      Além disso, esteja ciente de que este comando de migração não substituirá nenhuma chave existente no banco de dados de destino, a menos que uma das chaves existentes tenha o mesmo nome da chave que você está migrando.

      A migração ocorrerá após a execução do seguinte comando. Antes de executá-lo, porém, vamos dividi-lo parte por parte:

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 | while read key; do redis-cli -n banco_de_dados_de_origem -a senha_da_origem MIGRATE localhost 8000 "$key" banco_de_dados_de_destino 1000 COPY AUTH senha_do_redis_gerenciado; done

      Vamos analisar cada parte deste comando separadamente:

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 . . .

      A primeira parte do comando, redis-cli, abre uma conexão com o servidor Redis local. A flag -n especifica a qual dos bancos de dados lógicos do Redis se conectar. O Redis possui 16 bancos de dados prontos para uso (com o primeiro sendo numerado como 0, o segundo numerado como 1 e assim por diante), portanto, banco_de_dados_de_origem pode ser qualquer número entre 0 e 15. Se sua instância de origem mantém apenas dados no banco de dados padrão (numerado como 0), você não precisará incluir a flag -n ou especificar um número de banco de dados.

      A seguir, vem a flag -a e a senha da instância de origem, que juntos autenticam a conexão. Se sua instância de origem não exigir autenticação por senha, você não precisará incluir a flag -a.

      Em seguida, ele executa o comando scan do Redis, que itera sobre as chaves mantidas no data set e as retorna como uma lista. O scan requer ser seguido de um cursor — a iteração começa quando o cursor está definido como 0, e termina quando o servidor retorna um cursor 0. Portanto, seguimos o scan com um cursor 0 para iterar sobre todas as chaves do conjunto.

      • . . . | while read key; do . . .

      A próxima parte do comando começa com uma barra vertical (|). Nos sistemas tipo Unix, as barras verticais são conhecidas como pipes e são usadas para direcionar a saída de um processo para a entrada de outro.

      A seguir, é iniciado o loop while. No bash, assim como na maioria das linguagens de programação, um loop while é uma declaração de fluxo de controle que permite repetir um determinado processo, código ou comando, enquanto uma certa condição permanecer verdadeira.

      A condição neste caso é o subcomando read key, que lê a entrada que foi canalizada e a atribui à variável key. O ponto-e-vírgula (;) significa o final da declaração condicional do loop while, e o do a seguir precede a ação que será repetida enquanto a expressão while permanecer verdadeira. Toda vez que a instrução do for concluída, a instrução condicional lerá a próxima linha canalizada a partir do comando scan e atribuirá essa entrada à variável key.

      Essencialmente, esta seção diz “enquanto houver saída do comando scan para ser lida, execute a seguinte ação”.

      • . . . redis-cli -n banco_de_dados_de_origem -a senha_da_origem migrate localhost 8000 "$key" . . .

      Esta seção do comando é a que executa a migração real. Após outra chamada do redis-cli, ela especifica mais uma vez o número do banco de dados de origem com a flag -n e autentica com a flag -a. Você precisa incluí-las novamente, porque essa chamada redis-cli é distinta daquela no início do comando. Mais uma vez, porém, você não precisa incluir a flag -n ou o número do banco de dados se a instância Redis de origem mantém apenas dados no banco de dados padrão 0, e você não precisa incluir a flag -a se ela não requer autenticação por senha.

      A seguir, está o comando migrate. Sempre que você usar o comando migrate, deverá segui-lo com o nome do host ou endereço IP do banco de dados de destino e o número da porta. Aqui, seguimos a convenção estabelecida no tutorial de pré-requisito do stunnel e apontamos o comando migrate para localhost na porta 8000.

      $key é a variável definida na primeira parte do loop while e representa as chaves de cada linha da saída do comando scan.

      • . . . banco_de_dados_de_destino 1000 copy auth senha_do_redis_gerenciado; done

      Esta seção é uma continuação do comando migrate. Ela começa com banco_de_dados_de_destino, que representa o banco de dados lógico na instância de destino em que você deseja armazenar os dados. Novamente, este pode ser qualquer número entre 0 e 15.

      Em seguida está um número que representa um tempo limite. Esse tempo limite é a quantidade máxima de tempo de comunicação inativa entre as duas máquinas. Observe que este não é um limite de tempo para a operação, apenas que a operação deve sempre fazer algum nível de progresso dentro do tempo limite definido. Tanto o número do banco de dados quanto os argumentos de tempo limite são necessários para cada comando migrate.

      Após o tempo limite está a flag opcional copy. Por padrão, o migrate excluirá cada chave do banco de dados de origem depois de transferi-la para o destino; Ao incluir esta opção, você está instruindo o comando migrate a meramente copiar as chaves para que elas persistam na origem.

      Após o copy, aparece a flag auth, seguido da senha do seu Banco de Dados Redis Gerenciado. Isso não é necessário se você estiver migrando dados para uma instância que não requer autenticação, mas é necessário quando você estiver migrando dados para um banco gerenciado pela DigitalOcean.

      A seguir, outro ponto-e-vírgula, indicando o final da ação a ser executada enquanto a condição while for verdadeira. Finalmente, o comando fecha com done, indicando o fim do loop. O comando verifica a condição na instrução while e repete a ação na instrução do até que ela não seja mais verdadeira.

      Em conjunto, este comando executa os seguintes passos:

      • Examina um banco de dados na instância Redis de origem e retorna todas as chaves nela contidas
      • Passa cada linha da saída do comando scan para um loop while
      • Lê a primeira linha e atribui seu conteúdo à variável key
      • Migra qualquer chave no banco de dados de origem que corresponda à variável key para um banco de dados na instância Redis na outra extremidade do túnel TLS mantida em localhost na porta 8000
      • Volta e lê a próxima linha, e repete o processo até que não haja mais chaves para ler

      Agora que examinamos cada parte do comando de migração, você pode prosseguir e executá-lo.

      Se sua instância de origem tiver apenas dados no banco de dados 0 padrão, você não precisa incluir quaisquer das flags -n ou seus argumentos. Se, no entanto, você estiver migrando dados de qualquer banco de dados que não seja o 0 na sua instância de origem, você deve incluir as flags -n e alterar as duas ocorrências de banco_de_dados_de_origem para alinhar com o banco de dados que você deseja migrar.

      Se o seu banco de dados de origem exigir autenticação por senha, certifique-se de alterar senha_da_origem para a senha real da instância do Redis. Caso contrário, certifique-se de remover ambas as ocorrências de -a senha_da_origem do comando. Além disso, altere senha_do_redis_gerenciado para a senha do seu Banco de Dados Gerenciado e certifique-se de alterar banco_de_dados_de_destino para o número do banco de dados lógico na sua instância de destino em que você deseja gravar os dados:

      Nota: Se você não tiver a senha do seu banco de dados Redis gerenciado em mãos, poderá encontrá-la navegando primeiramente para o Painel de controle da DigitalOcean. A partir daí, clique em Databases no menu da barra lateral esquerda e depois clique no nome da instância Redis para a qual você deseja migrar os dados. Role para baixo até a seção Connection Details, onde você encontrará um campo chamado password. Clique no botão show para revelar a senha e copie e cole-a no comando de migração — substituindo senha_do_redis_gerenciado – para autenticar.

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 | while read key; do redis-cli -n banco_de_dados_de_origem -a senha_da_origem MIGRATE localhost 8000 "$key" banco_de_dados_de_destino 1000 COPY AUTH senha_do_redis_gerenciado; done

      Você verá uma saída semelhante à seguinte:

      Output

      NOKEY OK OK OK OK OK OK

      Nota: Observe a primeira linha da saída do comando que lê NOKEY. Para entender o que isso significa, execute a primeira parte do comando de migração sozinho:

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0

      Se você migrou os dados de amostra adicionados no Passo 2, a saída deste comando será parecida com esta:

      Output

      1) "0" 2) 1) "hash1" 2) "string3" 3) "list1" 4) "string1" 5) "string2" 6) "set1"

      O valor "0" mantido na primeira linha não é uma chave mantida no seu banco de dados Redis de origem, mas um cursor retornado pelo comando scan. Como não há chaves no servidor denominadas “0”, não há nada lá para o comando migrate enviar à sua instância de destino e ele retorna NOKEY.

      No entanto, o comando não falha e sai. Em vez disso, ele continua lendo e migrando as chaves encontradas nas próximas linhas da saída do comando scan.

      Para testar se a migração foi bem-sucedida, conecte-se ao seu Banco de Dados Redis Gerenciado:

      • redis-cli -h localhost -p 8000 -a senha_do_redis_gerenciado

      Se você migrou dados para qualquer banco de dados lógico que não o padrão, conecte-se a esse banco de dados com o comando select:

      • select banco_de_dados_de_destino

      Execute um comando scan para ver quais chaves são mantidas lá:

      Se você concluiu o Passo 2 deste tutorial e adicionou os dados de exemplo ao seu banco de dados de origem, você verá resultados como este:

      Output

      1) "0" 2) 1) "set1" 2) "string2" 3) "hash1" 4) "list1" 5) "string3" 6) "string1"

      Por fim, execute um comando ttl em qualquer chave que você configurou para expirar para confirmar que ela ainda é volátil:

      Output

      (integer) 3944

      Esta saída mostra que, embora você tenha migrado a chave para o seu Banco de Dados Gerenciado, ela ainda está configurada para expirar com base no comando expireat que você executou anteriormente.

      Depois de confirmar que todas as chaves do seu banco de dados Redis de origem foram exportadas para o destino com êxito, você pode fechar sua conexão com o Banco de Dados Gerenciado. Se você tiver clientes gravando dados na instância Redis de origem e já os configurou para enviar suas gravações para o destino, nesse momento você pode configurá-los para parar de enviar dados para a origem.

      Conclusão

      Ao concluir este tutorial, você transferiu os dados do seu repositório de dados Redis autogerenciado para uma instância Redis gerenciada pela DigitalOcean. O processo descrito neste guia pode não ser o ideal em todos os casos. Por exemplo, você teria que executar o comando de migração várias vezes (uma vez para cada banco de dados lógico que contém dados) se sua instância de origem estiver usando bancos de dados diferentes do padrão. No entanto, quando comparado a outros métodos, como replicação ou snapshotting, este é um processo bastante direto que funciona bem com a configuração de um Banco de Dados Gerenciado pela DigitalOcean.

      Agora que você está usando um Banco de Dados Redis Gerenciado pela DigitalOcean para armazenar seus dados, você pode medir seu desempenho executando alguns testes de benchmarking. Além disso, se você é novo no trabalho com o Redis, você pode conferir nossa série Como Gerenciar um Banco de Dados Redis.



      Source link

      Como se Conectar a um Banco de Dados Redis


      Introdução

      O Redis é um datastore ou armazenamento de dados open-source de chave-valor na memória. Se você instalou o Redis localmente ou está trabalhando com uma instância remota, é necessário conectar-se a ele para executar a maioria das operações. Neste tutorial, veremos como se conectar ao Redis a partir da linha de comando, como autenticar e testar sua conexão, bem como fechar uma conexão do Redis.

      Como Utilizar Este Guia

      Este guia está no formato de referência rápida com trechos de linha de comando 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 4.0.9 do Redis. 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.

      Como alternativa, 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 de produto para Managed Databases. Então, você deve instalar ou o Redli ou configurar um túnel TLS para conectar-se ao banco de dados gerenciado por TLS.

      Conectando ao Redis

      Se você tiver o redis-server instalado localmente, você pode conectar-se à instância Redis com o comando redis-cli:

      Isso o levará ao modo interativo do redis-cli, que lhe apresenta um read-eval-print loop (REPL) onde você pode executar os comandos internos do Redis e receber respostas.

      No modo interativo, seu prompt de linha de comando será alterado para refletir sua conexão. Neste exemplo e em outros neste guia, o prompt indica uma conexão com uma instância do Redis hospedada localmente (127.0.0.1) e acessada pela porta padrão do Redis (6379):

      A alternativa para executar comandos Redis no modo interativo é executá-los como argumentos para o comando redis-cli, da seguinte forma:

      Se você deseja se conectar a um datastore remoto do Redis, poderá especificar seu host e número de porta com as flags -h e -p, respectivamente. Além disso, se você configurou seu banco de dados Redis para exigir uma senha, você pode incluir a flag -a seguido da sua senha para se autenticar:

      • redis-cli -h host -p port_number -a password

      Se você definiu uma senha no Redis, os clientes poderão se conectar ao Redis, mesmo que não incluam a flag -a no comandoredis-cli. No entanto, eles não poderão adicionar, alterar ou consultar dados até que sejam autenticados. Para autenticar após a conexão, use o comando auth seguido da senha:

      Se a senha passada para auth for válida, o comando retornará OK. Caso contrário, ele retornará um erro.

      Se você estiver trabalhando com um banco de dados Redis gerenciado, seu provedor de nuvem poderá lhe fornecer um URI que comece com redis:// ou rediss://, que você pode usar para acessar seu datastore. Se a string de conexão começar com redis://, você poderá incluí-la como um argumento para o redis-cli para conectar.

      No entanto, se você tiver uma string de conexão que comece com rediss://, isso significa que seu banco de dados gerenciado requer conexões através de TLS/SSL. O redis-cli não suporta conexões TLS, portanto você precisará usar uma ferramenta diferente que suporte o protocolo rediss para conectar-se ao URI. Para os bancos de dados gerenciados da DigitalOcean, que exigem que as conexões sejam feitas por TLS, recomendamos o uso do Redli para acessar a instância do Redis.

      Use a seguinte sintaxe para conectar-se a um banco de dados com Redli. Observe que este exemplo inclui a opção --tls, que especifica que a conexão deve ser feita através de TLS, e a flag -u, que declara que o seguinte argumento será um URI de conexão:

      • redli --tls -u rediss://connection_URI

      Se você tentou se conectar a uma instância indisponível, o redis-cli entrará no modo desconectado. O prompt refletirá isso:

      O Redis tentará restabelecer a conexão toda vez que você executar um comando quando estiver em modo desconectado.

      Testando Conexões

      O comando ping é útil para testar se a conexão com um banco de dados está ativa. Observe que este é um comando específico do Redis e é diferente do utilitário de rede ping. No entanto, os dois compartilham uma função semelhante, pois ambos são usados para verificar uma conexão entre duas máquinas.

      Se a conexão estiver ativa e nenhum argumento for incluído, o comando ping retornará PONG:

      Output

      PONG

      Se você fornecer um argumento para o comando ping, ele retornará esse argumento em vez de PONG se a conexão for bem-sucedida:

      Output

      "hello Redis!"

      Se você executar ping ou qualquer outro comando no modo desconectado, verá uma saída como esta:

      Output

      Could not connect to Redis at host:port: Connection refused

      Note que o ping também é usado internamente pelo Redis para medir a latência.

      Desconectando do Redis

      Para desconectar-se de uma instância Redis, use o comando quit:

      Executar exit também sairá da conexão:

      Ambos quit e exit fecharão a conexão, mas apenas assim que todas as respostas pendentes forem gravadas nos clientes.

      Conclusão

      Este guia detalha vários comandos usados para estabelecer, testar e fechar conexões com um servidor Redis. Se houver outros comandos, argumentos ou procedimentos relacionados que você queira ver 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 Como Gerenciar um Banco de Dados Redis.



      Source link