Migrar a base de dados do back-end do Looker para o MySQL

Por predefinição, o Looker usa uma base de dados na memória HyperSQL para armazenar a respetiva configuração, utilizadores e outros dados. Numa instância ocupada, esta base de dados pode crescer até ter gigabytes, o que pode originar problemas de desempenho, pressão de memória Java e longos tempos de arranque.

Numa instância alojada pelo cliente, recomendamos que substitua a base de dados HyperSQL por um back-end de base de dados MySQL completo quando a base de dados HyperSQL interna exceder 600 MB. Para verificar o tamanho da base de dados HyperSQL, veja o tamanho do ficheiro looker.script:

cd looker
cd .db
ls -lah

Se o tamanho do ficheiro looker.script exceder os 600 MB, siga os procedimentos abaixo para migrar para uma base de dados MySQL externa.

Nota: este procedimento pressupõe uma implementação no AWS EC2. Para implementações locais, os sistemas devem ter um tamanho comparável ao das instâncias da AWS equivalentes.

Os clientes que atualizam para o Looker 6.6 ou posterior a partir de uma versão anterior ao Looker 6.6 não podem fazer a atualização do Looker e migrar para uma BD de back-end do MySQL ao mesmo tempo. Se estiver a atualizar o Looker e a migrar para o MySQL, recomendamos que conclua a atualização do Looker antes de realizar a migração para o MySQL.

Aprovisione uma instância do MySQL

Aprovisione uma instância do MySQL 8.0.x para usar como back-end. As versões do MySQL anteriores à 8.0 não são suportadas.

No AWS RDS, uma instância da classe db.m5.large é provavelmente suficiente como back-end para uma única instância do Looker. Embora a utilização real da base de dados seja provavelmente entre 5 e 10 GB, é uma boa ideia aprovisionar 100 a 150 GB de armazenamento SSD, uma vez que os IOPS aprovisionados se baseiam na quantidade de armazenamento pedida.

MySQL 8.0.X: alterar o plug-in de autenticação predefinido

No MySQL 8.0.X, o plug-in de autenticação predefinido é caching_sha2_password. O Looker usa o plug-in mysql_native_password para tentar fazer a autenticação nas bases de dados MySQL através do controlador JDBC. Para que esta versão do MySQL funcione corretamente, tem de seguir os seguintes passos adicionais:

1. Configure a base de dados do MySQL para usar o plug-in mysql_native_password. Isto pode ser feito de várias formas e depende da forma como a sua base de dados MySQL 8 está implementada e do tipo de acesso que tem à configuração:

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

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

     [mysqld]
     default-authentication-plugin=mysql_native_password
     

   • Se a instância da base de dados estiver alojada através do AWS RDS, defina o parâmetro default_authentication_plugin através de um grupo de parâmetros do RDS que seja aplicado a esta instância da base de dados.

2. Emita as seguintes declarações, substituindo some_password_here por uma palavra-passe única e segura:

   CREATE USER looker IDENTIFIED WITH mysql_native_password BY 'some_password_here';
   GRANT SELECT ON database_name.* TO 'looker'@'%';
   

Ajuste o MySQL

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

Aumente o tamanho máximo do pacote

O tamanho predefinido do MySQL max_allowed_packet é demasiado pequeno para a migração da base de dados e pode fazer com que a migração falhe com um erro PACKET_TOO_LARGE. Defina max_allowed_packet para o valor máximo permitido de 1073741824:

max_allowed_packet = 1073741824

Defina o algoritmo da tabela temporária

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

internal_tmp_mem_storage_engine = MEMORY

Configure conjuntos de carateres

Defina os seguintes parâmetros predefinidos para usar UTF8mb4, que suporta conjuntos de carateres UTF8. Consulte o artigo No MySQL, nunca use "utf8". Use "utf8mb4". para obter informações sobre o motivo pelo qual recomendamos a utilização 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

Nas instâncias do Amazon RDS, aplica esta definição criando ou modificando um grupo de parâmetros e editando as definições adequadas. Recomendamos que copie o grupo de parâmetros atual e faça as alterações na cópia, especialmente se estiver a partilhar grupos de parâmetros em várias instâncias do RDS. Depois de guardar o grupo de parâmetros, aplique-o à instância do RDS. Pode ser necessário reiniciar.

Defina o esquema de réplica

O Looker baseia-se numa funcionalidade que requer um binlog mixed ou row. Se estiver a alojar a sua própria instância do MySQL, defina o binlog_format como mixed ou row emitindo um dos seguintes comandos:

SET GLOBAL binlog_format = 'MIXED';

ou

SET GLOBAL binlog_format = 'ROW';

Crie uma base de dados e um utilizador

Crie um utilizador e uma base de dados na instância da base de dados, substituindo <DB_username>, <DB_name> e <DB_password> pelos valores reais do utilizador e da base de dados. Substitua também <DB_charset> e <DB_collation> pelo conjunto de carateres e pela ordenação escolhidos que correspondem às definições do grupo de parâmetros da instância do RDS (para um verdadeiro suporte de UTF8, recomendamos utf8mb4 e utf8mb4_general_ci).

create user <DB_username>;
set password for <DB_username> = password ('<DB_password>');
create database <DB_name> default character set <DB_charset> default collate <DB_collation>;
grant all on <DB_name>.* to <DB_username>@'%';
grant all on looker_tmp.* to '<DB_username>'@'%';

A base de dados looker_tmp na última linha não tem de existir efetivamente, mas a declaração grant é necessária para relatórios internos.

Crie um ficheiro de credenciais da base de dados

O Looker precisa de saber com que base de dados do MySQL comunicar e que credenciais usar. No diretório do Looker, crie um ficheiro denominado looker-db.yml com o seguinte conteúdo, substituindo <DB_hostname>, <DB_username>, <DB_password> e <DB_name> por valores da sua base de dados:

dialect: mysql
host: <DB_hostname>
username: <DB_username>
password: <DB_password>
database: <DB_name>
port: 3306

Se a sua base de dados do MySQL exigir uma ligação SSL, adicione a seguinte linha a looker-db.yml:

ssl: true

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

verify_ssl: true

Opcionalmente, também pode especificar outros parâmetros JDBC adicionais suportados pelo controlador JDBC do MariaDB adicionando jdbc_additional_params. Por exemplo, se precisar de usar um ficheiro de repositório de confiança específico, pode adicionar o seguinte parâmetro à string de ligação JDBC do MySQL:

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

Para instalações alojadas pelo cliente, pode especificar opcionalmente o número máximo de ligações que o Looker pode estabelecer com a sua base de dados adicionando max_connections. Por exemplo, para limitar o número de ligações simultâneas à sua base de dados a 10, adicione o seguinte:

max_connections: 10

Importante: siga as considerações de segurança de práticas recomendadas quando guardar credenciais num ficheiro. Idealmente, defina as autorizações de ficheiros looker-db.yml como 600, pertencentes à conta "user" do Linux na qual a aplicação Looker é executada. Este ficheiro nunca deve ser adicionado a um repositório Git.

No esquema de encriptação do Looker, todos os dados confidenciais na base de dados são encriptados em repouso. Mesmo que alguém consiga aceder às credenciais da base de dados de texto simples e aceder à base de dados, o Looker encripta ou aplica hash aos dados confidenciais antes do armazenamento. Isto aplica-se a palavras-passe, credenciais da base de dados de estatísticas, cache de consultas, etc. No entanto, se não quiser armazenar a palavra-passe de texto não cifrado para esta configuração no ficheiro looker-db.yml no disco, pode configurar a variável de ambiente LOOKER_DB para conter uma lista de chaves/valores para cada linha no ficheiro looker-db.yml. Por exemplo:

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

Importante: limite a utilização da sua conta de utilizador do MySQL ao endereço IP usado pelo seu servidor do Looker.

Faça uma cópia de segurança do diretório .db

Faça uma cópia de segurança do diretório .db, que contém os ficheiros necessários para criar a base de dados HyperSQL na memória, caso precise de restaurar o HyperSQL:

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

Migre a base de dados

A migração da base de dados para o MySQL pode demorar horas numa instância média ou grande, especialmente se a base de dados HyperSQL tiver 1 GB ou mais. Recomendamos que atualize temporariamente a instância do EC2 para um m5.2xlarge (com 32 GB de RAM para permitir os 26 GB de memória dinâmica especificados nos passos) durante a migração, o que reduz o tempo necessário para cerca de 10 minutos.

1. No anfitrião do Looker:

   cd looker
   ./looker stop
   vi looker
   

2. No script de arranque do Looker, crie uma nova segunda linha no ficheiro:

   exit
   

3. Pare a instância na consola da AWS. Quando parar, altere o tamanho da instância EC2 para m5.2xlarge. Em seguida, inicie novamente a instância.

4. Use SSH para aceder ao anfitrião como utilizador do Looker. Primeiro, certifique-se de que o Java não está em execução e, em seguida, execute:

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

   Quando executar o passo migrate_internal_data, o libcrypt pode não ser encontrado e é apresentada uma rastreabilidade da pilha, começando com o seguinte:

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

   Se isto 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 a conclusão for bem-sucedida, pare a instância na consola da AWS.

6. Agora, pode restaurar o tamanho original da instância.

7. Inicie novamente a instância.

Inicie o Looker

1. Edite o script de arranque do Looker e elimine a linha exit que adicionou anteriormente.

2. Certifique-se de que não existem argumentos definidos em LOOKERARGS no script de arranque. Em alternativa, todos os argumentos devem ser movidos para o ficheiro lookerstart.cfg para que não sejam substituídos por novas versões do script de arranque. Guarde e saia do script de arranque.

3. Edite o pacote lookerstart.cfg. Deve ter um aspeto semelhante ao seguinte:

   LOOKERARGS="-d looker-db.yml"
   

   Se existirem outros argumentos no script de arranque do Looker, adicione-os ao ficheiro lookerstart.cfg.

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

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

5. Iniciar Looker:

   ./looker start
   

Verifique se o Looker está a usar a nova base de dados

Se o Looker estiver a usar o MySQL de back-end com êxito, deve ver ligações de rede entre a instância do Looker e a nova instância da base de dados. Para verificar esta situação, execute o seguinte comando na instância do Looker:

netstat -na | grep 3306

Deve ver algumas ligações à instância da base de dados. Segue-se um exemplo de saída que mostra uma instância de base 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 uma cópia de segurança do Looker

Depois de migrar para um back-end do MySQL, as cópias de segurança automáticas do S3 do Looker deixam de funcionar. Recomendamos, pelo menos, cópias de segurança noturnas da base de dados MySQL, juntamente com cópias de segurança noturnas do sistema de ficheiros do diretório de trabalho do Looker. O diretório looker/log/ pode ser excluído das cópias de segurança do sistema de ficheiros. Consulte a página de documentação Criar cópias de segurança para mais informações.