Você está visualizando a documentação do Looker. Para conferir a documentação do Looker Studio, acesse https://support.google.com/looker-studio.

Como migrar o banco de dados do back-end do Looker para o MySQL

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

Recomendamos que você substitua o banco de dados do HyperSQL por um back-end completo quando ele tiver mais de 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.

Provisionar uma instância do MySQL

Provisionar uma instância do MySQL 8.0.x para usar como back-end. O Looker também é compatível com o MySQL versão 5.7.x.

As versões do MySQL anteriores à 5.7.x não são compatíveis porque não são compatíveis com a 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 provavelmente na faixa de 5 a 10 GB, é uma boa ideia provisionar de 100 a 150 GB de armazenamento SSD, pois as IOPS provisionadas são baseadas na quantidade de armazenamento solicitada.

MySQL 8.0.X: como alterar o 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 do MySQL por meio do driver JDBC. Para que essa versão do MySQL funcione corretamente, siga estas etapas adicionais:

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 de qual tipo de acesso você tem à configuração:
- Inicie o processo com a sinalização --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 por meio de um grupo de parâmetros do RDS aplicado a essa instância.

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 MySQL

Ajuste as configurações a seguir 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 como o valor máximo permitido de 1073741824:

max_allowed_packet = 1073741824

Definir algoritmo de tabela temporário

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 a execução do Looker, principalmente em instâncias do Looker com muitos usuários e projetos. A prática recomendada é usar o algoritmo legado de tabela temporária interna do MySQL 5.7 definindo 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 informações sobre por que recomendamos o uso de UTF8mb4, e não UTF8, com 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

Para aplicar essa configuração em instâncias do Amazon RDS, crie ou modifique um grupo de parâmetros e edite 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 de RDS. Depois de salvar o grupo de parâmetros, aplique-o à instância do RDS. Talvez seja necessário reinicializar.

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 emitindo um dos seguintes comandos:

SET GLOBAL binlog_format = 'MIXED';

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. Substitua também <DB_charset> e <DB_collation> pelo conjunto de caracteres escolhido e pelo agrupamento que corresponda às configurações do grupo de parâmetros da instância RDS. Para compatibilidade com UTF8 verdadeiro, 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 do banco de dados

O Looker precisa saber com qual banco de dados do MySQL conversar 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

Como opção, também é possível especificar qualquer outro parâmetro JDBC compatível com o MariaDB Driver JDBC 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 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

No esquema de criptografia do Looker, todos os dados confidenciais no banco de dados são criptografados em repouso. Mesmo que alguém ganhe 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 banco de dados de análise, cache de consulta e outros. No entanto, se você não quiser armazenar a senha de 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"

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 você precise restaurá-lo:

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 fazer 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.

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, inicie a instância novamente.
Conecte-se por SSH ao host como 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 libcrypt não seja encontrado, e um stack trace será exibido, 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
```
Depois que isso for concluído, interrompa a instância no console da AWS.
Agora é possível 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 adicionada 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 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.
Editar lookerstart.cfg. Aparecerá da seguinte maneira:
```
LOOKERARGS="-d looker-db.yml"
```
Se houver algum outro argumento no script de inicialização do Looker, adicione-o 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á as 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

Como fazer backup do Looker

Depois de migrar para um back-end do MySQL, os backups automatizados do S3 do Looker não funcionarão mais. Recomendamos pelo menos os backups noturnos do banco de dados MySQL com os 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 de documentação Como criar backups para mais informações.