久々の「Club MySQL」となる、『Club MySQL #5 ～SQLデータベースのセキュリティ』を開催しました。mysql.connpass.comClub MySQL は、ひとりの講演者の話をじっくりと聞こう、という趣向の、日本MySQLユーザ会のイベントシリーズです。今回は、徳丸浩先生にお引き受けいただき、Webセキュリティの視点でデータベースとして注視すべき点について語っていただきました。テーマとスピーカーのパワーで、当ユーザ会のイベントとしては「驚くほどたくさんの」参加申込みをいただき、ありがとうございました。 ライトニングトーク メインスピーカーにも、膨大な経験をもとに90分…

目次

• 目次
• とある日
• 環境
• MySQL8.0.24 アップデート手順
  • 1. YUM アップデート
  • 2. MySQL 停止
  • …

エイプリルフール12日目にして JPUG & MyNA合同勉強会 -PLEASE 2021/4- を開催しました。

俺はこの手の「ジョークのために尽くされる ~方向を間違った~ 努力」をするのも見るのも大好きなので、とても俺得な楽しい会でした。
最初の流れを作ってくださった坂井さんと、大人げない大人たちのみなさんに超感謝しています :D

イﾉﾚカ㌠の坂井さん ( @sakaik )

• よく読むと実は「いのれちから㌠」の坂井さん
• PLEASE愛好家
  • 時代に即したMySQﾚの新機能：PLEASE句 - sakaikの日々雑感～(T)編
  …

目次

• 目次
• とある日
• 環境
• ロングクエリー監視
  • ロングクエリー確認
  • Commandについて
…

最近は、会社などの組織において仕事の指示をする場合に、単に上司が命令をするだけでは組織は動かないと言われています。部下に仕事をしてもらうには－－そう、まさにこの「してもらう」の気持ちこそが本質なのですが－－「命令」ではなく「依頼」の形を取ることで、お互いに気持ちよく仕事をすることができ、より良いチームとなるのです。 この世の中の流れは近年、ソフトウェアの世界にも強く適用されるようになってきました。ソフトウェアに於いても、常に、より中立的な立場での対応が求められてきています。 MySQﾚも例外ではなく、最近の修正ではレプリケーションの master-slave を source-replica …

目次

• 目次
• とある日
• 環境
• USINGとONの違いについて
  • 1. 同一列名
  • 2.結合後列数減少
  • …

PHPerKaigi 2021 でトークしてきた話です。

これは yt-healthcheck の話で、ウチの環境ではこれを5分に1回、crondからキックしています。

喋っていた他にもいくつかひねりがあって、でも再集録の時間が取れなくて断念したネタもあります。

• yt-healthcheck (というか、 ytkit 全部そうのはず)が実行するクエリーは全て /* ytkit <関数名> */ SELECT .. のようにコメントが入っている
  • ジェネラルログとかで除外したいのでグレッパビリティのあるキーワードを埋め込んでおく
• innodb_stats_on_metadata=ON で …

MySQL の情報が欲しいとき、なるべく一次情報に近いところから探すことは大切なことです。 Oracle社はMySQLに関する様々な情報を公開していて、特に日本チームの皆さんはMySQLについての系統立てたセミナーを開催し、その動画を公開してくれています。これを学習や情報収集に活用しない手はありません！・・・・なーんて偉そうに書いていますが、実は私も「そういえば動画を公開してるって言っていたっけ」と、つい最近思い出して、見てみようと思い立った次第でして。 実際に動画を見ようとした時に、目的の動画にたどり着くのが少しだけ不便に感じたので、日本語動画についてこのページにまとめてみました。皆さんのお…

日本MySQLユーザ会として、「MySQLユーザ会会(MyNA会)2021年3月」を開催しました。 mysql.connpass.com 通常、毎回4～5人くらい発表してくれるといいなぁと思っているMyNA会、今回登壇くださったのは3名とやや少なめではありましたが、そのぶん、普段聞けない立場からのお話、残念(自称)な感じながらも楽しんでいるお話(いやむしろ楽しんでいるのは周りの人かｗ）、MySQLの内部動作に関する深いお話など、濃厚なお話を聞かせていただける時間となりました。発表くださったみなさん、質問等で盛り上げてくださった皆さん、ありがとうございました。 つたない進行のせいか、参加者の皆さ…

デッドロックは複数のトランザクションが複数のレコードをロックする場合にタイミングによって発生する。

1. トランザクションAがレコード1をロック→成功
2. トランザクションBがレコード2をロック→成功
3. トランザクションAがレコード2をロック→2のロックの解放待ち
4. トランザクションBがレコード1をロック→1のロックの解放待ち

AもBも互いのロックの解放を待つことになってデッドロックする。 MySQLはデッドロックを検出すると、片方のトランザクションでデッドロックエラーを発生させて強制的にトランザクションを終了させる。

たとえば、次のような2つのトランザクションを同時に動かすとデッドロックエラーが発生する。

CREATE TABLE t (a INT, val INT, …