mysqlで既存の状態からレプリケーション構築 - innodb編 - うまいぼうぶろぐ
webの情報を見てると、まずデータディレクトリをtarで固めて・・・というのを良くみかける。MyISAMのみならそれでもいいと思うけど、InnoDBを使用してるとちょっと不都合かなと思って調べた。 というのもInnoDBのデータ領域は設定した分だけ最初にディスクに作成されるので、数GByteに設定している場合、実際に使ってる実データは少なくてもtarで時間がかかってしまうから。 調べながら試行錯誤したら、mysqldumpを使うだけで出来た。ただし、この方法の場合、dumpを取る間に全テーブルにREAD LOCKを掛ける。master dataの取得さえ先にしとけば、--lock-all-tablesしなくてもいけそうだけど。 masterでの作業 全データのdumpを取得する。 $ mysqldump \ --all-databases \ --add-drop-database \ -
MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpやMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
プロファイリングで快適MySQLチューニング生活
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態（特に状態遷移やリソースの消費状況）を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
MySQL の auto_increment が duplicate key になる恐れ : にぽたん研究所
Clouder::Blogger - max number for INT AUTO_INCREMENT PRIMARY KEYよく、mysqlとかで CREATE TABLEするときに id INT unsigned NOT NULL DEFAULT '0' AUTO_INCREMENT PRIMARY KEY なんつーことするけど、これ、もし最大までいったときにどうなるかって mysqlのMLに出てたんですが、idが最大までいくとその数以上はAUTO_INCREMENT できなくて、duplicate key になっちゃうようです。 TINYINTとかで試すとすぐに確認できます。 なるほどっ！ 目からウロコだっ！！ int(10) unsigned で、auto_increment だと、1 〜 4,294,967,295 までしかインクリメントしないから、仮にもし「1 日 100 万
MySQL＋Apache＋PHPをインストールしよう（1/3） ― ＠IT
PHPとMySQL はじめに、PHP（Personal Home Page tool）について簡単に紹介します（注）。ご存じのように、PHPはWebアプリケーションの定番として定着しています。また、Strutsのような大規模開発向けフレームワークがもてはやされる一方で、PHPをはじめPerlやRuby、Pythonといったスクリプト系言語に代表される「Lightweight Language」が手軽さと機能の豊富さから近年再注目されています。特にDBやWebとの相性がいいPHPは、初歩的なWebアプリケーションから本格的な用途まで幅広く利用されています。 PHP 4.1まではおおむね順調にリリースされていたのですが、PHP 4.2で「register_globals問題」が大きく取りざたされました（コラム1）。ちなみに、快速MySQLでデータベースアプリ！の第5、6回で紹介しているPHPサ
RwJ:[データベース]MySQL-5.0.27のレプリケーション設定
このサイトページは次の URL に移転しました。 0秒後に新 URL に転送します 自動で移動しない場合は恐れ入りますが下記をクリックしてください。 RwJ
MySQLの文字コードにハマる - すがブロ
文字コードを設定するところはたくさんある Database の文字コード テーブルの文字コード カラムの文字コード クライアントの文字コード 基本、これらは全部統一されていれば MySQL のコンバートに巻き込まれることは無いと思う。 だけど、今回ハマったのはDatabase を ascii にしてテーブルを utf8 で作成してしまったことが原因。 テーブルを DROP するのは惜しいので ALTER で文字コードを変えたんだけど、何回やっても何回やっても文字コードがなおらーないよー。何がいけない？ 横着はやっぱりだめなの？*1 と、割と絶望感に打ちひしがれたんだけど、上のほうで書いたとおり、カラムにも文字コードは設定されているわけで、 Table に対して ALTER をかけてもカラムにまで ALTER の影響は無いので、ALTER TABLE する際には各カラムに対する変更も付けてあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://vector.jugem.jp/?eid=130
mikuriya.biz
MySQL の MERGE テーブルで巨大なテーブルを効率的に運用する
現場指向のレプリケーション詳説
mysqlのレプリケーション
MySQL FULLTEXT Ngram : LIKE検索より数十倍高速な、お手軽 日本語全文検索 について｜blog｜たたみラボ