Migra la base de datos de backend de Looker a MySQL

De forma predeterminada, Looker usa una base de datos en memoria HyperSQL para almacenar la configuración, los usuarios y otros datos. En una instancia ocupada, esta base de datos puede crecer a gigabytes, lo que puede generar problemas de rendimiento, presión de la memoria en Java y tiempos de inicio prolongados.

Recomendamos que reemplace la base de datos de HyperSQL por un backend de base de datos de MySQL completo cuando la base de datos interna de HyperSQL supere los 600 MB. Para verificar el tamaño de la base de datos HyperSQL, consulta el tamaño del archivo looker.script:

cd looker
cd .db
ls -lah

Si el archivo looker.script tiene un tamaño superior a 600 MB, sigue estos procedimientos para migrar a una base de datos externa de MySQL.

Nota: En este procedimiento, se supone una implementación en AWS EC2. Para implementaciones locales, el tamaño de los sistemas debe ser similar al de las instancias de AWS equivalentes.

Los clientes que actualizan a Looker 6.6 o versiones posteriores desde una versión anterior a Looker 6.6 no pueden realizar la actualización de Looker y migrar a una base de datos de backend de MySQL al mismo tiempo. Si quieres actualizar Looker y migrar a MySQL, te recomendamos que completes la actualización de Looker antes de realizar la migración a MySQL.

Aprovisionar una instancia de MySQL

Aprovisionar una instancia de MySQL 8.0.x para usarla como backend Looker también es compatible con la versión 5.7.x de MySQL.

Las versiones de MySQL anteriores a 5.7.x no son compatibles porque no admiten la codificación UTF8mb4.

En AWS RDS, una instancia de la clase db.m5.large probablemente sea suficiente como backend para una sola instancia de Looker. Aunque es probable que el uso real de la base de datos sea entre 5 y 10 GB, se recomienda aprovisionar entre 100 y 150 GB de almacenamiento SSD, ya que las IOPS aprovisionadas se basan en la cantidad de almacenamiento solicitado.

MySQL 8.0.X: cómo cambiar el complemento de autenticación predeterminado

En MySQL 8.0.X, el complemento de autenticación predeterminado es caching_sha2_password. Looker usa el complemento mysql_native_password para intentar autenticarse en las bases de datos de MySQL a través del controlador JDBC. Para que esta versión de MySQL funcione correctamente, debes seguir estos pasos adicionales:

1. Configura la base de datos de MySQL para usar el complemento mysql_native_password. Esto se puede hacer de varias maneras y dependerá de cómo se implemente su base de datos de MySQL 8 y del tipo de acceso que tenga a la configuración:

   • Comienza el proceso con la marca --default-auth=mysql_native_password.

   • Establece la propiedad en el archivo de configuración my.cnf:

     [mysqld]
     default-authentication-plugin=mysql_native_password
     

   • Si tu instancia de base de datos está alojada a través de AWS RDS, configura el parámetro default_authentication_plugin a través de un grupo de parámetros de RDS que se aplique a esta instancia de base de datos.

2. Ejecuta las siguientes declaraciones y reemplaza some_password_here por una contraseña única y segura:

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

Ajustar MySQL

Ajusta la siguiente configuración en tu instancia de MySQL.

Aumentar el tamaño máximo del paquete

El tamaño max_allowed_packet predeterminado de MySQL es demasiado pequeño para la migración de la base de datos y puede hacer que la migración falle con un error PACKET_TOO_LARGE. Establece max_allowed_packet en el valor máximo permitido de 1073741824:

max_allowed_packet = 1073741824

Configurar el algoritmo de la tabla temporal

MySQL 8 controla las tablas temporales internas de manera diferente a las versiones anteriores. La configuración predeterminada puede causar problemas en la ejecución de algunas de las consultas necesarias para ejecutar Looker, en especial en el caso de las instancias de Looker con muchos usuarios y proyectos. La práctica recomendada es usar el algoritmo heredado interno de la tabla de MySQL 5.7 configurando la siguiente configuración global del servidor:

internal_tmp_mem_storage_engine = MEMORY

Configurar grupos de caracteres

Configura los siguientes parámetros predeterminados para usar UTF8mb4, que admite grupos de caracteres UTF8. Consulta el artículo En MySQL, nunca uses "utf8". Usa “utf8mb4” para obtener información sobre por qué recomendamos usar UTF8mb4, no UTF8, con 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 este parámetro de configuración en las instancias de Amazon RDS, debe crear o modificar un grupo de parámetros y editar la configuración adecuada. Le recomendamos que copie el grupo de parámetros actual y realice los cambios en la copia, especialmente si comparte grupos de parámetros en varias instancias de RDS. Después de guardar el grupo de parámetros, aplícalo a la instancia de RDS. Es posible que debas reiniciarlo.

Configura el esquema de réplica

Looker se basa en la funcionalidad que requiere un binlog mixed o row. Si alojas tu propia instancia de MySQL, configura tu binlog_format como mixed o row mediante la emisión de uno de los siguientes comandos:

SET GLOBAL binlog_format = 'MIXED';

o

SET GLOBAL binlog_format = 'ROW';

Crea una base de datos y un usuario

Crea un usuario y una base de datos en la instancia de base de datos y reemplaza <DB_username>, <DB_name> y <DB_password> con los valores reales para el usuario y la base de datos. También reemplaza <DB_charset> y <DB_collation> por el grupo de caracteres y la intercalación elegidos que coincidan con la configuración de grupo de parámetros de instancia de RDS (para compatibilidad con UTF8, recomendamos utf8mb4 y 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>'@'%';

No es necesario que la base de datos looker_tmp de la última línea exista, pero se necesita la sentencia grant para los informes internos.

Crea un archivo de credenciales de la base de datos

Looker necesita saber con qué base de datos MySQL comunicarse y qué credenciales usar. En el directorio de Looker, crea un archivo llamado looker-db.yml con el siguiente contenido y reemplaza <DB_hostname>, <DB_username>, <DB_password> y <DB_name> por los valores de tu base de datos:

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

Si tu base de datos MySQL requiere una conexión SSL, agrega la siguiente línea a looker-db.yml:

ssl: true

Si también deseas habilitar la verificación del certificado SSL, agrega la siguiente línea a looker-db.yml:

verify_ssl: true

De manera opcional, también puedes agregar jdbc_additional_params para especificar cualquier otro parámetro JDBC adicional que sea compatible con el controlador JDBC de MariaDB. Por ejemplo, si necesita usar un archivo específico de Trust Store, puede agregar el siguiente parámetro a la string de conexión de JDBC de MySQL:

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

Para las instalaciones alojadas por el cliente, tienes la opción de especificar la cantidad máxima de conexiones que puede establecer Looker con tu base de datos agregando max_connections. Por ejemplo, para limitar a 10 la cantidad de conexiones simultáneas a tu base de datos, agrega lo siguiente:

max_connections: 10

Importante: Sigue las prácticas recomendadas de seguridad cuando guardes credenciales en un archivo. Lo ideal es establecer los permisos del archivo looker-db.yml en 600, propiedad de la cuenta de “usuario” de Linux en la que se ejecuta la aplicación de Looker. Este archivo nunca debe registrarse en un repositorio de Git.

Según el esquema de encriptación de Looker, todos los datos sensibles de la base de datos se encriptan en reposo. Incluso si alguien obtuviera acceso a las credenciales de la base de datos de texto sin formato y a la base de datos, Looker encripta o genera un hash de los datos sensibles antes de almacenarlos. Esto se aplica a contraseñas, credenciales de bases de datos de estadísticas, caché de consultas, etcétera. Sin embargo, si no deseas almacenar la contraseña de texto simple para esta configuración en el archivo looker-db.yml del disco, puedes configurar la variable de entorno LOOKER_DB a fin de que contenga una lista de claves/valores para cada línea en el archivo looker-db.yml. Por ejemplo:

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

Importante: Limita el uso de tu cuenta de usuario de MySQL a la dirección IP que usa tu servidor de Looker.

Crea una copia de seguridad del directorio .db

Crea una copia de seguridad del directorio .db, que contiene los archivos necesarios para compilar la base de datos de HyperSQL en memoria, en caso de que necesites restablecer HyperSQL:

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

Migra la base de datos

La migración de la base de datos a MySQL puede llevar horas en una instancia mediana o grande, en especial si la base de datos de HyperSQL es de 1 GB o más. Te recomendamos que actualices temporalmente la instancia EC2 a m5.2xlarge (con 32 GB de RAM para permitir el montón de 26 GB especificado en los pasos) durante la migración, lo que reduce el tiempo requerido de unos 10 minutos.

1. En el host de Looker, haz lo siguiente:

   cd looker
   ./looker stop
   vi looker
   

2. En la secuencia de comandos de inicio de Looker, cree una segunda línea nueva en el archivo:

   exit
   

3. Detén la instancia en la consola de AWS. Una vez que se detenga, cambia el tamaño de la instancia de EC2 a m5.2xlarge. Luego, vuelve a iniciar la instancia.

4. Establece una conexión SSH al host como usuario de Looker. Primero, asegúrese de que Java no esté en ejecución. Luego, ejecute lo siguiente:

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

   Cuando ejecutes el paso migrate_internal_data, es posible que no se encuentre libcrypt y aparezca un seguimiento de pila que comience con lo siguiente:

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

   Si esto sucede, configura el LD_LIBRARY_PATH de forma manual antes de ejecutar el comando de Java:

   export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATH
   

5. Una vez que se complete de forma correcta, detenga la instancia desde la consola de AWS.

6. Ahora puedes restablecer la instancia a su tamaño original.

7. Vuelve a iniciar la instancia.

Inicia Looker

1. Edita la secuencia de comandos de inicio de Looker y borra la línea exit que agregaste antes.

2. Asegúrate de que no haya argumentos definidos en LOOKERARGS en la secuencia de comandos de inicio. En cambio, cualquier argumento debe pasar al archivo lookerstart.cfg para que no se reemplacen por versiones nuevas de la secuencia de comandos de inicio. Guarda la secuencia de comandos de inicio y sal de ella.

3. Editar lookerstart.cfg. El resultado debería ser similar al siguiente:

   LOOKERARGS="-d looker-db.yml"
   

   Si había otros argumentos en la secuencia de comandos de inicio de Looker, agrégalos al archivo lookerstart.cfg.

4. Archiva el directorio .db si aún no lo hiciste.

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

5. Inicia Looker:

   ./looker start
   

Verifica que Looker esté usando la base de datos nueva

Si Looker usa correctamente el backend de MySQL, debería ver conexiones de red entre la instancia de Looker y la nueva instancia de base de datos. Para verificar esto, ejecuta el siguiente comando en la instancia de Looker:

netstat -na | grep 3306

Debería ver algunas conexiones a la instancia de la base de datos. A continuación, se muestra un resultado de muestra que muestra una instancia de base de datos en la dirección 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

Crea una copia de seguridad de Looker

Después de migrar a un backend de MySQL, las copias de seguridad automáticas de S3 de Looker dejarán de funcionar. Recomendamos al menos copias de seguridad nocturnas de la base de datos MySQL junto con copias de seguridad del sistema de archivos todas las noches del directorio de trabajo de Looker. Es posible que el directorio looker/log/ se excluya de las copias de seguridad del sistema de archivos. Consulta la página de documentación sobre cómo crear copias de seguridad para obtener más información.