[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama

5. バグ情報など GTID有効でネットワークが途切れるとデータ消失する InnoDBmemcacheAPIのメモリリーク( #68530 ) GRANT文発行時、構文に特定の記載ミスがあるとレプリ ケーションが停止する( # 68892) マッチしないパーティションがたくさんある場合、予想ス キャン件数を過剰に低く見積もってしまう不具合 ※上記は勉強会で見かけた情報などです 僕らのMySQL5.6移行記(仮) http://www.slideshare.net/conmame/mysql56-27565355 7. 運用方法の変化について GTIDが有効だとSlaveでクエリをスキップできなくなって確認 して空コミットしないといけなくなった(割と手間) MySQL Utilityというpythonツールが便利そう バッファプールのダンプとリスト
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第2弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ&読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
他のDBMSはよく判らないけれど、MySQLのFROM句サブクエリは順番が大事。 ロジックを知らずにサブクエリを書くと、かなり遅くなることが多い。 取り敢えずサンプルテーブル。 mysql> DESC t1; +-------+------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+----------------+ | num | int(10) unsigned | NO | PRI | NULL | auto_increment | | val | char(32)
MySQLのMyISAM型テーブルは、レコードの追加・削除を繰り返しているとどんどん効率が悪くなっていく。そこで定期的にoptimize tableを発行して統計情報の更新や、インデックスページのソートを行ってやることでテーブルの状態を最適化することが出来る。のだが…そこで思いっきり嵌った。 全部のテーブルをoptimizeして、今までslow-logに出ていたあるSQLを実行すると7秒かかっていた処理が1秒かからないまでに実行時間が短縮されたため、効果が出たと喜んでいたのだが。しばらく経って普通にシステムを使ってみると、時折異様に処理が遅いことがある。いままでDBの構成はMaster1+Slave1の2台構成だったのだが、メンテナンスでSlaveを2台増やした。どうも増設したSlaveにアクセスすると重いことがわかった。既存のSlaveと増設Slaveでの違いは、optimizeしたかど
今運用している某システム、MyISAMのある難癖によって非常に辛い目に遭っております。それはもちろんテーブルロック。これはもうMyISAMを選択した時点でどうしても避けては通れない道。そこんところ仕組みをちゃんと理解してないと、MyISAMのほうが速いって言うから選んだのに、なんだよ全然遅いじゃん!っていうか使い物にならないよウワァァァァンみたいなことになりがち。今のシステムでどうやってMyISAMかInnoDBかを分けたのかというと、単純に更新頻度だった。頻繁に更新されるテーブルはInnoDB、そうじゃなければMyISAM。参照が殆どならInnoDBを選択するメリットは何もないと思っていた。が、実は全然そうじゃなかった。 MyISAMが辛いのは、INSERT文実行時にテーブルロックされることもそうだが、時間のかかるSELECT文を実行したときにREADロックされることなんじゃなかろうか。
いちよんこーど Notion/Jira/Confluence/GitHub/OneLogin/AWS/GCPなど開発管理ツールを試して運用していくブログ おそらく MySQL5.1 から 5.6 へ上げた影響だと思われるが、 ユーザの権限を設定することができなくなっていた。 mysql> grant all privileges on testdb.* to testuser@localhost identified by 'testpass'; ERROR 2013 (HY000): Lost connection to MySQL server during query エラーログには以下のような文言がでていた。 バージョン違いの SQL をぶち込んだため、5.6 で必要なテーブルがなくなったのかな。 InnoDB: Error: Table "mysql"."innodb_table
都元です。AWS上に構築するシステムAにおいて、非AWS上で稼働する別システムBで利用しているマスタデータを使いたい、という状況ってありえますよね。既にシステムBは非AWS環境で動いていて、そこで使っているマスタデータを、AWS上に新規構築するシステムBでも使いたい。そして、システムA上でマスタ更新が掛かったら、システムBのマスタも更新されて欲しい、というわけです。 システムA,B共にAWS上にあれば、理想的な解決方法もあるでしょう。逆に、システムBがRDSでさえなければ、MySQL標準のレプリケーション機能を使うこともできるでしょう。しかし、RDSを使う場合は、標準のレプリケーション機能を利用することはできません *1。 というわけで、今回のような非RDSをmasterとするRDSへのレプリケーションでは、サードパーティ製プロダクトのお世話になる必要がありそうです。今回はTungsten
はじめに こんにちは植木和樹です。先日AWSより非RDSなMySQLからRDSへのレプリケーションを用いたデータ移行機能が発表されました。 Migrate On-Premises MySQL Data to Amazon RDS (and back) 非RDS→RDSへのレプリケーションについては、以前都元さんが「Tungsten Replicatorを使って、非RDS→RDSのMySQLレプリケーションを行う」というブログを書いています。サービスの停止を極力短くしつつ大量のデータを移行する際、今まではデータ移行ツールを使う必要がありました。 今回追加された機能によって簡単にデータ移行ができるようになるのでしょうか。試してみたいと思います。 条件 非RDS→RDSへのレプリケーションは以下の条件を満たす必要があります。 RDS: MySQL 5.5.33 以上 または 5.6.13 以上
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
認証プロトコルの現在の実装は、古い (4.1 より前) クライアントによって使用されるアルゴリズムと互換性がないパスワードハッシュアルゴリズムを使用しています。古いクライアントを使用して 4.1 以降のサーバーに接続しようとすると、次のメッセージが表示されて失敗することがあります。 shell> mysql Client does not support authentication protocol requested by server; consider upgrading MySQL client この問題に対処する場合、推奨される解決方法はすべてのクライアントプログラムをアップグレードして、4.1.1 以降のクライアントライブラリが使用されるようにすることです。これを行うことができない場合は、次のいずれかの方法を使用します。 4.1 より前のクライアントプログラムを使用してサーバ
データベースに個人情報を登録するのであれば暗号化は必須です。 しかし簡単に暗号化出来る訳ではなく、相応の工数が必要になります。で、お客様にお見積もりを出す際に、暗号化をご提案し費用をお伝えすると半数ほどは「暗号化しないと安くなる?」と聞かれます。或いは「大丈夫でしょ。暗号化しなくていいから安くして」など。 こういったクライアントの案件はお断りしましょう。 と、強気に出られるのならばいいのですが・・食べていくにはそうも行かず・・が現状です。最初から暗号化を見越してトータルで見積もればいいのですが、目に見えない部分には中々お金を払って頂けません。 見た目には全く同じ動作をし、デザインも全く同じWEBシステムでも、暗号化に限らず様々なものを取り入れると数倍の工数が掛かってしまいます。でもクライアントは中身より金額で、動作するなら安い方を・・となるケースも。 愚痴は置いておき・・ MySQLにはデ
セキュリティに関してどんどん厳しくなっている今日この頃。 DBの暗号化を求められることも少なくない。 というか漏えいしたらこっちにだってリスクがふりかかるので、正直全力でセキュリティ対策はやっておきたい。 (だからもっと予算を割いてくれ!どうしてそこから削ろうとするんだ!) 「MySQL 暗号化」で検索すると「AES_ENCRYPT,AES_DECRYPT」この二つの関数が引っかかる。 SELECT AES_ENCRYPT('kan naoto','password'); と打ち込むと、環境にもよるけど暗号化されているのが分かる。(貼れるかな) + AES_ENCRYPT('kan naoto','password') + ウMァ9\\Kォ5��F�・ + 1 row in set (0.00 sec) 文字化けしているのは、暗号化されてバイナリ型になっているから。 この値をいつもと同じよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く