去年からほそぼそと作ってきた、EmacsからDBを操作できるツール Emacs DBI を紹介します。 Emacs DBI の簡単な紹介 このツールの目的は、クロスプラットフォームで便利なDB操作環境を実現することです。 pgAdmin や MySQL Query Browser のようなGUIの良さをCUIで実現してみようとしてみました。すなわち、ぼくのかんがえたさいきょうのDBツールです。ちなみに、このツールにとってEmacsはただの実行環境です。Emacs使わない人でも使うと便利だと思います。 データベース画面 e2wmで3ペインの画面 機能概要 以下のような機能があります。 EmacsとDB接続可能なPerlが動けばターミナルでも何処でも動く DB定義、テーブル定義がすぐ見れる auto-complete によるSQL補完 接続先DBにからキーワード、型名、テーブル名、カラム名など
ふたたびSpiderの話題です。 WEBアプリを世界展開する場合、要件の1つとして、世界各国のユーザーは全てのデータを参照する必要があるが、データの登録は各国、地域の担当者が各自のデータを登録したい、というケースが多いと思います。 たとえば、商品のサイトで、EUと日本にそれぞれ管理者がいるとします。 その場合のユースケースとしては、 EUの管理者はEUの商品を登録する 日本の管理者は日本の商品を登録する ユーザーは全ての商品を閲覧できる となります。 このとき、DBがどのリージョンにあるかによって、ユーザーや管理者の間で、レスポンススポードに差がでます。 DBを日本に置くとEUのユーザーや管理者には遅いシステムとなってしまい、EUに置くとその逆になります。 そのため、各リージョンに全てのリージョンで登録した商品データを用意し、ユーザーのロケーションに関わらず、DBアクセスをユーザーと同じリ
どうもこんにちは。小太り男子中年のサーバーエンジニアです。 先日行われたhbstudy#13の [twitter:@nippondanji]さんのセッション(スライド) で、「BLACKHOLEストレージエンジンを使えば、InnoDBなテーブルの暖気運転(テーブルデータを空読みして、buffer poolに乗っける)ができる」という話があったので、あなるほどーと思い試してみました。 CREATE TABLE _preload LIKE huge_table; ALTER TABLE _preload ENGINE = BLACKHOLE; INSERT INTO _preload SELECT * FROM huge_table; DROP TABLE _preload;なるほどなるほど。
2. 自己紹介 MySQL/Linux周りのスペシャリスト 2006年9月から2010年8月までMySQL本家(MySQL/Sun/Oracle)で APAC/US圏のMySQLコンサルティングに従事 主な著書に「現場で使えるMySQL」「Linux-DBシステム構築/ 運用入門」「Javaデータアクセス実践講座」 DeNAでの主な役割 安定化/パフォーマンス/運用周りの中長期的な改善活動 L3サポート/運用/トラブルシューティング – 難度の高いMySQL周りの問題の根本原因の特定と解決 多くのプロジェクト支援 社内勉強会/トレーニング – MySQLやデータベース周りのベストプラクティスを社内で共有し、 技術スキルを底上げする 技術マーケティング – 国内外のカンファレンスや、技術雑誌等
今日はDeNA Technology Seminar #2ですが、皆さんSpiderの予習復習は大丈夫でしょうか。 Spiderのチュートリアルといえば@nippondanjiさんのエントリーを見るのが一番だと思いますが、ちょっと試してみたいときにmysqlのコンパイルから始めるのは大変なので、linux用のバイナリパッケージでさくっと環境構築しちゃいましょう。 mkdir -p ~/local/src cd ~/local/src wget http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.44-linux-x86_64-glibc23.tar.gz wget http://launchpad.net/spiderformysql/spider-2.x/2.21-for-5.1.44/+download/spider-2.21
MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事(パーティショニングの使用例 - http session情報)を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする(たぶん昨日の例よりも)もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB(MySQL Cluster)ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
先日、SPIDERストレージエンジンについて2度に渡り本ブログで紹介した(その1:Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン、その2:快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう!)が、SPIDERの作者である斯波氏は、実はもう一つ驚くべきストレージエンジンを開発している。その名も、VPストレージエンジンだ。ちょっと地味な名前だが、VPとは、Vertical Partitioning(垂直パーティショニング)の略で、複数のテーブルの上にVPストレージエンジンを被せて、垂直パーティショニング(カラムごとにデータを格納する領域を分ける)を実現するというものだ。他のテーブルの上に被せるアーキテクチャをとっているという点では、VPとSPIDERの発想は同じである。以下は、VPストレージエンジンの動作
先月、Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジンというエントリでSPIDERストレージエンジンによるスケールアウトが凄い!という話を書いた。SPIDERストレージエンジンは凄いヤツだが、ノウハウがあまりウェブ上で見つからない。唯一見つかる日本語の記事は、ウノウラボによる「国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く 」だけである。SPIDERストレージエンジンは斯波氏による単独の作品であるため、斯波氏は開発だけで手いっぱいであり、使い方の紹介記事を書くことまでは手が回らないのであろう。こんな凄いストレージエンジンをドキュメントが足りないせいで使って貰えないなんて勿体ない!! というわけで、今日はSPIDERストレージエンジンの基本的な使い方について紹介する。少し長いエントリであるが、最後までお付き
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
この変数は、サーバー ID を指定します。server_id はデフォルトで 1 に設定されています。 このデフォルト ID を使用してサーバーを起動できますが、バイナリロギングが有効になっているときに、サーバー ID を指定するように server_id を明示的に設定しなかった場合は、情報メッセージが発行されます。 レプリケーショントポロジで使用されるサーバーの場合、レプリケーションサーバーごとに一意のサーバー ID を 1 から 2 の 32− 1 の範囲で指定する必要があります。 「Unique」 は、各 ID がレプリケーショントポロジ内の他のソースまたはレプリカで使用されている他のすべての ID と異なる必要があることを意味します。 詳細については、セクション17.1.6.2「レプリケーションソースのオプションと変数」,およびセクション17.1.6.3「Replica Serv
ふとした事から、レプリケーション周りの調査をしているところ。 MySQL4.1.1から、特定のDBやテーブルのみをレプリケーション対象とする事ができる様になったらしい事を知りました。 MySQL :: MySQL 4.1 リファレンスマニュアル :: 4.11.6 レプリケーションスタートアップオプション `SHOW SLAVE STATUS \G`で、'Replicate_%'な項目が確認できますが、これらがそのオプションで指定されているものです。が、これらをどうやって指定するのか、微妙にわかりません。 webのマニュアルを見る限り、mysqldの起動オプションで指定すればよいような印象ですが、どうなんでしょう。 # Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ig
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA(高可用性) ディザスタリカバリ(サイト間レプリケーション) BI(レポーティングetc) という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く