XtraBackupとは Percona社 が開発しているオープンソースのMySQLのバックアップツールです。InnoDB, XtraDBとMyISAMストレージエンジンをブロックすることなくバックアップをする事が出来ます。ライセンスはGPLv2で無料で使えます。 MySQLのバックアップ方法としてよく使われているmysqldumpというツールが有りますが、 大量のデータを保存しているデータベースからダンプしたデータをリストア（復旧）する時に非常に時間が掛かってしまうという欠点があります。 ここでは、mysqldumpとXtraBackupを使ってバックアップを取り、両者のバックアップとリストアのスピードの違いを比較してみます。 使用するサーバは以下の通りです サーバ さくらのクラウド プラン8 CPU仮想4コア メモリ24GB HDD100GB OS CentOS 5.7 64bit M
mroongaのN-gramについては、bigramだけでなく、uni-gramやtri-gramの他、多数の派生N-gramでのトークナイザに対応しています。さらに2013年5月末リリースのmysql-mroonga-3.04にて、待望のWプラグマに対応しました。これにより、Tritonnからmroongaへ移行する際の障壁はEプラグマのみになったと言えます。 Tritonnから乗り換えるならば、mroongaの1択ですね。 Tritonnからmroongaへ移行する7つのメリット それでは早速、Tritonnからmroongaヘ移行するメリットを見てみましょう。 MySQL 5.6対応であること もはやレガシーとなったMySQL 5.0という縛りがなくなることで、MySQL 5.1以降の先進的な機能を取り入れることができます。特にMySQL 5.6ではその進化が甚だしく、次の点を始めと
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
ここまでくると逆に清々しいよね，というくらい派手に飛んだ．そして原因はわからない 環境 root@alice% cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.04 DISTRIB_CODENAME=hardy DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS" root@alice% uname -a Linux alice.trashsuite.org 2.6.24-24-xen #1 SMP Wed Apr 15 18:53:17 UTC 2009 i686 GNU/Linux root@alice% mysqld --version mysqld Ver 5.0.51a-3ubuntu5.4-log for debian-linux-gnu on i486 ((Ubuntu)) 経緯 my
今回は、MySQLのストレージエンジンの中でも特に有名な「MyISAM」と「InnoDB」の2つを取り上げます。MyISAMはMySQLのデフォルトストレージエンジンで、ストレージエンジンを指定せずにテーブルを作成するとMyISAMが選択されます。もう一方のInnoDBエンジンは、MySQLに豊富なトランザクション機能を提供するストレージエンジンとして有名です。 まずはそれぞれのテーブルファイルの構造について解説し、最後にInnoDBのトランザクションについて解説します。 各ストレージエンジンのファイル構造を説明する前に、前知識としてMySQLのディレクトリ構造について説明します。 MySQLのデータベースディレクトリには、バイナリログと呼ぶデータベースの更新情報を格納するファイルと、2つのサブディレクトリが存在します（図1）。 「mysql」ディレクトリには権限テーブルと呼ばれるMySQ
今回は、CSVとBlackholeの2つのストレージエンジンを取り上げます。CSVエンジンとBlackholeエンジンは、共にMySQL 4.1から提供された比較的新しいエンジンです。以降ではそれぞれの特長やテーブルファイルの構成について解説します。 CSVエンジンとは、テーブルデータをCSV（Comma Separated Value）形式のテキストファイルにてディスク上に格納するストレージエンジンです。 テーブルデータをCSVファイルにて格納するメリットは何でしょうか。それは、他のソフトウェアとのデータ交換が容易にできることです。 例えば、MySQLを使用して作成したテーブルデータをExcelなどの表計算ソフトウェアに渡す場合を考えます。その対象テーブルがMyISAMエンジンなどの場合は「SELECT ・・・ INTO OUTFILE」文や他のバックアップツールなどを使用して、一度テー
テーブルを作成する際、CREATE TABLE文のENGINE句に"BLACKHOLE"を指定することにより、Blackholeテーブルを作成することができます。Blackholeテーブルを作成すると、そのデータベースのディレクトリ内に、どのようなカラム構成にてできているかなどのテーブル構造のデータが格納された「テーブル名.frm」のみが作成されます。 次に示すは、「Blackhole_TEST」データベース内に「TEST00」という名前のBlackholeテーブルを作成した時のファイル一覧です。「Blackhole_TEST」ディレクトリ内に「TEST00.frm」ファイルのみが存在していることがわかると思います。
こんにちわ、ミツバチワークス stoneです。 DECOLOGでは、データベースにMySQLを使用しています。 ストレージエンジンのメインはInnoDBなのですが、他にもMyISAM、BlackHole、Archiveエンジンを使っています。 今回は、その中でBlackHoleエンジンについて、DECOLOG内での利用方法をご紹介したいと思います。 BlackHoleエンジンについて BlackHoleエンジンは、何もしません。 insert、update、deleteを行っても、データは全く変更されませんし、selectをしても、データは何も返ってきません。 実際のデータファイルを見てみても、テーブル定義ファイルの.frm以外のファイルは作成されません。 /dev/nullと似ているイメージです。 が、BlackHoleのテーブルに対して発行されたinsert、update、delete
こんにちは。パートナーサービス部の加藤和良です。 2008年末に、mixi の年末年始対策について紹介しました。今回は、ここ数年の年末年始対策の歩みと、今年の対策について紹介したいと思います。実をいうと、設計も実装も自分じゃなかったりするのですが、このまま歴史に埋もれていくのも悲しいので、関係各所に取材してみました。 2008年末をふりかえる まずは、2008年末をふりかえってみましょう。 あのころはまだ mixi の機能も少なく、年末年始の負荷は主に日記に集中していました。そこで当時は ID Generator の改善 - mod_perl をあいだにはさんで MySQL への接続本数を減らす 最新情報DBへの書き込みを非同期に - Q4M をつかって負荷を時間軸で分散する という2つを日記に実装したのでした。 しかし、2008年末から2009年のお正月にかけて、mixi はまたも日記に
MySQL OracleのMySQLパフォーマンスチームが、最新のMySQL 5.5のストレージエンジンInnoDBおよびMyISAMに対して実施したベンチマークの結果を発表した。2010年12月15日(米国時間)に発表されたMySQL 5.5 GAは2年ぶりに公開されたプロダクションリリース。InnoDBが大幅に改善されマルチコア/プロセッサにおける性能が大幅に向上したという特徴がある。 MySQLパフォーマンスチームの公開した結果はMySQL 5.5 InnoDBの評判を裏付けるものとなっている。36コアCPUのシステムにおいてMyISAMとInnoDBの性能をSysbenchで評価。読み書き試験ではInnoDBがMyISAMの35倍の性能を、読み込みオンリー試験ではInnoDBがMyISAMの5倍の性能をマークしている。ほとんどスケールしないMyISAMと比較して、InnoDBは36
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
[ERROR] Got error 134 when reading table './データベース名/テーブル名' こんなエラーが出てたらデータファイルが破損してるので、myisamchkコマンドで修復する。 myisamchk --silent --force --fast --update-state -O key_buffer=64M \ -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \ /path/to/datadir/*/*.MYI こんな感じでエラーのあるデータファイルを修復してくれる。それでもおかしな場合は myisamchk -o /path/to/datadir/*/*.MYI これでより高度な修復ができる。 もちろんMySQLを止めて作業すること。
+------+------+-----------+------+---------+-------+----------------------+--------------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+------+-----------+------+---------+-------+----------------------+--------------------------+ | 2 | root | localhost | hoge | Query | 61998 | Repair with keycache | REPAIR TABLE posts | | 1040 | root | localhost | NULL | Query | 0
MySQL masterDBダウン時のサービス停止時間の短縮をはかるために、MHAについて調査してみました。 通常、運用中の大規模なサービスに、後からHAのアーキテクチャを導入する場合、多くの場合システムの再構築が発生するため、導入のコストは高くなる傾向があります。 予算を確保するため資料をつくって説明にまわり、メンテナンスの為のサービス停止許可を得るためにまた説明にまわり、サーバのセットアップ、データの移行、テスト、リリースと、コストも時間もかかる作業になります。しかしMHAは、既存の環境を入れ替えること無しに導入する事が可能なので、導入コストはとても低いです。 MHAがどういうものか、まだイメージができていない方には、この様に説明することができます。MHAは、masterDBダウン時に、手作業で行っていたslaveの昇格作業をスクリプト化し、監視処理からそのスクリプトを呼ぶことで、ダウ
XtraBackupとは Percona社 が開発しているオープンソースのMySQLのバックアップツールです。InnoDB, XtraDBとMyISAMストレージエンジンをブロックすることなくバックアップをする事が出来ます。ライセンスはGPLv2で無料で使えます。 MySQLのバックアップ方法としてよく使われているmysqldumpというツールが有りますが、 大量のデータを保存しているデータベースからダンプしたデータをリストア（復旧）する時に非常に時間が掛かってしまうという欠点があります。 ここでは、mysqldumpとXtraBackupを使ってバックアップを取り、両者のバックアップとリストアのスピードの違いを比較してみます。 使用するサーバは以下の通りです サーバ さくらのクラウド プラン8 CPU仮想4コア メモリ24GB HDD100GB OS CentOS 5.7 64bit M
前々回の記事、前回の記事と WordPress の反応を改善する方法を探ってきた。 PHP のコードの実行を高速化する XCache をインストールしたり、WordPress のページ表示の反応を良くする WP Super Cache プラグインを追加したりした。 確かに、これらの方策によって多少なりとも改善した気がしないでもないが、正直なところ思ったほどの効果は得られたと言えない。 しかしながら、もっと根本的な設定を見直すことで、大きく改善することができた。 それは WordPress の記事や設定などの各種データを保管する MySQL の設定にあった。 WordPress で使っている MySQL は default-storage-engine の値が InnoDB になっている。 MySQL をインストールしたときのインストール ウィザードで「Multifunctional Dat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く