Migrar o banco de dados de back-end do Looker para o MySQL

Por padrão, o Looker usa um banco de dados HyperSQL na memória para armazenar a configuração, os usuários e outros dados. Em uma instância ocupada, esse banco de dados pode crescer até ter gigabytes de tamanho, o que pode causar problemas de desempenho, pressão de memória Java e longos tempos de inicialização.

Em uma instância hospedada pelo cliente, recomendamos substituir o banco de dados HyperSQL por um back-end completo do MySQL quando o banco de dados HyperSQL interno exceder 600 MB. Para verificar o tamanho do banco de dados HyperSQL, confira o tamanho do arquivo looker.script:

cd looker
cd .db
ls -lah

Se o arquivo looker.script exceder 600 MB, siga os procedimentos abaixo para migrar para um banco de dados MySQL externo.

Observação: este procedimento pressupõe uma implantação no AWS EC2. Para implantações locais, os sistemas precisam ter um tamanho comparável às instâncias equivalentes da AWS. Se você estiver atualizando o Looker e migrando para o MySQL, recomendamos que conclua a atualização do Looker antes de realizar a migração para o MySQL.

Provisionar uma instância e um usuário do MySQL

É possível provisionar uma instância do MySQL 8.4.X (recomendado) ou do MySQL 8.0.X para usar como back-end. Não há suporte para versões do MySQL anteriores à 8.0.

O Looker 26.6 e versões mais recentes são compatíveis com o MySQL 8.4.X para o banco de dados de back-end do Looker. Para instâncias hospedadas pelo cliente que usam o MySQL 8.0.X no banco de dados de back-end do Looker, recomendamos atualizar para o MySQL 8.4.X assim que a instância do Looker for atualizada para a versão 26.6 ou mais recente.

No RDS da AWS, uma instância da classe db.m5.large provavelmente é suficiente como back-end para uma única instância do Looker. Embora o uso real do banco de dados provavelmente esteja na faixa de 5 a 10 GB, é recomendável provisionar 100 a 150 GB de armazenamento SSD, porque os IOPS provisionados são baseados na quantidade de armazenamento solicitada.

MySQL 8.4.X

O Looker é compatível com o uso do MySQL 8.4.X como banco de dados interno a partir do Looker 26.6. Para o MySQL 8.4.X, é possível usar um dos seguintes plug-ins de autenticação do MySQL, conforme descrito nas seções a seguir:

• caching_sha2_password
• mysql_native_password

Observação: se você estiver fazendo upgrade do back-end do Looker do MySQL 8.0.X para o MySQL 8.4.X, poderá manter o usuário do banco de dados criado para o MySQL 8.0.X. No entanto, com o MySQL 8.0.X, o Looker exige que os usuários do banco de dados façam a autenticação com mysql_native_password. Portanto, se você quiser manter o usuário do banco de dados do MySQL 8.0.X, siga as instruções para provisionar o MySQL 8.4.X com mysql_native_password para que o usuário atual ainda possa se autenticar. Caso contrário, se você quiser criar um novo usuário ao provisionar o MySQL 8.4.X, provisione a instância do MySQL e crie um novo usuário com o plug-in de autenticação caching_sha2_password ou mysql_native_password.

Como usar o caching_sha2_password

No MySQL 8.4.X, o plug-in de autenticação padrão é caching_sha2_password. O Looker oferece duas maneiras de usar o plug-in caching_sha2_password:

1. Ao usar uma conexão SSL para o banco de dados interno:nenhuma chave pública RSA é necessária. O Looker se conecta com segurança ao banco de dados usando as credenciais de usuário fornecidas. Consulte a seção Criar um arquivo de credenciais de banco de dados nesta página para configurar uma conexão SSL com seu banco de dados.
2. Se a conexão não for feita com o SSL ativado:por padrão, o Looker usa a opção --get-server-public-key para se conectar ao banco de dados interno quando o plug-in caching_sha2_password é usado pela conta de usuário fornecida ao Looker. Verifique se o ambiente de rede está seguro se o SSL não estiver ativado.

Observação: o Looker não aceita a especificação de um arquivo local como chave pública RSA para conexão.

Para qualquer uma das formas de usar o plug-in caching_sha2_password, configure o usuário emitindo a seguinte instrução:

CREATE USER 'DB_username' IDENTIFIED WITH caching_sha2_password BY 'password';

Substitua:

• DB_username: nome de usuário
• password: senha única e segura

Como usar o mysql_native_password

O Looker funciona com o plug-in mysql_native_password para autenticar bancos de dados MySQL usando o driver JDBC. Para que o MySQL 8.4.X funcione com o plug-in mysql_native_password, siga estas etapas adicionais:

1. Configure o banco de dados MySQL para ativar o plug-in mysql_native_password. Isso pode ser feito de várias maneiras, dependendo de como o banco de dados MySQL é implantado e do tipo de acesso que você tem à configuração:

   1. Inicie o servidor MySQL com --mysql-native-password=ON.

   2. Defina a propriedade no arquivo de configuração my.cnf:

      [mysqld]
      mysql_native_password=ON
      

   3. Se a instância do MySQL estiver hospedada no Google Cloud, na AWS ou no Azure, o plug-in mysql_native_password será ativado automaticamente. Consulte a documentação do provedor para instruções detalhadas.

2. Crie o usuário:

   CREATE USER 'DB_username' IDENTIFIED WITH mysql_native_password BY 'password';
   

   Substitua:

   • DB_username: nome de usuário
   • password: senha única e segura

MySQL 8.0.X

No MySQL 8.0.X, o plug-in de autenticação padrão é caching_sha2_password. O Looker usa o plug-in mysql_native_password para tentar autenticar em bancos de dados MySQL pelo driver JDBC. Para que o MySQL 8.0.X funcione corretamente, siga estas etapas adicionais:

1. Configure o banco de dados MySQL para usar o plug-in mysql_native_password. Isso pode ser feito de várias maneiras e depende de como o banco de dados MySQL 8 é implantado e do tipo de acesso que você tem à configuração:

   • Inicie o processo com a flag --default-auth=mysql_native_password

   • Defina a propriedade no arquivo de configuração my.cnf:

     [mysqld]
     default-authentication-plugin=mysql_native_password
     

   • Se a instância do banco de dados estiver hospedada no AWS RDS, defina o parâmetro default_authentication_plugin usando um grupo de parâmetros do RDS aplicado a essa instância.

2. Crie o usuário:

   CREATE USER 'DB_username' IDENTIFIED WITH mysql_native_password BY 'password';
   

   Substitua:

   • DB_username: nome de usuário
   • password: senha única e segura

Ajustar o MySQL

Ajuste as seguintes configurações na sua instância do MySQL.

Aumentar o tamanho máximo do pacote

O tamanho padrão max_allowed_packet do MySQL é muito pequeno para a migração de banco de dados e pode fazer com que ela falhe com um erro PACKET_TOO_LARGE. Defina max_allowed_packet como o valor máximo permitido de 1073741824:

max_allowed_packet = 1073741824

Definir o algoritmo de tabela temporária

O MySQL 8 processa tabelas temporárias internas de maneira diferente das versões anteriores. As configurações padrão podem causar problemas na execução de algumas das consultas necessárias para o Looker, especialmente em instâncias com muitos usuários e projetos. A prática recomendada é definir a seguinte configuração global do servidor:

internal_tmp_mem_storage_engine = MEMORY

Configurar conjuntos de caracteres

Defina os seguintes parâmetros padrão para usar UTF8mb4, que é compatível com conjuntos de caracteres UTF8. Consulte o artigo No MySQL, nunca use "utf8". Use "utf8mb4". para saber por que recomendamos o uso de UTF8mb4, e não UTF8, com o MySQL.

character_set_client = utf8mb4
character_set_results = utf8mb4
character_set_connection = utf8mb4
character_set_database = utf8mb4
character_set_server = utf8mb4
collation_connection = utf8mb4_general_ci
collation_server = utf8mb4_general_ci

Em instâncias do Amazon RDS, aplique essa configuração criando ou modificando um grupo de parâmetros e editando as configurações adequadas. Recomendamos que você copie o grupo de parâmetros atual e faça as mudanças na cópia, principalmente se estiver compartilhando grupos de parâmetros em várias instâncias do RDS. Depois de salvar o grupo de parâmetros, aplique-o à instância do RDS. Talvez seja necessário reiniciar o dispositivo.

Definir seu esquema de réplica

O Looker depende de funcionalidades que exigem um binlog mixed ou row. Se você estiver hospedando sua própria instância do MySQL, defina binlog_format como mixed ou row executando um dos seguintes comandos:

SET GLOBAL binlog_format = 'MIXED';

ou

SET GLOBAL binlog_format = 'ROW';

Criar um banco de dados e conceder permissão do usuário

Crie um banco de dados na instância:

create database DB_name default character set DB_charset default collate DB_collation;

Em seguida, conceda permissões ao usuário criado ao provisionar a instância e o usuário do MySQL:

grant all on DB_name.* to 'DB_username'@'%';
grant all on looker_tmp.* to 'DB_username'@'%';

Substitua:

• DB_name: nome do banco de dados
• DB_charset: o conjunto de caracteres que corresponde às configurações do grupo de parâmetros da instância do RDS. Para suporte verdadeiro a UTF8, recomendamos utf8mb4.
• DB_collation: a ordenação que corresponde às configurações do grupo de parâmetros da instância do RDS. Para suporte verdadeiro a UTF8, recomendamos utf8mb4_general_ci.
• DB_username: nome de usuário

O banco de dados looker_tmp na última linha não precisa existir, mas a instrução grant é necessária para relatórios internos.

Criar um arquivo de credenciais do banco de dados

O Looker precisa saber com qual banco de dados MySQL se comunicar e quais credenciais usar. No diretório do Looker, crie um arquivo chamado looker-db.yml com o seguinte conteúdo, substituindo DB_hostname, DB_username, DB_password e DB_name por valores do seu banco de dados:

dialect: mysql_8
host: DB_hostname
username: DB_username
password: DB_password
database: DB_name
port: 3306

Se o banco de dados MySQL exigir uma conexão SSL, adicione a seguinte linha a looker-db.yml:

ssl: true

Se você também quiser ativar a verificação do certificado SSL, adicione a seguinte linha a looker-db.yml:

verify_ssl: true

Também é possível especificar outros parâmetros JDBC compatíveis com o driver JDBC do MariaDB adicionando jdbc_additional_params. Por exemplo, se você precisar usar um arquivo de Trust Store específico, adicione o seguinte parâmetro à string de conexão JDBC do MySQL:

jdbc_additional_params: trustStore=/path/to/my/truststore.jks&keyStore=/path/to/my/keystore.jks

Para instalações hospedadas pelo cliente, é possível especificar o número máximo de conexões que o Looker pode estabelecer com seu banco de dados adicionando max_connections. Por exemplo, para limitar o número de conexões simultâneas com o banco de dados a 10, adicione o seguinte:

max_connections: 10

Importante: siga as considerações de segurança das práticas recomendadas ao salvar credenciais em um arquivo. O ideal é definir as permissões do arquivo looker-db.yml como 600, de propriedade da conta "user" do Linux em que o aplicativo Looker é executado. Esse arquivo nunca deve ser verificado em um repositório Git.

No esquema de criptografia do Looker, todos os dados sensíveis no banco de dados são criptografados em repouso. Mesmo que alguém consiga acesso às credenciais do banco de dados em texto simples e acesse o banco de dados, o Looker criptografa ou faz hash dos dados sensíveis antes de armazenar. Isso se aplica a elementos como senhas, credenciais de banco de dados de análise e cache de consultas. No entanto, se você não quiser armazenar a senha em texto não criptografado dessa configuração no arquivo looker-db.yml no disco, configure a variável de ambiente LOOKER_DB para conter uma lista de chaves e valores para cada linha do arquivo looker-db.yml. Exemplo:

export LOOKER_DB="dialect=mysql_8&host=localhost&username=root&password=&database=looker&port=3306"

Importante: limite o uso da sua conta de usuário do MySQL ao endereço IP usado pelo servidor do Looker.

Fazer backup do diretório .db

Faça backup do diretório .db, que contém os arquivos necessários para criar o banco de dados HyperSQL na memória, caso precise restaurar o HyperSQL:

cp -r .db .db-backup
tar -zcvf db-backup.tar.gz ./.db-backup

Migrar o banco de dados

A migração do banco de dados para o MySQL pode levar horas em uma instância média ou grande, principalmente se o banco de dados HyperSQL tiver 1 GB ou mais. Recomendamos que você faça upgrade temporário da instância do EC2 para um m5.2xlarge (com 32 GB de RAM para permitir o heap de 26 GB especificado nas etapas) durante a migração, o que reduz o tempo necessário para cerca de 10 minutos.

1. No host do Looker:

   cd looker
   ./looker stop
   vi looker
   

2. No script de inicialização do Looker, crie uma segunda linha no arquivo:

   exit
   

3. Pare a instância no console da AWS. Depois que ela parar, mude o tamanho da instância do EC2 para m5.2xlarge. Em seguida, inicie a instância novamente.

4. Acesse o host por SSH como o usuário do Looker. Primeiro, verifique se o Java não está em execução e execute:

   cd looker
   java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data  looker-db.yml
   

   Ao executar a etapa migrate_internal_data, talvez libcrypt não seja encontrado e um stack trace apareça, começando com:

   NotImplementedError: getppid unsupported or native support failed to load
   ppid at org/jruby/RubyProcess.java:752
   ppid at org/jruby/RubyProcess.java:749
   

   Se isso acontecer, defina o LD_LIBRARY_PATH manualmente antes de executar o comando Java:

   export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATH
   

5. Quando isso for concluído, pare a instância no console da AWS.

6. Agora é possível restaurar a instância para o tamanho original.

7. Iniciar a instância novamente.

Iniciar o Looker

1. Edite o script de inicialização do Looker e exclua a linha exit que você adicionou anteriormente.

2. Verifique se não há argumentos definidos em LOOKERARGS no script de inicialização. Em vez disso, todos os argumentos precisam ser movidos para o arquivo lookerstart.cfg para que não sejam substituídos por novas versões do script de inicialização. Salve e saia do script de inicialização.

3. Editar lookerstart.cfg. Aparecerá da seguinte maneira:

   LOOKERARGS="-d looker-db.yml"
   

   Se houver outros argumentos no script de inicialização do Looker, adicione-os ao arquivo lookerstart.cfg.

4. Arquive o diretório .db, se ele ainda não estiver arquivado.

   mv .db .db-backup
   tar -zcvf db-backup.tar.gz ./.db-backup
   rm -rf ./.db-backup/
   

5. Iniciar o Looker:

   ./looker start
   

Verificar se o Looker está usando o novo banco de dados

Se o Looker estiver usando o MySQL de back-end, você vai ver conexões de rede entre a instância do Looker e a nova instância de banco de dados. Para verificar isso, execute o seguinte comando na instância do Looker:

netstat -na | grep 3306

Algumas conexões com a instância do banco de dados vão aparecer. Confira a seguir um exemplo de saída, mostrando uma instância de banco de dados no endereço IP 10.0.3.155:

looker@instance1:~$ netstat -na | grep 3306
tcp6       0      0 10.0.5.131:56583        10.0.3.155:3306         ESTABLISHED
tcp6       0      0 10.0.5.131:56506        10.0.3.155:3306         ESTABLISHED
tcp6       0      0 10.0.5.131:56582        10.0.3.155:3306         ESTABLISHED
tcp6       0      0 10.0.5.131:56508        10.0.3.155:3306         ESTABLISHED

Fazer backup do Looker

Depois de migrar para um back-end do MySQL, os backups automatizados do S3 do Looker não vão mais funcionar. Recomendamos pelo menos backups noturnos do banco de dados MySQL e do sistema de arquivos do diretório de trabalho do Looker. O diretório looker/log/ pode ser excluído dos backups do sistema de arquivos. Consulte a página de documentação Como criar backups para mais informações.