Por padrão, o Looker usa um banco de dados no HyperSQL na memória para armazenar suas configurações, usuários e outros dados. Em uma instância movimentada, esse banco de dados pode ter gigabytes, o que pode gerar problemas de desempenho, pressão da memória do Java e tempos longos de inicialização.
Recomendamos substituir o banco de dados do HyperSQL por um back-end completo do MySQL quando o banco de dados interno do HyperSQL exceder 600 MB. Para verificar o tamanho do banco de dados do HyperSQL, veja o tamanho do arquivo looker.script:
cd looker
cd .db
ls -lah
Se o arquivo looker.script exceder 600 MB, siga os procedimentos a seguir para migrar para um banco de dados MySQL externo.
Este procedimento pressupõe uma implantação no AWS EC2. No caso de implantações locais, os sistemas devem ser dimensionados de maneira comparável às instâncias equivalentes da AWS.
Os clientes que atualizarem o Looker 6.6 ou posterior de uma versão anterior ao Looker 6.6 não poderão fazer a atualização do Looker e migrar para um banco de dados MySQL de back-end ao mesmo tempo. Se você estiver atualizando o Looker e migrando para o MySQL, recomendamos que conclua a atualização antes de realizar a migração para o MySQL.
Provisionar uma instância do MySQL
Provisionar uma instância do MySQL 8.0.x para usar como back-end. O Looker também oferece suporte ao MySQL versão 5.7.x.
As versões do MySQL anteriores à 5.7.x não são compatíveis porque não oferecem suporte à codificação UTF8mb4.
No AWS RDS, uma instância da classe db.m5.large provavelmente é suficiente como back-end para uma única instância do Looker. Mesmo que o uso real do banco de dados esteja entre 5 e 10 GB, é recomendável provisionar de 100 a 150 GB de armazenamento SSD, porque as IOPS provisionadas têm como base a quantidade de armazenamento solicitada.
Ajustar o MySQL
O tamanho padrão do max_allowed_packet no MySQL é muito pequeno para a migração de banco de dados e pode causar uma falha com um erro PACKET_TOO_LARGE. Defina max_allowed_packet como o valor máximo permitido de 1073741824:
max_allowed_packet = 1073741824
Além disso, defina os parâmetros padrão a seguir para usar UTF8mb4, que é compatível com os conjuntos de caracteres UTF8. Consulte o artigo No MySQL, nunca usar "utf8". Use "utf8mb4". para ver informações sobre 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
Nas instâncias do Amazon RDS, aplique essa configuração criando ou modificando um grupo de parâmetros e editando as configurações apropriadas. Recomendamos que você copie o grupo de parâmetros atual e faça as alterações 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.
Defina seu esquema de réplica
O Looker depende da funcionalidade que requer 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 banco de dados e usuário
Crie um usuário e um banco de dados na instância do banco de dados, substituindo <DB_username>, <DB_name> e <DB_password> pelos valores reais do usuário e do banco de dados. Substitua também <DB_charset> e <DB_collation> pelo conjunto de caracteres escolhido e a compilação que corresponda às configurações do grupo de parâmetros da instância do RDS. Para compatibilidade com UTF8 real, 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>'@'%';
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 de banco de dados
O Looker precisa saber com qual banco de dados do 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 para seu banco de dados:
dialect: mysql
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 qualquer outro parâmetro JDBC compatível com o Driver JDBC do Mariaaria adicionando jdbc_additional_params. Por exemplo, se você precisar usar um arquivo Trust Store específico, poderá adicionar o seguinte parâmetro à string de conexão do 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 ao seu banco de dados a 10, adicione o seguinte:
max_connections: 10
Recomendação de segurança: siga as práticas recomendadas de segurança ao salvar credenciais em um arquivo. O ideal é definir as permissões do arquivo
looker-db.ymlcomo 600, de propriedade da conta do Linux "user" 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 confidenciais no banco de dados são criptografados em repouso. Mesmo que alguém tenha acesso a credenciais de banco de dados de texto simples e acesse o banco de dados, o Looker criptografa ou gera hash de dados confidenciais antes do armazenamento. Isso se aplica a senhas, credenciais de análise de banco de dados, cache de consulta e assim por diante. No entanto, se você não quiser armazenar a senha do texto não criptografado para essa configuração no arquivo looker-db.yml no disco, configure a variável de ambiente LOOKER_DB para conter uma lista de chaves/valores para cada linha no arquivo looker-db.yml. Exemplo:
export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"
Recomendação de segurança: limite o uso da sua conta de usuário do MySQL ao endereço IP utilizado pelo servidor do Looker.
Faça 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 você 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, especialmente se o banco de dados do HyperSQL tiver 1 GB ou mais. Recomendamos que você faça o 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 aproximadamente 10 minutos.
- No host do Looker:
cd looker
./looker stop
vi looker
- No script de inicialização do Looker, crie uma segunda linha no arquivo:
exit
Interrompa a instância no Console da AWS. Quando ela for interrompida, altere o tamanho da instância do EC2 para
m5.2xlarge. Em seguida, reinicie a instância.SSH para o host como o usuário do Looker. Primeiro, confirme se o Java não está em execução. Depois, execute:
cd looker
java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data looker-db.yml
When running the `migrate_internal_data` step, `libcrypt` may not be found and a stack trace will appear, starting with this:
NotImplementedError: getppid unsupported or native support failed to load
ppid at org/jruby/RubyProcess.java:752
ppid at org/jruby/RubyProcess.java:749
If this happens, set the `LD_LIBRARY_PATH` manually before executing the Java command:
export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATH
Quando o processo for concluído, interrompa a instância no Console da AWS.
Agora você pode restaurar a instância para o tamanho original.
Inicie a instância novamente.
Iniciar o Looker
Edite o script de inicialização do Looker e exclua a linha
exitadicionada anteriormente.Verifique se não há argumentos definidos em
LOOKERARGSno script de inicialização. Em vez disso, os argumentos precisam ser movidos para o arquivolookerstart.cfgpara que não sejam substituídos por novas versões do script de inicialização. Salve e saia do script de inicialização.Editar
lookerstart.cfg. Aparecerá da seguinte maneira:
LOOKERARGS="-d looker-db.yml"
If there were any other arguments in the Looker startup script, add them to the `lookerstart.cfg` file.
- 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/
- Inicie 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ê verá conexões de rede entre a instância do Looker e a nova instância do banco de dados. Para verificar isso, execute o seguinte comando na instância do Looker:
netstat -na | grep 3306
Você verá algumas conexões com a instância do banco de dados. Veja abaixo um exemplo de saída que mostra 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
Fazendo backup do Looker
Depois de migrar para um back-end do MySQL, os backups automáticos de S3 do Looker não funcionarão mais. Recomendamos, pelo menos, backups noturnos do banco de dados MySQL com backups do sistema de arquivos noturnos 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 Como criar backups para ver mais informações.