Migra la base de datos de backend de Looker a MySQL

De forma predeterminada, Looker usa una base de datos en la memoria de HyperSQL para almacenar su configuración, los usuarios y otros datos. En una instancia con mucho tráfico, esta base de datos puede alcanzar gigabytes de tamaño, lo que puede generar problemas de rendimiento, presión de memoria en Java y tiempos de inicio prolongados.

Recomendamos que reemplaces 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 de tamaño. Para verificar el tamaño de la base de datos de HyperSQL, consulta el tamaño del archivo looker.script:

cd looker
cd .db
ls -lah

Si el archivo looker.script supera los 600 MB, sigue estos procedimientos para migrar a una base de datos externa de MySQL.

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 son compatibles con 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 esté 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.

Ajusta MySQL

El tamaño predeterminado max_allowed_packet 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

Además, establece 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 el uso de 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 esta 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 reiniciar.

Configura el esquema de réplica

Looker se basa en la funcionalidad que necesita un binlog mixed o row. Si alojas tu propia instancia de MySQL, configura binlog_format como mixed o row mediante 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> por 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 del grupo de parámetros de la instancia de RDS (para compatibilidad con UTF8 real, 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>'@'%';

La base de datos looker_tmp de la última línea no tiene que existir, pero la declaración grant es necesaria 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> con valores para 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 especificar cualquier otro parámetro JDBC adicional que admita el controlador JDBC de MariaDB agregando jdbc_additional_params. Por ejemplo, si necesitas usar un archivo específico de Trust Store, puedes agregar el siguiente parámetro a la string de conexión JDBC de MySQL:

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

En el caso de las instalaciones alojadas por el cliente, puedes especificar max_connections si quieres especificar la cantidad máxima de conexiones que puede establecer Looker con tu base de datos. Por ejemplo, para limitar a 10 la cantidad de conexiones simultáneas a tu base de datos, agrega lo siguiente:

max_connections: 10

Sugerencia de seguridad: Sigue las prácticas recomendadas de seguridad cuando guardes credenciales en un archivo. Lo ideal es que los permisos del archivo looker-db.yml estén 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.

En 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 bases de datos sin formato y a la base de datos, Looker encripta o genera un hash para datos sensibles antes de almacenarlos. Esto se aplica a las contraseñas, las credenciales de las bases de datos de estadísticas, la caché de consultas, etc. Sin embargo, si no deseas almacenar la contraseña de Cleartext para esta configuración en el archivo looker-db.yml en el disco, puedes configurar la variable de entorno LOOKER_DB a fin de que contenga una lista de pares clave-valor 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"

Recomendación de seguridad: 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 la 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 de forma temporal la instancia EC2 a m5.2xlarge (con 32 GB de RAM para permitir la pila de 26 GB especificada en los pasos) durante la migración, lo que reduce el tiempo requerido de aproximadamente 10 minutos.

  1. En el host de Looker:
    cd looker
    ./looker stop
    vi looker
  1. En la secuencia de comandos de inicio de Looker, cree una segunda línea nueva en el archivo:
    exit
  1. 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.

  2. Establecer una conexión SSH al host como usuario de Looker Primero, verifica que Java no esté en ejecución; luego, ejecuta lo siguiente:

    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
  1. Una vez que se complete de forma correcta, detén la instancia desde la consola de AWS.

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

  3. Vuelve a iniciar la instancia.

Iniciar 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 moverse 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"
If there were any other arguments in the Looker startup script, add them to the `lookerstart.cfg` file.
  1. 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/
  1. Inicia Looker:
    ./looker start

Verifica que Looker use 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 instancia de base de datos nueva. Para verificar esto, ejecute 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 de MySQL junto con copias de seguridad del sistema de archivos durante la noche del directorio de trabajo de Looker. El directorio looker/log/ puede excluirse de las copias de seguridad del sistema de archivos. Consulta la página de documentación Crea copias de seguridad para obtener más información.