Stai visualizzando la documentazione per Looker 22.16. La documentazione più recente è disponibile qui.

Migrazione del database di backend Looker a MySQL

Per impostazione predefinita, Looker utilizza un database in memoria HyperSQL per archiviare la configurazione, gli utenti e altri dati. Quando è attiva, questo database può raggiungere dimensioni di gigabyte e ciò può causare problemi di prestazioni, pressione della memoria Java e lunghi tempi di avvio.

Ti consigliamo di sostituire il database HyperSQL con un backend completo del database MySQL quando il database interno HyperSQL supera le dimensioni di 600 MB. Per controllare le dimensioni del database HyperSQL, visualizza le dimensioni del file looker.script:

cd looker
cd .db
ls -lah

Se il file looker.script supera i 600 MB, segui queste procedure per eseguire la migrazione a un database MySQL esterno.

Questa procedura presuppone un deployment in AWS EC2. Per i deployment locali, i sistemi dovrebbero avere una dimensione paragonabile a quella delle istanze AWS equivalenti.

I clienti che eseguono l'aggiornamento a Looker 6.6 o versioni successive da una versione precedente a Looker 6.6 non possono eseguire l'aggiornamento di Looker ed eseguire la migrazione a un database di backend MySQL contemporaneamente. Se stai aggiornando Looker ed esegui la migrazione a MySQL, ti consigliamo di completare l'aggiornamento di Looker prima di eseguire la migrazione a MySQL.

Esegui il provisioning di un'istanza MySQL

Eseguire il provisioning di un'istanza MySQL 8.0.x da utilizzare come backend. Looker supporta anche MySQL versione 5.7.x.

Le versioni di MySQL precedenti alla 5.7.x non sono supportate perché non supportano la codifica UTF8mb4.

In AWS RDS, un'istanza di classe db.m5.large è probabilmente sufficiente come backend per una singola istanza di Looker. Anche se l'utilizzo effettivo del database sarà probabilmente compreso nell'intervallo 5-10 GB, è buona norma eseguire il provisioning di 100-150 GB di spazio di archiviazione SSD perché il numero di IOPS di cui è stato eseguito il provisioning si basa sulla quantità di spazio di archiviazione richiesta.

Metti a punto MySQL

Le dimensioni predefinite di MySQL per il sistema max_allowed_packet sono troppo piccole per eseguire la migrazione del database e possono causare un errore della migrazione con un errore PACKET_TOO_LARGE. Imposta max_allowed_packet sul valore massimo consentito di 1073741824:

max_allowed_packet = 1073741824

Inoltre, imposta i seguenti parametri predefiniti per utilizzare UTF8mb4, che supporta i set di caratteri UTF8. Leggi l'articolo In MySQL, non utilizzare mai"utf8". Per saperne di più sui motivi per cui consigliamo di utilizzare UTF8mb4 e non UTF8 con MySQL, utilizza "utf8mb4"..

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

Sulle istanze Amazon RDS, puoi applicare questa impostazione creando o modificando un gruppo di parametri e modificando le impostazioni appropriate. Ti consigliamo di copiare il gruppo di parametri corrente e di apportare le modifiche nella copia, soprattutto se condividi gruppi di parametri in più istanze RDS. Dopo aver salvato il gruppo di parametri, applicalo all'istanza RDS. Potrebbe essere necessario riavviare.

Imposta lo schema di replica

Looker si basa su funzionalità che richiedono un binlog mixed o row. Se la tua istanza MySQL è ospitata, imposta binlog_format su mixed o row eseguendo uno dei seguenti comandi:

SET GLOBAL binlog_format = 'MIXED';

SET GLOBAL binlog_format = 'ROW';

Crea un database e un utente

Crea un utente e un database nell'istanza del database, sostituendo <DB_username>, <DB_name> e <DB_password> con i valori effettivi dell'utente e del database. Sostituisci anche <DB_charset> e <DB_collation> con il set di caratteri e il confronto selezionati che corrispondono alle impostazioni del gruppo di parametri dell'istanza RDS (per il supporto UTF8 reale, consigliamo 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>'@'%';

In realtà il database looker_tmp nell'ultima riga non deve esistere, ma l'istruzione grant è necessaria per i report interni.

Creare un file di credenziali del database

Looker deve sapere con quale database MySQL comunicare e quali credenziali utilizzare. Nella directory di Looker, crea un file denominato looker-db.yml con il seguente contenuto, sostituendo <DB_hostname>, <DB_username>, <DB_password> e <DB_name> con valori del tuo database:

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

Se il database MySQL richiede una connessione SSL, aggiungi la seguente riga a looker-db.yml:

ssl: true

Se vuoi attivare anche la verifica del certificato SSL, aggiungi la seguente riga a looker-db.yml:

verify_ssl: true

Facoltativamente, puoi specificare altri parametri JDBC aggiuntivi supportati dal driver JDBC MariaDB aggiungendo jdbc_additional_params. Ad esempio, se devi utilizzare un file specifico di Trust Store, puoi aggiungere il seguente parametro alla stringa di connessione MySQL JDBC:

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

Per le installazioni ospitate dal cliente, puoi facoltativamente specificare il numero massimo di connessioni che Looker può stabilire con il tuo database aggiungendo max_connections. Ad esempio, per limitare il numero di connessioni simultanee al database a 10, aggiungi quanto segue:

max_connections: 10

Consiglio sulla sicurezza: segui le best practice per la sicurezza quando salvi le credenziali in un file. Idealmente, imposta le autorizzazioni del file looker-db.yml su 600, di proprietà dell'account "user" di Linux, su cui viene eseguita l'applicazione Looker. Questo file non deve mai essere inserito in un repository Git.

Nello schema di crittografia di Looker, tutti i dati sensibili nel database sono criptati at-rest. Anche se qualcuno riuscisse ad accedere alle credenziali del database in testo non crittografato e ad accedere al database, Looker cripta o esegue l'hashing dei dati sensibili prima di archiviarli. Si applica a password, credenziali del database di analisi, cache di query e così via. Tuttavia, se non vuoi archiviare la password in chiaro per questa configurazione nel file looker-db.yml su disco, puoi configurare la variabile di ambiente LOOKER_DB in modo che contenga un elenco di chiavi/valori per ogni riga nel file looker-db.yml. Ad esempio:

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

Consiglio sulla sicurezza: limita l'uso del tuo account utente MySQL all'indirizzo IP utilizzato dal server Looker.

Esegui il backup della directory `.db`

Esegui il backup della directory .db, che contiene i file necessari per creare il database HyperSQL in memoria, nel caso in cui tu debba ripristinare HyperSQL:

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

Esegui la migrazione del database

La migrazione del database a MySQL può richiedere ore su un'istanza di medie o grandi dimensioni, soprattutto se il database HyperSQL è pari o superiore a 1 GB. Ti consigliamo di eseguire temporaneamente l'upgrade dell'istanza EC2 a una m5.2xlarge (con 32 GB di RAM per consentire l'heap di 26 GB specificati nei passaggi) durante la migrazione, in modo da ridurre il tempo necessario a circa 10 minuti.

Nell'host di Looker:

    cd looker
    ./looker stop
    vi looker

Nello script di avvio di Looker, crea una nuova seconda riga nel file:

    exit

Arresta l'istanza nella console AWS. Una volta interrotto, modifica le dimensioni dell'istanza EC2 in m5.2xlarge. Quindi riavvia l'istanza.
SSH all'host come utente Looker. Assicurati che Java non sia in esecuzione, quindi esegui:

    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

Al termine, arresta l'istanza dalla console AWS.
Ora puoi ripristinare le dimensioni originali dell'istanza.
Avvia di nuovo l'istanza.

Avvia Looker

Modifica lo script di avvio di Looker ed elimina la riga exit che hai aggiunto in precedenza.
Assicurati che non siano presenti argomenti definiti in LOOKERARGS nello script di avvio. Tuttavia, qualsiasi argomento deve essere spostato nel file lookerstart.cfg in modo che non venga sovrascritto da nuove versioni dello script di avvio. Salva ed esci dallo script di avvio.
Modifica lookerstart.cfg. La pagina dovrebbe essere simile alla seguente:

    LOOKERARGS="-d looker-db.yml"

If there were any other arguments in the Looker startup script, add them to the `lookerstart.cfg` file.

Archivia la directory .db, se non è già archiviata.

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

Avvia Looker:

    ./looker start

Verifica che Looker utilizzi il nuovo database

Se Looker utilizza correttamente il backend MySQL, dovresti vedere le connessioni di rete tra l'istanza di Looker e la nuova istanza di database. Per verificarlo, esegui il comando seguente sull'istanza di Looker:

netstat -na | grep 3306

Dovresti vedere alcune connessioni all'istanza di database. Di seguito è riportato un output di esempio che mostra un'istanza di database all'indirizzo 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

Backup di Looker

Dopo aver eseguito la migrazione a un backend MySQL, i backup S3 automatici di Looker non funzioneranno più. Consigliamo almeno dei backup notturni del database MySQL insieme ai backup del file system notturno della directory di lavoro di Looker. La directory looker/log/ potrebbe essere esclusa dai backup del file system. Per ulteriori informazioni, consulta la pagina della documentazione relativa alla creazione dei backup.