De forma predeterminada, Looker usa una base de datos en memoria HyperSQL para almacenar su configuración, usuarios y otros datos. En una instancia con mucha actividad, esta base de datos puede crecer hasta alcanzar varios gigabytes, lo que puede generar problemas de rendimiento, presión de memoria de Java y tiempos de inicio prolongados.
En una instancia alojada por el cliente, te 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 los procedimientos que se indican a continuación para migrar a una base de datos externa de MySQL.
Aprovisiona una instancia y un usuario de MySQL
Puedes aprovisionar una instancia de MySQL 8.4.X (recomendada) o MySQL 8.0.X para usarla como backend. No se admiten las versiones de MySQL anteriores a la 8.0.
Looker 26.6 y versiones posteriores admiten MySQL 8.4.X para la base de datos de backend de Looker. En el caso de las instancias alojadas por el cliente que usan MySQL 8.0.X para la base de datos de backend de Looker, se recomienda que actualices a MySQL 8.4.X tan pronto como actualices tu instancia de Looker a la versión 26.6 o posterior.
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 se encuentre en el rango de 5 a 10 GB, es una buena idea aprovisionar entre 100 y 150 GB de almacenamiento SSD, ya que el IOPS aprovisionado se basa en la cantidad de almacenamiento solicitada.
MySQL 8.4.X
A partir de la versión 26.6, Looker admite el uso de MySQL 8.4.X como base de datos interna. Para MySQL 8.4.X, puedes usar cualquiera de los siguientes complementos de autenticación de MySQL, como se describe en las siguientes secciones:
Usa caching_sha2_password
En MySQL 8.4.X, el complemento de autenticación predeterminado es caching_sha2_password. Looker proporciona dos formas de usar el complemento caching_sha2_password:
- Cuando se usa una conexión SSL para la base de datos interna: No se necesita una clave pública RSA. Looker se conecta de forma segura a la base de datos con las credenciales de usuario proporcionadas. Consulta la sección Crea un archivo de credenciales de la base de datos en esta página para configurar una conexión SSL a tu base de datos.
- Si no te conectas con SSL habilitado: De forma predeterminada, Looker usa la opción
--get-server-public-keypara conectarse a la base de datos interna cuando la cuenta de usuario proporcionada a Looker usa el complementocaching_sha2_password. Asegúrate de que el entorno de red esté protegido si SSL no está habilitado.
Para usar el complemento caching_sha2_password de cualquier manera, configura el usuario con la siguiente instrucción:
CREATE USER 'DB_username' IDENTIFIED WITH caching_sha2_password BY 'password';
Reemplaza lo siguiente:
- DB_username: nombre de usuario
- password: Contraseña segura y única
Usa mysql_native_password
Looker funciona con el complemento mysql_native_password para autenticarse en bases de datos de MySQL a través del controlador JDBC. Para que MySQL 8.4.X funcione con el complemento mysql_native_password, debes seguir estos pasos adicionales:
Configura la base de datos de MySQL para habilitar el complemento
mysql_native_password. Esto se puede hacer de varias maneras, según cómo se implemente tu base de datos de MySQL y qué tipo de acceso tengas a la configuración:- Inicia el servidor de MySQL con
--mysql-native-password=ON. Establece la propiedad en el archivo de configuración
my.cnf:[mysqld] mysql_native_password=ONSi la instancia de MySQL está alojada en Google Cloud, AWS o Azure, el complemento
mysql_native_passworddebería habilitarse automáticamente. Consulta la documentación de tu proveedor para obtener instrucciones detalladas.
- Inicia el servidor de MySQL con
Crea el usuario:
CREATE USER 'DB_username' IDENTIFIED WITH mysql_native_password BY 'password';Reemplaza lo siguiente:
- DB_username: nombre de usuario
- password: Contraseña segura y única
MySQL 8.0.X
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 MySQL 8.0.X funcione correctamente, debes seguir estos pasos adicionales:
Configura la base de datos de MySQL para que use el complemento
mysql_native_password. Esto se puede hacer de varias maneras y dependerá de cómo se implemente tu base de datos de MySQL 8 y del tipo de acceso que tengas a la configuración:Inicia 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_passwordSi tu instancia de base de datos está alojada a través de AWS RDS, configura el parámetro
default_authentication_plugina través de un grupo de parámetros de RDS que se aplique a esta instancia de base de datos.
Crea el usuario:
CREATE USER 'DB_username' IDENTIFIED WITH mysql_native_password BY 'password';Reemplaza lo siguiente:
- DB_username: nombre de usuario
- password: Contraseña segura y única
Ajusta MySQL
Ajusta la siguiente configuración en tu instancia de MySQL.
Aumenta el tamaño máximo del paquete
El tamaño predeterminado de max_allowed_packet de MySQL es demasiado pequeño para la migración de bases de datos y puede provocar 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
Establece 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 al ejecutar algunas de las consultas necesarias para que se ejecute Looker, en especial para las instancias de Looker con muchos usuarios y proyectos. La práctica recomendada es establecer el siguiente parámetro de configuración global del servidor:
internal_tmp_mem_storage_engine = MEMORY
Configura grupos de caracteres
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 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
En las instancias de Amazon RDS, puedes aplicar este parámetro de configuración creando o modificando un grupo de parámetros y editando los parámetros de configuración correspondientes. Te recomendamos que copies el grupo de parámetros actual y realices los cambios en la copia, en especial si compartes 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 el dispositivo.
Establece tu esquema de réplicas
Looker depende de una funcionalidad que requiere un registro binario mixed o row. Si alojas tu propia instancia de MySQL, configura tu binlog_format como mixed o row con uno de los siguientes comandos:
SET GLOBAL binlog_format = 'MIXED';
o
SET GLOBAL binlog_format = 'ROW';
Crea una base de datos y otorga permiso de usuario
Crea una base de datos en la instancia de base de datos:
create database DB_name default character set DB_charset default collate DB_collation;
Luego, otorga permisos al usuario que creaste cuando aprovisionaste la instancia y el usuario de MySQL:
grant all on DB_name.* to 'DB_username'@'%';
grant all on looker_tmp.* to 'DB_username'@'%';
Reemplaza lo siguiente:
- DB_name: Nombre de la base de datos
- DB_charset: Es el grupo de caracteres que coincide con la configuración del grupo de parámetros de la instancia de RDS (para una verdadera compatibilidad con UTF8, recomendamos
utf8mb4). - DB_collation: Es la intercalación que coincide con la configuración del grupo de parámetros de la instancia de RDS (para una compatibilidad real con UTF8, recomendamos
utf8mb4_general_ci). - DB_username: nombre de usuario
La base de datos looker_tmp de la última línea no tiene que existir, pero la instrucció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 de 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_8
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 quieres 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 adicional de JDBC que admita el controlador JDBC de MariaDB agregando jdbc_additional_params. Por ejemplo, si necesitas usar un archivo de almacén de confianza específico, puedes agregar el siguiente parámetro a la cadena de conexión de 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 de forma opcional la cantidad máxima de conexiones que Looker puede establecer con tu base de datos agregando max_connections. Por ejemplo, para limitar la cantidad de conexiones simultáneas a tu base de datos a 10, agrega lo siguiente:
max_connections: 10
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 simple y accediera a la base de datos, Looker encripta o genera un hash de los datos sensibles antes de almacenarlos. Esto se aplica a elementos como contraseñas, credenciales de bases de datos de Analytics y caché de consultas. 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 para que contenga una lista de claves y valores para cada línea del archivo looker-db.yml. Por ejemplo:
export LOOKER_DB="dialect=mysql_8&host=localhost&username=root&password=&database=looker&port=3306"
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 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 tardar 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 de EC2 a una m5.2xlarge (con 32 GB de RAM para permitir el heap de 26 GB especificado en los pasos) durante la migración, lo que reduce el tiempo necesario a unos 10 minutos.
En el host de Looker, haz lo siguiente:
cd looker ./looker stop vi lookerEn la secuencia de comandos de inicio de Looker, crea una segunda línea nueva en el archivo:
exitDeté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.Establece una conexión SSH con el host como usuario de Looker. Primero, asegúrate de que Java no se esté ejecutando y, luego, ejecuta lo siguiente:
cd looker java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data looker-db.ymlCuando ejecutes el paso
migrate_internal_data, es posible que no se encuentrelibcrypty que aparezca un seguimiento de pila, que comienza 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:749Si esto sucede, configura
LD_LIBRARY_PATHde forma manual antes de ejecutar el comando de Java:export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATHUna vez que se complete correctamente, detén la instancia desde la consola de AWS.
Ahora puedes restablecer la instancia a su tamaño original.
Reiniciar la instancia.
Inicia Looker
Edita la secuencia de comandos de inicio de Looker y borra la línea
exitque agregaste antes.Asegúrate de que no haya argumentos definidos en
LOOKERARGSen la secuencia de comandos de inicio. En cambio, todos los argumentos deben trasladarse al archivolookerstart.cfgpara que las versiones nuevas de la secuencia de comandos de inicio no los sobrescriban. Guarda y sal de la secuencia de comandos de inicio.Editar
lookerstart.cfg. El resultado debería ser similar al siguiente:LOOKERARGS="-d looker-db.yml"Si hubiera otros argumentos en la secuencia de comandos de inicio de Looker, agrégalos al archivo
lookerstart.cfg.Archiva el directorio
.dbsi aún no lo hiciste.mv .db .db-backup tar -zcvf db-backup.tar.gz ./.db-backup rm -rf ./.db-backup/Inicia Looker:
./looker start
Verifica que Looker use la nueva base de datos
Si Looker usa correctamente el backend de MySQL, deberías ver conexiones de red entre la instancia de Looker y la nueva instancia de la base de datos. Para verificarlo, ejecuta el siguiente comando en la instancia de Looker:
netstat -na | grep 3306
Deberías ver algunas conexiones a la instancia de la base de datos. A continuación, se muestra un ejemplo de resultado que muestra una instancia de la 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
Copia de seguridad de Looker
Después de migrar a un backend de MySQL, las copias de seguridad automatizadas de S3 de Looker ya no funcionarán. Recomendamos que se realicen copias de seguridad de la base de datos de MySQL al menos todas las noches, junto con copias de seguridad del sistema de archivos 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 Cómo crear copias de seguridad para obtener más información.