NuxtMeetUp#8 に行ってきた

nuxt-meetup.connpass.com

こちらのイベントに行ってきました。

以前からずっと申し込んでいたけど、圧倒的な定員オーバーで抽選に漏れ続け、ようやく参加が実現してめっちゃ嬉しかったです。

続きを読む

プライバシーポリシー

アクセス解析ツールについて

当サイトは、アクセス解析ツール「Google アナリティクス」を利用しています。

この Google アナリティクスは、トラフィックデータの収集のために Cookie を使用しています。
トラフィックデータは匿名で収集されており、個人を特定するものではありません。
当サイトは、それらの情報をサイト利用状況の計測・分析、サイトの質の向上目的に限り使用しています。
この機能は Cookie を無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

Google アナリティクスの詳細はこちらをご参照ください。

免責事項

当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。

当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもあります。

当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

プライバシーポリシーの変更について

当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。

修正された最新のプライバシーポリシーは常に本ページにて開示されます。

Amazon RDS に MySQL のデータを移行しようとしたら Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes と怒られた話

はじめに

最近、お仕事で AWS に触る機会が出てきました。

触ると言っても AWS の機能をフル活用して、ってレベルではなくて。
Web として EC2 にインスタンスを立てて、DB として RDS を使って、といったくらいのものです。

起きたエラー

現在進行系で国内産クラウドを使っているのを AWS に切り替えよう、という動きの中で触ることになったのですが、このときに以下のエラーメッセージが表示され、困りました。

SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

国内産クラウドでは、AWS でいうところの EC2 的なサービスでサーバを立て、MySQL を入れて運用していました。

ここで培っていたデータを Amazon RDS に移行しようと CREATE TABLE したときに発生したエラーです。

原因

結論から述べると、MySQL文字コードutf8mb4 になっていたのが原因でした。

エラーメッセージを読み解くと、以下のようになります。

Syntax error or access violation

シンタックスエラーかアクセス違反、ということですね。

過去に利用した実績のある CREATE TABLE のクエリだったので 🤔 という感じです。

1071 Specified key was too long; max key length is 767 bytes

MySQL のインデクスサイズが最大 767 bytes である制約に当たってしまった、と思われます。

これも実績あるクエリ、ということで謎に思えたのですが、エラーメッセージでググって出てきた以下の記事に助けられました 🙏

qiita.com

上記の記事は Laravel で、私の使うシステムは Symfony という違いはありましたが、原因だろうと思われるインデクスの type は varchar(255) である点は同じでした。

そこで、Amazon RDS の設定値を確認、そしてビンゴ。

文字コード関連の設定値が utf8mb4 になっていました。

varchar(255) を 4bytes で保存すると 767bytes を超えてしまいますので、上記の記事と同じ現象ということですね。

解消方法の検討

対処法はいくつかあるのですが、私は Amazon RDS の設定値を書き換えることにしました。

インデクスの対象となるカラムのサイズを変えたり、インデクスの最大サイズを変更したり、最初に CREATE DATABASE する際の文字コード指定でも良いのですけれど、今回の主目的はデータ移行。

前の DATABASE で utf8 を使っていたので、それに合わせるのが適当だと判断しました。

解消

というわけで、Amazon RDS の設定画面から、パラメータグループを開きます。

パラメータの数が多いので、絞り込むために character_set と入力すると、目的のパラメータが出てきます。

f:id:h-yamashita:20190226133346p:plain

ここで utf8mb4 になっている設定を utf8 に書き換えます。

f:id:h-yamashita:20190226133518p:plain

この変更を保存。

RDS を再起動して、もう一度 CREATE DATABASE からやり直すと、文字コードutf8 で構築し直されました。

f:id:h-yamashita:20190226133635p:plain

あとは、先ほどコケた CREATE TABLE を流し、エラーが出なくなったのを確認して、完了です。

おわりに

Amazon RDS ですと、普通に MySQL で構築したときと違って設定値が my.cnf で管理されなくなるので、こうした設定値の差異は起きてしまいやすいかもしれませんね。

今回のエラーで、少しだけ詳しくなれた気がするので、良い経験になりました。

Acrobat で PDF を開いた時に「このページにはエラーがあります。Acrobat はページを正しく表示できない場合があります。PDF 文書の作成者に連絡して、問題を解決してください。」と出た時の対処法

私は、業務上で Field Reports を使っています。

今回の事象は Field Reports に起因しているのかもしれませんが、調査した条件だけ見ると他のソフトウェアを使っていても発生しそうだなぁーと思ったので、起きた事象と発生条件、その対処法を書いておきます。

エラーとの邂逅

ある日、Acrobat で PDF を開くとエラーが発生しました。

開いたのは、業務で開発しているシステムで、Field Reports を使って出力された PDF ファイルです。

テンプレートとなる PDF ファイルにフォームを作成し、PHP のコード上で値を埋め込んで出力する、という至って変わったことをしていないはずだったのですが、出力した PDF ファイルを Acrobat で開いてみると、見慣れない以下のエラーが発生。

このページにはエラーがあります。Acrobat はページを正しく表示できない場合があります。PDF 文書の作成者に連絡して、問題を解決してください。
このページにはエラーがあります。Acrobat はページを正しく表示できない場合があります。PDF 文書の作成者に連絡して、問題を解決してください。

どうやら出力したファイルの何かがおかしいみたいです。

エラーの症状

急いで状況を確認すると、以下の通りでした。

  • Acrobat で PDF ファイルを開くと、エラーは出る
  • Google Chrome で PDF ファイルを開くと、エラーなく表示できる
  • Firefox で PDF ファイルを開くと、エラーは出ないが、フォームに入力していたはずの内容が消えている
  • 私以外の環境(同僚の PC)で開いてみたが、全く同じ現象

ブラウザによって内臓の PDF Viewer が異なるのは知っていましたが、どうにも不思議な感じです。

ファイルとして破損しているなら、どのソフトウェアでも同じようにエラーが出るんじゃないかと思いますし、当方の環境に依存している様子もありません。

Acrobat の不具合かと思いきや、Firefox でもうまく表示されないみたいで、どの視点で見ても中途半端にダメダメな感じです。

エラーの発生条件

どうにも不可思議なこの現象。

どうググっても公式見解にたどり着くことが出来なかったので、数時間かけて、不確定ではありますが、状況証拠から発生条件を割り出すことが出来ました。

その条件は以下。

  1. 当該フォームの font-size自動 に設定されている
  2. 当該フォームの padding0 に設定されている
  3. 当該フォームに入力する文字数が多く、フォームの横幅以上だったため、フォントサイズが自動調整される

これらの条件に全て当てはまる時、このエラーが発生しているようでした。

エラーの対処法

この中でもっとも簡単に対処可能そうだった padding1 に設定してみました。

すると、Acrobat でエラーが出ることはなくなり、Firefox でも無事に表示されました。

試していませんが、他の条件を満たさないように変更することでも対策できそうです。

まじかよ。

おわりに

先述のとおり、どうやら padding なしのフォームでフォントサイズを自動調整しなければならない場合に発生するようです。

よほどのことがない限り padding0 に設定することはないと思うので、これからは 0 以外の値を設定する癖をつけようと思います。

一件落着。