MySQL8.0 を初めてインストールして、 Laravelでマイグレーションを実行したときにエラーがでて罠にハマりました。 追記: 2020.04.12 PHP 7.1.16, 7.2.4 以降のバージョンから caching_sha2_password に対応するようになりましたので、この記事の設定は不要となります。 環境 MySQL8.0.x PHP < 7.2.4 エラー内容 mysql コマンドで直接データベースへログインできたのですが、Laravel マイグレーションを実行するとエラーとなりました。 $ php artisan migrate Illuminate\Database\QueryException : SQLSTATE[HY000] [2054] The server requested authentication method unknownto the cl
皆さんこんにちは ちょっとしたアプリケーションを作っていると、キーワードやフリーワードを利用した検索が必要になったりします。 でも、そのときにLIKE検索なんてやっていると、全データを走査する可能性があり、あまり気分の良いものではありません。 そこで、適当な全文検索エンジンを使ってインデックスを張っておきたいなと思うわけですが...MySQLの場合、5.6まではデフォルトで(InnoDBに)日本語全文検索エンジンを入れていなかったりと、少々ハードルが高かったのです。 今回はMySQL5.7でデフォルトでNgramが搭載されているようなので、Laravelで全文検索を実装してみましょう。 例によって今回もLaradockを使用して即席環境を構築しています。 MySQLに全文検索が来た！ 大昔のtritton, ちょい昔のgroongaのように、外部のプラグインを導入することなく、裸のMySQ
以下に移行しました。 kenzo0107.github.io
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
MySQL 8.0.0 Development Milestone Release登場！！
先月、詳解MySQL 5.7を発刊したばかりであるが、MySQL 5.7自体は去年の10月にリリースされたバージョンである。それから約1年弱、MySQLは開発の手を緩めること無く日々改良を重ねている。 そう、MySQL 8.0の登場である。 現在はDevelopment Milestone Release（通称DMR）という状態なので、まだ正式版における機能が固まっている段階ではないという点には注意して欲しい。MySQLの開発プロセスでは、DMRをリリースするごとにその段階で成熟した機能をマージする。DMRを何度かリリースした後に、キリの良いところでリリース候補版となって正式版で追加される機能が一応確定し、その後バグ修正を経て正式版（GA版）がリリースされる予定となっている。詳しくはMySQLのマニュアルを参照して欲しい。 バージョン8.0!!5.7の次は誰もが5.8だと思っていただろう・
Percona Data Performance Blogの翻訳。Percona CEOのPeter Zaitevによる、MySQLのメモリー使用量をどのように決めるべきか、またそれを決める時に気にするべきことは何かについてのまとめ。 この記事では、最適なMySQLのメモリー使用量を設定するためのベストプラクティスを扱おうと思います。 使用できるメモリーのリソースをどのように使うか正しく設定するのは、MySQLを最適なパフォーマンスでかつ安定して使うために最も重要なことのひとつです。MySQL 5.7では、デフォルトの設定では非常に少ない量のメモリしか使いません。デフォルトのままにしておくのは、最も良くないことのひとつでしょう。しかし、不適切に設定してしまうと、パフォーマンスを更に悪くする(あるいはクラッシュする)ことにもなりかねません。 MySQLのメモリ使用量を設定するにあたっての最初
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
兼ねてからちょこちょこエラーが出ていたiOSの絵文字を含んだデータにようやく対応しましたので、その備忘録です。 Railsは3.2.11、MySQLは5.6.25です。 ちなみにMySQLは5.5以降からUTF8MB4に対応しています。 はじめに 文字コードをUTF8からUTF8MB4に変更をするにあたっていくつかの注意点があります。 コレーション問題 UTF8MB4のコレーションをデフォルトにしたままだと、寿司ビール問題("🍣"と"🍺"が同じものとして扱われる)と言われる問題に遭遇し、コレーションをUTF8MB4_UNICODE_520_CIにすると、ハハパパ問題("ハ"と"パ"が同じものとして扱われる)と言われる問題に遭遇します。 そのため、ハハパパ問題を気にしない場合(そんな国内サービスはあるのか！？)はUTF8MB4_UNICODE_520_CIを、気にする場合は、コードポイン
If you remember my post How To Disable MySQL Strict Mode on Laravel Forge (Ubuntu), you'll remember that MySQL 5.7 introduced something we've been casually calling "strict mode," which is really a combination of new modes that, in sum, make MySQL process your queries a little more strictly than before. In my previous post I showed how to disable it on Ubuntu, but since then, Adam Wathan has added
※このエントリはMySQL Casual Advent Calendar 2015の5日目のエントリです。 openark-kit というものについて ここまで読んでわかった方は、この先を読む必要はありません。 openark-kitとは、mysqlの運用に便利なツールキットを14個あつめたソフトウェアパッケージです。 Shlomi Noachという方がPythonで開発しており、少なくとも2009年に発表されているようです。 2015-12-05時点での最新版は196.1となっており、.tar.gz および .deb で配布されております。 このエントリを書いた背景事情 そもそも僕自身、50を超えるクラスタ化されたmysqlノードと一緒に業務生活を送っております。 ところが、システムが非常に古くさい構成のため、合計レコード数が2億から3億程度ある垂直分割されたテーブルに対しALTERを投
DockerHubでは公式のMySQLイメージが無料で公開されています。 これを使えば簡単にDockerでMySQLサーバを起動することができます。データの永続化もできます。 https://hub.docker.com/_/mysql/ 2015年10月現在では下記３種類のバージョンが用意されています。 タグを指定することで任意のバージョンのイメージを取得できます。 5.5 5.6 5.7 (latest) イメージの取得方法 docker pull mysql これで最新の安定版を取得できます。 バージョンを明示的に取得したい場合はタグを使います。 docker pull mysql:5.7 (2015/10/25現在だと、mysql, mysql:latest, mysql:5.7, mysql:5.7.9はどれも同じイメージを指します。) これのDockerfileを見たい場合はこ
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
クラウド時代の新常識はこれだ！「MySQL クラウド向け InnoDB チューニング」 こんにちは。インフラエンジニアの nobuh です。 株式会社インサイトテクノロジー様主催の db tech showcase sapporo 2015 が 9月10日、11日の2日間にわたって開催されました 。 今回、弊社も発表する機会を頂きましたので、インフラエンジニアとして日々 MySQL と格闘して培ったノウハウについてお話させて頂きました。その発表で使ったスライドがこちらです。 クラウド上の仮想サーバーを使って MySQL の管理やチューニングに日々邁進されている方々にご覧いただけると幸いです。 今までにも MySQL に関していくつか記事を掲載していますので、この機会に是非ご覧ください！ → OSC2015北海道で「これだけみれば大丈夫ーCactiによるMySQLパフォーマンス監視のツボ」
awesome先生*1に基礎を教わってきたので忘れないうちにメモ。 utf8_unicode_ci / utf8_general_ci MySQL で default charset を utf8 に指定すると、デフォルトで選ばれるコレーションは utf8_general_ci unicode_ci は文字に対して独自の weight map でもって評価する（general_ci は ascii とコードポイントで評価） MySQL で実装されている weight map は１階層のみのため、日本語が入る環境では意図しない挙動をする*2 utf8mb4 も基本的には同一 ただ utf8mb4_general_ci だと絵文字の評価が厳しいので、やるならコードポイントのみで比較する utf8mb4_bin に設定するしかないとのこと "default" charset の挙動 本来 MyS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
