free nudes, naked, photos,
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか?」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
DB 処理における Fixture テストの勧め 自己紹介 Toru Yamaguchi <zigorou@cpan.org> id:ZIGOROu (@zigorou) 株式会社ディー・エヌ・エー ソーシャルメディア事業本部プラットフォーム統括部システムグループエンジニア Japan Perl Association 理事 今回のお題 昨日は割と概念的なお話ばかりだったので、今回は具体的な話メインで行きたいと思います。 やはりプログラミングにはバグがつきもので、それを防ぐにはテストを書くしかないですよね、と言う事でテストにまつわるお話です。 とは言っても今日のこのイベントに来ている人は Test::More でのテストなどは書いた事がある人が多いと思うので、Test::More の説明は割愛します。 まずは Test::mysqld の使い方 とりあえず、手元の環境に mysql をイン
slow query logとかをTest::mysqldで出す 以前ここで書いたTest::mysqldの仕組み、すこーしずつ毎回変えながら使ってる。今は継承はしてないが、まぁやってることはだいたい一緒。 で、テーブルのインデックスとか使ってるクエリとかを確認したいなーと思って、slow query logと general log をぼこっと出せるようにした。 if (! $ENV{ TEST_DSN }) { my %my_cnf = ( 'skip_networking' => '', ); if ( $ENV{SLOW_QUERY_LOG} ) { $my_cnf{ slow_query_log } = 1; $my_cnf{ slow_query_log_file } = $ENV{SLOW_QUERY_LOG}; $my_cnf{ long_query_time } = $
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
来たる6月12日、我が入魂の書籍が発刊される運びとなった。執筆を開始したのはすでに一年以上前であり、本ブログでも何度か「執筆中です!」といいながらなかなか発刊に至らずお待たせしてしまったのだが、しかし時間がかかってしまった分、内容には磨きがかかったと思うので期待して頂きたい。書籍のタイトルは「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」。筆者にとって初の著書(単著)である。名前にエキスパートと冠している通り、中級〜上級者向けの一冊となっている。初心者の方は、まずMySQL 徹底入門 第2版などを先に読んでから本書を購入するといいだろう。以下もくじである。 第1章 MySQLの概要 1 MySQLとは 1-1 世界で最も有名なオープンソースのRDBMS 1-2 LAMPの"M" 1-3 History 2 MySQL Serverの種類 2-1 FOSS Exc
I wrote about FlashCache there, and since that I run couple benchmarks, to see what performance benefits we can expect. For initial tries I took sysbench oltp tests ( read-only and read-write) and case when data fully fits into L2 cache. I made binaries for FlashCache for CentOS 5.4, kernel 2.6.18-164.15, you can download it from our testing stage. It took some efforts to make binary, you may get
出ました。今回は機能追加が1件、バグ修正が55件あります。バグ修正のうちセキュリティに関するものが1件、パーティショニングに関するものが5件、レプリケーションに関するものが7件となっています。 MySQL 5.1.38から本体に付属するようになったInnoDB Pluginですが、バージョンが1.0.7に上がりRCからGA(Generally Available、正式版)となりました。ついに正式リリースです。というわけで何度か繰り返している話題ですが、今回はInnoDB Pluginについて再度おさらいをしておきたいと思います。 InnoDB Pluginの使い方 MySQL 5.1.38以降であればInnoDB Pluginを使うように設定するのは簡単です。/etc/my.cnfに以下の設定を書き加えることでInnoDB Pluginが有効化されます。 ignore-builtin-in
先日、SPIDERストレージエンジンについて2度に渡り本ブログで紹介した(その1:Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン、その2:快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう!)が、SPIDERの作者である斯波氏は、実はもう一つ驚くべきストレージエンジンを開発している。その名も、VPストレージエンジンだ。ちょっと地味な名前だが、VPとは、Vertical Partitioning(垂直パーティショニング)の略で、複数のテーブルの上にVPストレージエンジンを被せて、垂直パーティショニング(カラムごとにデータを格納する領域を分ける)を実現するというものだ。他のテーブルの上に被せるアーキテクチャをとっているという点では、VPとSPIDERの発想は同じである。以下は、VPストレージエンジンの動作
日本のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。
やってみたかったからついやってみた。 #!/usr/bin/perl use strict; use warnings; use Data::Dump qw(dump); use DBI; use Test::More; use Test::Exception; use Test::mysqld; use Test::TCP; sub setup_master { # http://dev.mysql.com/doc/refman/5.1/en/replication-howto-masterbaseconfig.html my $mysqld = Test::mysqld->new( auto_start => 2, mysqld => '/usr/sbin/mysqld', my_cnf => +{ 'port' => empty_port(), 'log-bin' => 'mysql
Various tools for managing, maintaining, and improving the performance of MySQL databases, originally written by Google. Libraries: * pylib/db.py: Easily execute queries in parallel on a sharded database * Depends on MySQLdb. Most tools here depend on it. * permissions_lib/: Manage MySQL permissions in a Python-based format * Depends on tlslite. * parser_lib/: Parse SQL and apply rules based on th
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
I’m running in this misconception second time in a week or so, so it is time to blog about it. How blobs are stored in Innodb ? This depends on 3 factors. Blob size; Full row size and Innodb row format. But before we look into how BLOBs are really stored lets see what misconception is about. A lot of people seems to think for standard (“Antelope”) format first 768 bytes are stored in the row itsel
1 Yahoo! Cloud Serving Benchmark Overview and results - January 29, 2010 Brian F. Cooper cooperb@yahoo-inc.com Joint work with Adam Silberstein, Erwin Tam, Raghu Ramakrishnan and Russell Sears System setup and tuning assistance from members of the Cassandra and HBase committers, and the Sherpa engineering team 2 Motivation • There are many “cloud DB” and “nosql” systems out there – Sherpa/PNUTS –
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く