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

Esta página foi traduzida pela API Cloud Translation.

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 movimentada, esse banco de dados pode chegar a gigabytes de tamanho, o que pode levar a problemas de desempenho, pressão de memória do Java e longos tempos de inicialização.

Em uma instância hospedada pelo cliente, recomendamos que você substitua o banco de dados HyperSQL por um back-end de banco de dados MySQL completo 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 tiver mais de 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. Não há suporte para versões do MySQL anteriores à 8.0.

No AWS RDS, 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 entre 5 e 10 GB, é recomendável provisionar de 100 a 150 GB de armazenamento SSD, porque os IOPS provisionados são baseados na quantidade de armazenamento solicitada.

MySQL 8.0.X: como mudar 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 autenticar-se nos bancos de dados MySQL pelo driver JDBC. Para que essa versão do MySQL funcione corretamente, faça o seguinte:

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 for hospedada pelo AWS RDS, defina o parâmetro default_authentication_plugin com 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 o MySQL

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

Aumentar o tamanho máximo do pacote

O tamanho padrão do max_allowed_packet do MySQL é muito pequeno para a migração de banco de dados e pode causar a falha da migração 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á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 a execução do Looker, especialmente em instâncias com muitos usuários e projetos. A prática recomendada é definir a seguinte configuração do servidor global:

internal_tmp_mem_storage_engine = MEMORY

Configurar conjuntos de caracteres

Defina os parâmetros padrão a seguir para usar UTF8mb4, que oferece suporte a 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, 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, especialmente se você 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. Pode ser necessário reinicializar.

Defina seu esquema de réplica

O Looker depende de uma 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 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 de 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 e ordenação escolhido que corresponde às configurações do grupo de parâmetros da instância do RDS. Para suporte real ao 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, 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> pelos valores do 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

Você também pode especificar outros parâmetros JDBC compatíveis com o driver JDBC MariaDB 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, você tem a opção de 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 banco de dados a 10, adicione o seguinte:

max_connections: 10

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 ao banco de dados, o Looker criptografa ou gera hash de dados sensíveis antes do armazenamento. Isso se aplica a senhas, credenciais do banco de dados de análise, cache de consulta e assim por diante. No entanto, se você não quiser armazenar a senha em texto simples 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"

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 seja necessário 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 HyperSQL tiver 1 GB ou mais. Recomendamos que você faça upgrade temporário da instância do EC2 para uma m5.2xlarge (com 32 GB de RAM para permitir a pilha de 26 GB especificada 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
```
Pare a instância no console da AWS. Quando ela for interrompida, mude o tamanho da instância do EC2 para m5.2xlarge. Em seguida, inicie o backup da instância novamente.
Estabeleça conexão SSH com o host como usuário do Looker. Primeiro, verifique se o Java não está em execução e depois execute:
```
cd looker
java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data  looker-db.yml
```
Ao executar a etapa migrate_internal_data, o libcrypt pode não ser encontrado e um stack trace vai aparecer, começando com este:
```
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 disso, interrompa a instância no console da AWS.
Agora é possível restaurar a instância para o tamanho original.
Iniciar 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, todos os argumentos precisam ser movidos para o arquivo lookerstart.cfg (link em inglês) 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/

Iniciar o Looker:
```
./looker start
```

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

Se o Looker usar 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

Algumas conexões com a instância do banco de dados vão aparecer. Veja 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 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.