Por padrão, o Looker usa um banco de dados na memória HyperSQL para armazenar configurações, usuários e outros dados. Em uma instância ocupada, esse banco de dados pode atingir gigabytes de tamanho, o que pode levar a 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 quando o banco de dados HyperSQL interno exceder 600 MB. Para verificar o tamanho do banco de dados do 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.
Provisionar uma instância do MySQL
Provisione 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 compatíveis.
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 seja de 5 a 10 GB, é recomendável provisionar de 100 a 150 GB de armazenamento SSD, porque as IOPS provisionadas são baseadas na quantidade de armazenamento solicitada.
MySQL 8.0.X: alteração do plug-in de autenticação padrão
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 se autenticar nos bancos de dados MySQL por meio do driver JDBC. Para que essa versão do MySQL funcione corretamente,
é preciso seguir as seguintes etapas:
Configure o banco de dados MySQL para usar o plug-in
mysql_native_password
. Isso pode ser feito de várias maneiras e vai depender de como seu banco de dados MySQL 8 está 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 por meio do AWS RDS, defina o parâmetro
default_authentication_plugin
por meio de um grupo de parâmetros do RDS aplicado a essa instância do banco de dados.
Emita as seguintes instruções, substituindo
some_password_here
por uma senha exclusiva e segura:CREATE USER looker IDENTIFIED WITH mysql_native_password BY 'some_password_here'; GRANT SELECT ON database_name.* TO 'looker'@'%';
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 de max_allowed_packet
do MySQL é muito pequeno para a migração de banco de dados e pode fazer com que a migração falhe com um erro PACKET_TOO_LARGE
. Defina max_allowed_packet
com o valor máximo permitido de 1073741824
:
max_allowed_packet = 1073741824
Definir algoritmo de tabela temporária
O MySQL 8 lida com tabelas temporárias internas de maneira diferente das versões anteriores. As configurações padrão podem causar problemas na execução de algumas 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 de servidor global:
internal_tmp_mem_storage_engine = MEMORY
Configurar conjuntos de caracteres
Defina os parâmetros padrão a seguir 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 (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, você aplica 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 mudanças na cópia, principalmente se você estiver compartilhando grupos de parâmetros entre várias instâncias de RDS. Depois de salvar o grupo de parâmetros, aplique-o à instância do RDS. Pode ser necessário reinicializar o dispositivo.
Definir o esquema de réplica
O Looker depende de uma funcionalidade que exige um binlog mixed
ou row
. Se você estiver hospedando sua própria instância do MySQL, defina binlog_format
como mixed
ou row
emitindo um dos seguintes comandos:
SET GLOBAL binlog_format = 'MIXED';
ou
SET GLOBAL binlog_format = 'ROW';
Criar um banco de dados e um 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. Além disso, substitua <DB_charset>
e <DB_collation>
pelo conjunto de caracteres e a ordenação escolhidos que correspondam às configurações do grupo de parâmetros da instância do RDS. Para suporte real a 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>'@'%';
O banco de dados looker_tmp
na última linha não precisa existir de fato, mas a instrução grant
é necessária para a geração de relatórios internos.
Criar um arquivo de credenciais de 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 conteúdo a seguir, substituindo <DB_hostname>
, <DB_username>
, <DB_password>
e <DB_name>
pelos valores do 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 outros parâmetros JDBC compatíveis com o driver JDBC MariaDB (em inglês) adicionando jdbc_additional_params
. Por exemplo, se você precisar usar um arquivo específico do Trust Store, 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 ao seu banco de dados a 10, adicione o seguinte:
max_connections: 10
De acordo com o esquema de criptografia do Looker, todos os dados sensíveis no banco de dados são criptografados em repouso. Mesmo que alguém tenha acesso a credenciais de banco de dados em texto simples e acesse o banco de dados, o Looker criptografa ou gera hash de dados sensíveis antes de armazenar. Isso se aplica a senhas, credenciais de bancos de dados de análise, cache de consultas e assim por diante. No entanto, se você não quiser armazenar a senha de texto não criptografado para essa configuração no arquivo looker-db.yml
em 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"
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 do 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, especialmente se o banco de dados do hiperSQL tiver 1 GB ou mais. Recomendamos que você faça upgrade temporariamente da instância do EC2 para uma m5.2xlarge
(com 32 GB de RAM para permitir os 26 GB de heap especificados nas etapas) durante a migração, o que reduz o tempo necessário para cerca de 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 parar, mude o tamanho da instância do EC2 para
m5.2xlarge
. Em seguida, inicie a instância de backup novamente.SSH para o host como o usuário do Looker. Primeiro, verifique 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
Ao executar a etapa
migrate_internal_data
, talvez não seja possível encontrarlibcrypt
, e um stack trace vai aparecer, 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 isso acontecer, defina
LD_LIBRARY_PATH
manualmente antes de executar o comando Java:export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATH
Depois que 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
exit
que você adicionou anteriormente.Verifique se não há argumentos definidos em
LOOKERARGS
no script de inicialização. Em vez disso, os argumentos precisam ser movidos para o arquivolookerstart.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.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
.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 automatizados do S3 do Looker não vão mais funcionar. Recomendamos que você faça backups do banco de dados MySQL pelo menos todas as noites, além de backups 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.