[MySQL]optimizeの落とし穴 · Real Beat
MySQLのMyISAM型テーブルは、レコードの追加・削除を繰り返しているとどんどん効率が悪くなっていく。そこで定期的にoptimize tableを発行して統計情報の更新や、インデックスページのソートを行ってやることでテーブルの状態を最適化することが出来る。のだが…そこで思いっきり嵌った。 全部のテーブルをoptimizeして、今までslow-logに出ていたあるSQLを実行すると7秒かかっていた処理が1秒かからないまでに実行時間が短縮されたため、効果が出たと喜んでいたのだが。しばらく経って普通にシステムを使ってみると、時折異様に処理が遅いことがある。いままでDBの構成はMaster1+Slave1の２台構成だったのだが、メンテナンスでSlaveを2台増やした。どうも増設したSlaveにアクセスすると重いことがわかった。既存のSlaveと増設Slaveでの違いは、optimizeしたかど
Tungsten Replicatorを使って、非RDS→RDSのMySQLレプリケーションを行う | DevelopersIO
都元です。AWS上に構築するシステムAにおいて、非AWS上で稼働する別システムBで利用しているマスタデータを使いたい、という状況ってありえますよね。既にシステムBは非AWS環境で動いていて、そこで使っているマスタデータを、AWS上に新規構築するシステムBでも使いたい。そして、システムA上でマスタ更新が掛かったら、システムBのマスタも更新されて欲しい、というわけです。 システムA,B共にAWS上にあれば、理想的な解決方法もあるでしょう。逆に、システムBがRDSでさえなければ、MySQL標準のレプリケーション機能を使うこともできるでしょう。しかし、RDSを使う場合は、標準のレプリケーション機能を利用することはできません *1。 というわけで、今回のような非RDSをmasterとするRDSへのレプリケーションでは、サードパーティ製プロダクトのお世話になる必要がありそうです。今回はTungsten
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
MySQL 5.6正式リリース！！ #mysql56
待望のMySQL 5.6が正式にリリースされた。正式版の最初のバージョンは5.6.10である。コミュニティ版（MySQL Community Server）は下記のページからダウンロードできるので、ぜひ今すぐダウンロードして頂きたい。 MySQL Downloads MySQL 5.6のリリースにあわせて、GUIツールであるMySQL Workbenchやドライバも新しいバージョンがリリースされており、MySQL 5.6対応となっている。それらの周辺ソフトウェアもチェックして頂けると幸いである。 新機能について正式版の機能はリリース候補版の頃から特に変更はない。（リリース候補版まで到達したということは、正式版の機能セットは固まったということであり、大きな機能の変更はないことを意味するからだ。）なので新機能については、リリース候補版が出たときに書いたエントリを参照して頂きたい。 漢(オトコ)
MySQL TIMESTAMP型の NOT NULL制約に期待してはいけない | 開発メモるアル
MySQL 5.1.67環境です。 タイトルの通りなのですが、MySQLマニュアルのTIMESTAMPの説明を読んでみると、 NOT NULL制約に関して気になる記述がありました。 MySQLマニュアルのTIMESTAMPの説明 MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 6.3.1.1 TIMESTAMP の特性によると、 TIMESTAMP カラムはデフォルトで NOT NULL になっているため、NULL 値を含めることはできません。NULL を指定すると、現在のタイプスタンプが割り当てられます。 だそうです。 さらっと書いてるけど、NOT NULL制約がエラーチェックに使えないってことじゃないか。 実際、 MySQLのTIMESTAMPカラムをNOT NULLで定義しても、NULLのINSERT/UPDATEを実行すると現在時刻になってしまいます。 これ
Devsの常識、DBAは非常識
1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. ＼こんにちは！／ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日本 MySQL ユーザ会 (MyNA) のスベり担当 3. ＼しゃべること！／ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・ テーブル構築・運営、 DBA はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
PDOにてMaster&Slaveのコネクションを操作するクラス(PHP)
皆様、ご無沙汰しております。笹亀です。 いよいよきたる、9/10に新しいiPhone5 S(仮名)が発表される予定ということで、iphone4を使っている自分は今回のタイミングで変更する予定なので、いまから発表が楽しみです。 さて、本日はフレームワークなどを利用している場合などであれば、あまり使用することはないですが、PDOを利用したレプリケーションしたデータベースのコネクションを切り分ける方法をご紹介したいと思います。PHPでも様々なフレームワーク（symfony,Cake,ZendFramwork）を使い開発をされるようになってきており、あまりレプリケーションの切り分けを考える必要がなくなってきておりますが、切り分けを行う方法（考え方）という視点で見ていただけますと幸いです。 ※尚、ご使用される場合は自己責任でお願い致します 概要について レプリケーションのコネクションを切り分けること
MySQL 5.5で「default-character-set」が使えず文字化けする→「character-set-server」にするとOK | KennyQi PHP Blog
MySQLを5.5にバージョンアップしました。 MySQLを起動すると、 Faildに！！！！ ログを調べてみたら「default-character-set」ってオプションて何？みたいなのが出てました。。 で、調べたら解決しましたのでメモ。 [mysql]MySQL 5.5.3-m3, 5.5.4-m3 同時リリース ここに書いてあるとおり、MySQLサーバのほうは 「default-character-set」というオプションが廃止されて、 「character-set-server」になった模様。 で、下記のようにmy.cnfを修正してMySQLを起動したら無事に再起動できました。 # vi /etc/my.cnf # default-character-set=utf8 ←ここはコメントアウト character-set-server=utf8 # ここを追加 ちなみ
MyISAMからInnoDBへ切り替えるときの注意点
MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな
MySQLリモートDBの結果をローカルCSVファイルに出力する方法 | 開発メモるアル
MySQLのデータをCSVファイルに出力したい場合、 SELECT … INTO OUTFILE 構文を使うのがよくあるパターンなのですが、 DBサーバーがリモートホスト上にある場合はこの方法が使えません。 CSVファイルに出力するコマンド このコマンドで、リモートDBの結果をローカルCSVファイルに出力できます。 構文 mysql -u [ユーザー名] -p -h [DBサーバーホスト名] [DB名] -e "`cat [実行SQLファイル名]`" | sed -e 's/\t/,/g' > [出力CSVファイルパス] 実行例 $ mysql -u test -p -h dbhost testdb -e "`cat outcsv.sql`" | sed -e 's/\t/,/g' > /tmp/test.csv いろいろ調べた結果たどり着いたのが以上の方法です。 理由とか気にならない人は
[MySQL] プロンプトの表示を変えておくといいかもしれない | バシャログ。
もう 11 月ってウソでしょ・・・時の流れの速さに引くわ～。どうもこんにちは nakamura です。 完全にちょいネタですが、最近知った MySQL の設定で mysql コマンドで接続した際のプロンプトの表示を変える方法をご紹介しようと思います。screen とかで複数の DB に同時につなぐケースがある人はこれやっとくと便利ですよ。 設定方法 と言ってもブログに書くほどでもないボリュームですが・・・。 $HOME/.my.cnf にこんな感じの設定を追加するだけです。全てのユーザに適用させたければ /etc/my.cnf に書いてください。 [mysql] prompt = '\u@mysql://db1.example.com/\d $ ' 上記を書いた上で例えば information_schema に接続してみるとプロンプトはこんな感じになります。 root@mysql://d
![[MySQL] プロンプトの表示を変えておくといいかもしれない | バシャログ。](https://cdn-ak-scissors.b.st-hatena.com/image/square/20c0b0df62783283e7ba333774006e31f6235c74/height=288;version=1;width=512/https%3A%2F%2Fbashalog.c-brains.jp%2Fimages%2Fdb01.jpg)
[MySQL] ステータス取得系の SQL まとめ | バシャログ。
夏休みまだ取れてないよ～・・・夏終わっちゃうよ～・・・みなさん、こんちには nakamura です。 コンテンツ DB への更新・参照等は日々使うので割りと覚えやすいですが、パフォーマンスチューニング等行う際にテーブルや MySQL 自体のステータスを取得する SQL ってしょっちゅう使うわけではないので結構忘れがちですよね～。今日はその辺りの SQL 文を備忘録も兼ねてまとめてみようと思います。 テーブル関連 テーブルの一覧を取得。 show tables; テーブル構造を取得。 describe table_name; ; describe にはショートカットが用意されています。 desc table_name; CREATE TABLE 文を取得。 show create table table_name; テーブルの状態を取得。 ; 全てのテーブルを表示 show table st
[MySQL] サイト無停止で ALTER TABLE を可能にする pt-online-schema-change | バシャログ。
早く沖縄オフィス作ってくれないかなー寒くて仕事にならないよ！みなさんこんにちは nakamura です。 ローンチ後もサイトの運用を受け持っているとどうしても機能追加などで DB のテーブル構成を変えなきゃいけないって事あると思います。データ量がさほど多くなければ問題にならないかもしれませんが、MySQL の ALTER TABLE はテーブル全体に対して書き込みロックをかけてしまうため、サイズの大きなテーブルの場合結構な時間サイトを止める必要が出てきてしまったり。。。いい加減なんとかならないのかよ！と思って探していたら中々いい感じのツールを見つけたので今回はそのご紹介です。 Percona Toolkit pt-online-schema-change は Percona Toolkit という MySQL を使う上での便利機能をまとめたツール群に含まれています。pt-online-sc
Amazon RDS で肥大化したslow_logテーブルをクリアする方法
以前AmazonRDSでslow queryを出力するようにする方法にてRDSでslow_logを出力するように設定すると、mysqlデータベースのslow_logテーブルにログが保存されるようになるのですが、このテーブルに保存されたデータは、RDSで作成できるユーザーの権限では削除することができません。 mysql> delete from slow_log; ERROR 1556 (HY000): You can't use locks with log tables. mysql> truncate table slow_log; ERROR 1044 (42000): Access denied for user 'xxxx'@'%' to database 'mysql' このことはgeneral_logにも言えるのですが、 これに対して、Amazonから以下のストアドプロシージ
MySQLデータベース自動バックアップ運用(mysqlhotcopy) - Fedoraで自宅サーバー構築
MySQLデータベースの自動バックアップを行なう。 ここでは、MySQL全データベースをサーバー内の別ディレクトリへバックアップする。 [root@fedora ~]# vi mysql-backup.sh ← MySQLデータベースバックアップスクリプト作成 #!/bin/bash PATH=/usr/local/sbin:/usr/bin:/bin # バックアップ先ディレクトリ BACKDIR=/backup/mysql # MySQLrootパスワード ROOTPASS=Mysqlrootパスワード # バックアップ先ディレクトリ再作成 rm -rf $BACKDIR mkdir -p $BACKDIR # データベース名取得 DBLIST=`ls -p /var/lib/mysql | grep / | tr -d /` # データベースごとにバックアップ for dbname
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう！
先月、Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジンというエントリでSPIDERストレージエンジンによるスケールアウトが凄い！という話を書いた。SPIDERストレージエンジンは凄いヤツだが、ノウハウがあまりウェブ上で見つからない。唯一見つかる日本語の記事は、ウノウラボによる「国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く 」だけである。SPIDERストレージエンジンは斯波氏による単独の作品であるため、斯波氏は開発だけで手いっぱいであり、使い方の紹介記事を書くことまでは手が回らないのであろう。こんな凄いストレージエンジンをドキュメントが足りないせいで使って貰えないなんて勿体ない！！ というわけで、今日はSPIDERストレージエンジンの基本的な使い方について紹介する。少し長いエントリであるが、最後までお付き
MySQLでテーブル毎に設定されているストレージエンジンを確認する方法 - とあるSEの戯れ言
MySQLでは、各テーブル毎にストレージエンジンを設定する事が出来ます。 大体は、この２つのどちらかになるかと思います。 MyISAM：検索に強いらしい InnoDB：トランザクションが使えるらしい と言う事で、各テーブル毎に設定されているストレージエンジンを確認する方法です。 # mysql -u root mysql> use information_schema; mysql> select table_name, engine from tables where table_schema = DB_NAME; +--------------------+--------+ | table_name | engine | +--------------------+--------+ | hogehoge | InnoDB | | hagehage | MyISAM | | hige
MySQL InnoDBにおけるロック競合の解析手順 - SH2の日記
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テーブルを削除する(DROP TABLE文)
