デフォルトでは、Looker は HyperSQL のインメモリ データベースを使用し、構成やユーザーなどのデータを保存しています。ビジー状態のインスタンスでは、このデータベースのサイズはギガバイトまで大きくなる可能性があり、パフォーマンスの問題、Java のメモリ圧縮、起動時間が長くなる可能性があります。
お客様がホストするインスタンスでは、内部 HyperSQL データベースのサイズが 600 MB を超える場合は、HyperSQL データベースを完全な MySQL データベース バックエンドに置き換えることをおすすめします。HyperSQL データベースのサイズを確認するには、looker.script ファイルのサイズを表示します。
cd looker
cd .db
ls -lah
looker.script ファイルのサイズが 600 MB を超える場合は、次の手順で外部 MySQL データベースに移行します。
MySQL インスタンスをプロビジョニングする
バックエンドとして使用する MySQL 8.0.x インスタンスをプロビジョニングします。8.0 より前の MySQL バージョンはサポートされていません。
AWS RDS では、単一 Looker インスタンスのバックエンドとしてクラス db.m5.large のインスタンスで十分と思われます。データベースの実際の使用量は 5 ～ 10 GB の範囲になる模様ですが、プロビジョニングされる IOPS は要求されたストレージの量に基づいているため、100 ～ 150 GB の SSD ストレージをプロビジョニングすることをおすすめします。
MySQL 8.0.X - デフォルトの認証プラグインの変更
MySQL 8.0.X では、デフォルトの認証プラグインは caching_sha2_password です。Looker は、mysql_native_password プラグインを使用して、JDBC ドライバを介して MySQL データベースに対する認証を試みます。このバージョンの MySQL を正しく機能させるには、追加の手順を行う必要があります。
mysql_native_passwordプラグインを使用するように MySQL データベースを構成します。これは複数の方法で実行できます。どの方法を使用するかは、MySQL 8データべースのデプロイ方法と、構成へのアクセスのタイプによって決まります。--default-auth=mysql_native_passwordフラグでプロセスを開始するmy.cnf構成ファイルのプロパティを設定します。[mysqld] default-authentication-plugin=mysql_native_passwordデータベース インスタンスが AWS RDS を介してホストされている場合、このデータベース インスタンスに適用される RDS パラメータ グループを介して
default_authentication_pluginパラメータを設定します。
次のステートメントを発行します。
some_password_hereを独自のセキュアなパスワードに変更して発行します。CREATE USER looker IDENTIFIED WITH mysql_native_password BY 'some_password_here'; GRANT SELECT ON database_name.* TO 'looker'@'%';
MySQL を調整する
MySQL インスタンスで次の設定を調整します。
最大パケットサイズを増やす
MySQL のデフォルトの max_allowed_packet サイズはデータベースの移行には小さすぎるため、PACKET_TOO_LARGE エラーで移行が失敗する可能性があります。max_allowed_packet を 1073741824 の最大許容値に設定します。
max_allowed_packet = 1073741824
一時テーブル アルゴリズムを設定する
MySQL 8 では、以前のバージョンと異なる内部一時テーブルの処理が行われます。デフォルト設定では、Looker の実行に必要な一部のクエリ（特に多数のユーザーとプロジェクトが存在する Looker インスタンス）の実行で問題が発生する可能性があります。次のグローバル サーバー設定をおすすめします。
internal_tmp_mem_storage_engine = MEMORY
文字セットの構成
UTF8 文字セットをサポートする UTF8mb4 を使用するように、次のデフォルト パラメータを設定します。記事を見るMySQL で「utf8」を使用しないでください。MySQL で UTF8 ではなく UTF8mb4 を使用することをおすすめします。その理由については「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
Amazon RDS インスタンスでは、パラメータ グループを作成または変更して、適切な設定を編集して、この設定を適用します。特に複数の RDS インスタンス間でパラメータ グループを共有している場合は、現在のパラメータ グループをコピーして、変更を行うことをおすすめします。パラメータ グループを保存したら、RDS インスタンスに適用します。再起動が必要になる場合があります。
レプリカ スキームを設定する
Looker は、mixed または row のバイナリログが必要な機能に依存しています。独自の MySQL インスタンスをホストする場合は、次のいずれかのコマンドを発行して、binlog_format を mixed または row に設定します。
SET GLOBAL binlog_format = 'MIXED';
または
SET GLOBAL binlog_format = 'ROW';
データベースとユーザーを作成する
データベース インスタンスにユーザーとデータベースを作成します。<DB_username>、<DB_name>、<DB_password> は、ユーザーとデータベースの実際の値に置き換えます。また、<DB_charset> と <DB_collation> は、RDS インスタンス パラメータ グループの設定に一致する選択した文字セットと照合に置き換えます（真 UTF8 をサポートする場合は、utf8mb4 と 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>'@'%';
最後の行の looker_tmp データベースは、実際には存在しなくてもかまいませんが、内部レポートでは grant ステートメントが必要です。
データベース認証情報ファイルを作成する
Looker では、どの MySQL データベースと通信してどの認証情報を使用するかを知っている必要がある。Looker ディレクトリで、<DB_hostname>、<DB_username>、<DB_password>、<DB_name> を実際のデータベースの値に置き換えて、looker-db.yml という名前のファイルを作成します。
dialect: mysql
host: <DB_hostname>
username: <DB_username>
password: <DB_password>
database: <DB_name>
port: 3306
MySQL データベースで SSL 接続が必要な場合は、次の行を looker-db.yml に追加します。
ssl: true
SSL 証明書の検証を有効にする場合は、looker-db.yml に次の行を追加します。
verify_ssl: true
jdbc_additional_params を追加することで、MariaDB JDBC ドライバでサポートされているその他の JDBC パラメータを指定することもできます。たとえば、特定のトラストストア ファイルを使用する必要がある場合は、MySQL JDBC 接続文字列に次のパラメータを追加できます。
jdbc_additional_params: trustStore=/path/to/my/truststore.jks&keyStore=/path/to/my/keystore.jks
顧客がホストするインストールでは、必要に応じて max_connections を追加することで、Looker がデータベースと確立できる最大接続数を指定できます。たとえば、データベースへの同時接続数を 10 に制限するには、以下を追加します。
max_connections: 10
Looker の暗号化スキームでは、データベース内のすべての機密データは保存時に暗号化されます。平文のデータベース認証情報にアクセスしてデータベースにアクセスする場合でも、保存前に Looker では機密データが暗号化またはハッシュ化されます。これは、パスワード、アナリティクス データベースの認証情報、クエリ キャッシュなどに適用されます。ただし、この構成のクリアテキスト パスワードをlooker-db.ymlディスクにファイルを作成する場合は、環境変数LOOKER_DBを構成します。looker-db.yml ファイルの各行の Key-Value のリストが含まれます。次に例を示します。
export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"
.db ディレクトリをバックアップする
HyperSQL を復元する必要がある場合に備えて、メモリ内 HyperSQL データベースの構築に必要なファイルを含む .db ディレクトリをバックアップします。
cp -r .db .db-backup
tar -zcvf db-backup.tar.gz ./.db-backup
データベースを移行する
特に HyperSQL データベースが 1 GB 以上の場合は、データベースを MySQL に移行するのに数時間か大規模なインスタンスで数時間かかることがあります。移行中に、EC2 インスタンスを m5.2xlarge に一時的にアップグレードし（32 GB の RAM を使用して、ステップで指定した 26 GB のヒープを使用できるようにします）、これにより約 10 分短縮されます。
Looker ホスト:
cd looker ./looker stop vi lookerLooker 起動スクリプトで、ファイルに新しい行を追加します。
exitAWS コンソールでインスタンスを停止します。停止したら、EC2 インスタンスのサイズを
m5.2xlargeに変更します。次に、インスタンスを再度再起動します。Looker ユーザーとして SSH でホストする。まず、Java が実行されていないことを確認します。そして次のコマンドを実行します。
cd looker java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data looker-db.ymlmigrate_internal_dataステップを実行すると、libcryptが見つからないため、以下からスタック トレースが表示されることがあります。NotImplementedError: getppid unsupported or native support failed to load ppid at org/jruby/RubyProcess.java:752 ppid at org/jruby/RubyProcess.java:749このような場合は、Java コマンドを実行する前に
LD_LIBRARY_PATHを手動で設定します。export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATHそれが正常に完了したら、AWS コンソールからインスタンスを停止します。
これで、インスタンスを元のサイズに復元できます。
インスタンスを再度起動します。
Looker を起動する
Looker 起動スクリプトを編集し、先ほど追加した
exit行を削除します。起動スクリプトで
LOOKERARGSに引数が定義されていないことを確認します。代わりに、引数をlookerstart.cfgファイルに移動して、新しいバージョンの起動スクリプトで上書きされないようにする必要があります。起動スクリプトを保存して終了します。lookerstart.cfgの編集次のようになります。LOOKERARGS="-d looker-db.yml"Looker 起動スクリプトに他の引数がある場合は、
lookerstart.cfgファイルに追加します。.dbディレクトリがまだアーカイブされていない場合は、アーカイブします。mv .db .db-backup tar -zcvf db-backup.tar.gz ./.db-backup rm -rf ./.db-backup/Looker を起動する:
./looker start
Looker が新しいデータベースを使用していることを確認する
Looker がバックエンド MySQL を正常に使用している場合、Looker インスタンスと新しいデータベース インスタンスとの間のネットワーク接続が確認できます。これを確認するには、Looker インスタンスで次のコマンドを実行します。
netstat -na | grep 3306
データベース インスタンスへの接続が表示されます。次のサンプル出力は、IP アドレスが 10.0.3.155 の DB インスタンスを示しています。
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
Looker をバックアップする
MySQL バックエンドに移行すると、Looker の S3 自動バックアップは機能しなくなります。Looker の作業ディレクトリの夜間ファイル バックアップと夜間のファイル システム バックアップを、夜間にバックアップすることをおすすめします。looker/log/ ディレクトリは、ファイル システムのバックアップから除外される場合があります。詳細については、バックアップの作成に関するドキュメント ページをご覧ください。