NuxtMeetUp#8 に行ってきた
こちらのイベントに行ってきました。
以前からずっと申し込んでいたけど、圧倒的な定員オーバーで抽選に漏れ続け、ようやく参加が実現してめっちゃ嬉しかったです。
続きを読む念願の抽選にようやく当選!
— Hayato Yamashita (@phayacell) May 7, 2019
めっちゃ嬉しい。頑張って学ぼう。
NuxtMeetUp#8 https://t.co/c86lWDiBk9 #nuxtmeetup
ブログを移行しました
はてな ID を変更したかったので、あわせてブログを移行しました。
旧ブログ h-yamashita.blog はしばらく残しておきますけど、更新はこちらでやっていきます。
もし、ブログ執筆が続くようであれば、新ブログで Pro 契約しよっかなー。
プライバシーポリシー
アクセス解析ツールについて
当サイトは、アクセス解析ツール「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 である制約に当たってしまった、と思われます。
これも実績あるクエリ、ということで謎に思えたのですが、エラーメッセージでググって出てきた以下の記事に助けられました 🙏
上記の記事は Laravel で、私の使うシステムは Symfony という違いはありましたが、原因だろうと思われるインデクスの type は varchar(255)
である点は同じでした。
そこで、Amazon RDS の設定値を確認、そしてビンゴ。
文字コード関連の設定値が utf8mb4
になっていました。
varchar(255)
を 4bytes で保存すると 767bytes を超えてしまいますので、上記の記事と同じ現象ということですね。
解消方法の検討
対処法はいくつかあるのですが、私は Amazon RDS の設定値を書き換えることにしました。
インデクスの対象となるカラムのサイズを変えたり、インデクスの最大サイズを変更したり、最初に CREATE DATABASE する際の文字コード指定でも良いのですけれど、今回の主目的はデータ移行。
前の DATABASE で utf8
を使っていたので、それに合わせるのが適当だと判断しました。
解消
というわけで、Amazon RDS の設定画面から、パラメータグループを開きます。
パラメータの数が多いので、絞り込むために character_set
と入力すると、目的のパラメータが出てきます。
ここで utf8mb4
になっている設定を utf8
に書き換えます。
この変更を保存。
RDS を再起動して、もう一度 CREATE DATABASE からやり直すと、文字コードが utf8
で構築し直されました。
あとは、先ほどコケた 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 ファイルを開くと、エラーは出る
- Google Chrome で PDF ファイルを開くと、エラーなく表示できる
- Firefox で PDF ファイルを開くと、エラーは出ないが、フォームに入力していたはずの内容が消えている
- 私以外の環境(同僚の PC)で開いてみたが、全く同じ現象
ブラウザによって内臓の PDF Viewer が異なるのは知っていましたが、どうにも不思議な感じです。
ファイルとして破損しているなら、どのソフトウェアでも同じようにエラーが出るんじゃないかと思いますし、当方の環境に依存している様子もありません。
Acrobat の不具合かと思いきや、Firefox でもうまく表示されないみたいで、どの視点で見ても中途半端にダメダメな感じです。
エラーの発生条件
どうにも不可思議なこの現象。
どうググっても公式見解にたどり着くことが出来なかったので、数時間かけて、不確定ではありますが、状況証拠から発生条件を割り出すことが出来ました。
その条件は以下。
- 当該フォームの
font-size
が自動
に設定されている - 当該フォームの
padding
が0
に設定されている - 当該フォームに入力する文字数が多く、フォームの横幅以上だったため、フォントサイズが自動調整される
これらの条件に全て当てはまる時、このエラーが発生しているようでした。
エラーの対処法
この中でもっとも簡単に対処可能そうだった padding
を 1
に設定してみました。
すると、Acrobat でエラーが出ることはなくなり、Firefox でも無事に表示されました。
試していませんが、他の条件を満たさないように変更することでも対策できそうです。
まじかよ。
おわりに
先述のとおり、どうやら padding
なしのフォームでフォントサイズを自動調整しなければならない場合に発生するようです。
よほどのことがない限り padding
を 0
に設定することはないと思うので、これからは 0
以外の値を設定する癖をつけようと思います。
一件落着。