今回は、前回の記事「Adobe 製品を Windows と Mac でスイッチする方法」を違う角度から見てみます。

今回の CS5 へのアップグレードポリシーを見ていくと、Premiere をはじめとする映像系ソフトの扱いが特別であることが分かります。Creative Suite 5 アップグレードに関する注意点から引用すると、「Premiere Pro、After Effects、Soundbooth、Production Premium へのアップグレードに関しましては、異なるプラットフォーム (異なる言語は不可) へのアップグレードが可能です。」とあったり、「Adobe Premiere / Premiere Pro については、すべてのバージョンよりアップグレードいただけます。」とあります。

Adobe のマーケティング戦略

これらの特別ルールの目的は、Premiere ユーザの囲い込みを続けることだと推察できます。さらに、新規 Premiere ユーザの獲得も視野に入った施策でしょう。

Adobe はクリエイティブ系ソフトウェアでは市場では寡占的地位を築いてきており、2005 年の Macromedia 買収合併後はさらにその傾向が進み、グラフィック系については揺るぎない絶対的な地位にあるわけです。強力なライバル不在のため、のびのびとした価格設定と、平日の営業時間以外は顧客の相手をしないという強気の姿勢を崩しません。これがリーダー企業の競争戦略なのだと言われればそうなのかもしれませんが、ムカつきますね。

しかし、こと映像系に限ってはそうではありません。かつて Premiere は Final Cut Pro に敗北して Mac 市場から撤退していますし、映像編集系ソフトとしてのマインドシェアは低いです。プロユースでも需要はいまいちで、After Effects を除いて、Adobe の映像ソフトは微妙な立ち位置でしょう。

実際にシェアはどんなもんか

シェアが分かる資料が見つからなかったので、BCNランキングを参照してみます。いずれも 2010年6月のカテゴリ別ランキングです。

まずは、対照としてグラフィック系ソフトの販売ランキング。

続いて、これまた対照として画像処理系ソフトのランキング。

CS5 発表直後とは言え、両分野ともに Adobe のシェアの大きさがうかがえるランキング結果です。

一方、映像編集系ソフトではどうかというと、こんな感じです。

9位にギリギリ入っているといった感じです。CS5 発表直後だというのに、それらはトップ10には入ってきていません。まあ、そんなもんですね。

まとめ

Adobe としては、Premiere を再度 Mac 市場に投入したし、Win から Mac への乗り換えユーザが増えているという事実から、この市場のみチャレンジャーとしての戦略に切り替えたのだと思います。こうした背景を考えると、仮にシェア奪回が実現できた場合、この戦略は捨てられる可能性が高そうです。つまり、Premiere はじめ Adobe の映像系ソフトがシェアを伸ばしたとき、またクロスアップデートは認められなくなり、アップグレード対象製品も他製品と同様の縛りにしてしまうでしょう。製品ごとにポリシーが違うのは、内部の管理コストもかかるわけで、変えたがっているに違いないでしょう、と。

しかしながら上で見たようなシェア具合であり、こんな作戦で効果が上がるのかは不透明というか、ぶっちゃけシェアは落とさないけれども伸ばしもできずにハマるんじゃないかと推測しています。その場合は、再度市場から撤退するとか、クローズドでやっていくという流れに行き着くことも考えられるため、やはり今のアップグレードポリシーのままでいることは無いでしょう。

そんなわけで、映像系ソフトのクロスアップデートを考えている方は、今のうちですよ！ Adobe 先生の気が変わらないうちに、ぜひ。

続きを読む "なぜAdobeは映像系ソフトだけクロスアップグレード可にしたか"

5月末に発売された Adobe CS5 に遅ればせながらアップグレードしました。今回のポイントは、Windows 版から Mac 版にクロスアップグレード（異なるOS間でのアップグレード）を実現したことです。

数年前から Mac の環境は手元にあるものの、なかなか Windows から移行することができなかった。理由は、高額な Adobe 製品群がすべて Windows 版であり、それらを Mac 版に交換することができなかったから。Adobe に救済を求めて聞いてみたことがあったけれども、「Mac版を新規に購入してください」というけんもほろろな回答しか得られず、結局 Windows 環境でクリエイティブを続けてきました。

こういう同士も少なくないと思いますが、朗報ですよ！

あまり知られていませんが、なんと CS5 ではクロスアップグレードができます。Adobe 製品を Windows 版から Mac 版に切り替えることができます。もちろん逆に Mac 版から Windows 版へのスイッチということもできます。

Adobe 製品は以前からアップグレードポリシーとして、クロスアップグレードを認めてきませんでした。これは CS5 でも同様なのですが、例外的に Premiere Pro、After Effects、Soundbooth、Production Premium へのアップグレードは、異なるプラットフォーム (異なる言語は不可) へのアップグレードが可能 になっています。今回はこの特例を利用するわけです。

このあたりの情報は Web 上に少ないので、一応、自分の例を書いておきますと、CS3 Design Premium Windows 版から、CS5 Production Premium Mac 版へのクロスアップグレードにしました。CS5 のインストール時に、現在利用中のプロダクトのシリアルを入力しろと求められますが、ちゃんと CS3 Windows 版のシリアルでパスできました。

映像系パッケージ群に限られる方法ではありますが、自分と同じようにグラフィックと映像という守備範囲の人ならドンピシャで使えます。

ほかに方法ないの？

あります。

カスタマーサービスに電話すると、何とかしてくれるかもしれないらしいです。上で、以前相談した際には新規購入を薦められた話を書きましたが、ちょっと態度は軟化しているのかもしれません。

ただ、先のパッケージを使ったクロスアップグレードと異なるのは、以前のシリアルを破棄する代わりに新しいプラットフォームでのライセンスを得ることができる点です。つまり、シリアルが破棄されると、やっぱ前のOSに戻りたい、というときの可逆性がない。ここはグレーゾーンなので棒読みしますが、普通にクロスアップグレードすると、Mac では CS5 が使えるし、Windows では以前のパッケージが使えるという状態になりますね。あら、ナニコレ不思議。

もっと、ほかに方法ないの？

あらためて CS5 のアップグレード対象製品を見てみると、そのなかに「Macromedia Studio 8」という文字があるのに気が付きました。私の記憶が確かならば、Studio 8 は Mac と Windows のハイブリッド版として販売されていた気がします。

つまり、Studio 8 さえ手元にあれば、好きな CS5 製品の Windows 版もしくは Mac 版にアップグレードできるということなんじゃないでしょうか。これ、すなわち最強。原理的にはできますよね、普通に。

結論、Macromedia 最高です。溜池山王時代が懐かしく恋しいです。

続きを読む "Adobe 製品を Windows と Mac でスイッチする方法"

SIer のなかの人は思考が止まってしまっているんでしょうか。

SIer 各社の業績が軒並み悪化しているにも関わらず、現場では新しい提案があるわけでもなく、それならどうやって業績回復のストーリーを実現するつもりなのかと思わされるような話がチラホラ。あとは、現状理解に乏しく需給関係が崩れつつあるにも関わらず、当然の顔で値上げ交渉をしかけてきたりする。バカなのかな、と思うわけです。

まずは状況整理

上場大手 SIer 各社の直近の状況を見てみます。

ほぼ減収減益で、営業利益については、富士ソフトを筆頭に半減しているところもあるという悲惨な状態。NTTデータだけは増収減益になっていますが、前年度はゆうちょなど銀行系の大型受注があったので、それでも売上高が横ばいだったということは、他社と傾向が異なるものではありません。

各社がそろって減収の要因に挙げているのが、企業のIT投資抑制にともなう受注減少。加えて、証券業向けのサービスを展開しているところは、業界自体の低迷でダメージが大きかった模様。流通系は堅調だったみたいですね。

インド・中国へのオフショアリングの更なる推進や、経費や外部委託費の圧縮など、ITゼネコンの多重構造を考えるに、涙なしには語れなさそうなコスト削減を行っているのも、各社共通です。敢えてここに関係ない話題を挟みますが、2009年度の全国企業倒産状況にあるとおり、情報通信業の倒産が6.7%増というのはリアルです。さて、そうしたコスト削減活動があるなかで、なお減益となっているのは、受注減少分がコスト削減効果を上回ったということ。いかに市場環境が悪いかが分かります。

SIer は変わらないのか

こうした市況下にあるものの、ほとんどの SIer が今期は 5% 前後の成長を見込んでいるのは、興味深いです。市況が回復し、クラウド関連事業が伸びるという見方なわけです。

確かに、大企業を中心にIT投資は底を打ったという見方もあるし、足元を見るとコスト削減の旗印のもとにプライベート・クラウドを推進し、導入した企業が増えてきているという事実があります。冷えきったIT投資意欲を、バズワードの独自解釈をもとに構築したソリューションで刺激して需要を生み出そうというあたりは、「いつもの感じ」で素晴らしい。この前まで Saas で大騒ぎしていたものを、一気にクラウドという上位概念で包み込んで一掃してしまう手法には惚れ惚れするわけです。そうしたなか、NTTデータがクラウドという単語より BizXaas という固有名詞で押しているのが、なんともクールです。

クラウドを標榜しつつ、SIer 根性はプラットフォーマーは目指さないし目指せない。その妥協点として着地したプライベート・クラウドでは、これまでの業務知識やノウハウは活きるかもしれないが、未来を作るわけではないと思うわけです。コスト削減効果はあるのかもしれませんが、例によってパッケージングを変えただけに過ぎないとも見えるわけです。

本質的な変化を取れないのは、SIer というポジショニングの宿命なんでしょうか。ソリューションのリパッケージングで延命していくやり方では、二番底は超えられないんじゃないかと思います。

稼働率は上げたいけど供給者目線

利益率アップは至上命題とばかり、SIer の外部委託費はさらに大幅削減とかいう話になっています。内製化傾向にあるユーザ企業にやられた仕打ちを、右から左に受けながすカツヤマー流。数年前の偽装請負禁止に次いで、二次請け・三次請けの会社からは、青息吐息が聞こえてきます。

大手 SIer にとっては、コスト削減効果を甘受しながら、受注減で低下している社内のエンジニア稼働率を上げられる施策ではあるものの、空洞化してしまったあとの社内で仕事を回せといっても回せないという、ウソかホントか区別つかない話が聞こえてくるなど、現場の混乱もなかなか。そこで安価なオフショアという選択肢になるのだろうけれども、ようやく落ち着いてきたと言われるオフショア開発も、最終的に下請け会社に回っていって、そこのSEがほとんどを作り直すなんていう、これまたウソかホントか区別つかない話も聞こえてきます。いろいろ心配です。

個人的に衝撃だったのは、そういう環境化にあって供給過剰で稼働率の下がっているエンジニアなのに、なぜか単価を上げようとかいう話が横行しているという話です。これは一次だけでなく二次請けやっているあたりの中堅どころでもそう。需給関係とか経済の仕組みは無視なんでしょうか。システム系は価格弾力性があまりないとは思いますが。

逆に三次・四次くらいをずっとやってきて、もはや売上が地べたを這っているソフトハウスさんなんかだと、びっくりするぐらい低単価で提案してきて、逆の意味で恐いなんて話も聞きます。それは赤字にならなければ良い、という覚悟の現れらしいですが、ぜひ各 SIer にもそういった姿勢を学んでいただきたく。

結局、言いたかったこと

SIer は自分のおかれた立場をちゃんと理解した上で、本質的な戦略を考えて実行して欲しいなと思うわけです。現状認識が甘いまま、サイズオーバーな提案をしようものなら、足元すくわれちゃうと思うんですよね。

プライベート・クラウドや仮想化によるコスト削減ソリューションは売れると思いますが、それはこれまで売れていたところには売れるし、売れていなかったところには売れないという話のような気がします。だから、中小 SIer が色気を出してクラウドサービスに入っても、ほとんど上手くいかないと思うわけです。ましてやグローバル化をや。

ぜひ某社には、きっちり考えてがんばっていただきたいと思います。

設計方針として「Memcached より先に FileCache を見るように」という話を聞いたので、「えー、それって性能的にどうなんだろうか？」と思い、簡単にベンチマークをとってみました。

環境としては、同一セグメント内のまったく別のホストに Memcached サーバを立てました。つまり、I/Oコストだけでなく通信コストなども含めての比較をしています。

ちなみに、このベンチのために、わざわざ memcached を入れるところから始めました。もちろん連休で時間があるからです。

ソース。

#!/usr/bin/perl -w
use strict;
use warnings;
use utf8;


use Cache::FileCache;
use Cache::Memcached::Fast;
use Benchmark qw(:all);


our $c = 0;


my $count   = 10000;
my $compare = timethese(
    $count,
    {
        filecache => sub {
            $c = 0;
            my $cache = Cache::FileCache->new({
                namespace           => 'test',
                default_expires_in  => 600,
                cache_root          => '/tmp',
            });
            my $data = $cache->get('key' . $c++);
            unless ( defined $data ) {
                $cache->set('key' . $c++, 'value');
            }
            return $data;
        },


        memcached => sub {
            $c = 0;
            my $cache = Cache::Memcached::Fast->new({
                servers     => ['192.168.50.102:11211'],
            });
            my $data = $cache->get('key' . $c++);
            unless ( defined $data ) {
                $cache->set('key' . $c++, 'value');
            }
            return $data;
        },
    },
);


cmpthese $compare;

10000 回の R/W の結果はこちら。

Benchmark: timing 10000 iterations of filecache, memcached...
 filecache:  5 wallclock secs 
 ( 4.55 usr +  0.76 sys =  5.31 CPU) @ 1883.24/s (n=10000)
 memcached:  7 wallclock secs 
 ( 0.26 usr +  0.15 sys =  0.41 CPU) @ 24390.24/s (n=10000)
             Rate filecache memcached
filecache  1883/s        --      -92%
memcached 24390/s     1195%        --

なんと FileCache の圧倒的な勝利。ネットワークコストが大きかったのか、想定外の差が出て驚きました。冒頭の設計方針に一理あるということは分かりました。疑ってすみません。しかし何か根本的なところを間違っていそうな気もしなくはないなあ。

ちなみに、「じゃあ Memcached やめて FileCache を積極的に使っていこうぜ！」とはもちろんならないです。それぞれの環境に応じて求められるものは変わってくるし、分散であったり failover しやすかったりという優位性があるので、それなりの規模で総合的に判断すると、 Memcached に軍配が上がるんではないでしょうか。逆に言えば、スタンドアローンだったり、Webサーバ1台・DBサーバ1台みたいな環境であれば、FileCache の方がメリットが大きそうですね。

ベンチの見方を盛大に誤っていまして、上記でまったく逆の考察をしていますが、誤爆です。やはり超圧倒的に Memcached が高速でした。wallclock secs を見ていたのですが、普通に秒間処理で測るんですよね。10倍以上の性能差です。

なので、考察としては、よほどネットワークコストが大きいとか、ディスクI/Oに対してメモリが不足しているとか、共用環境で memcached 立てられないといった限定的な環境以外では、FileCache の出番は無いということです。今回の検証は HDD でしたが、SSD にしても改善される性能は 2-3 倍程度でしょうから、Memcached の優位性は変わらないでしょう。

関連記事

CentOS に memcached をインストールする

LWP でベーシック認証に対応する

特定のサイズのファイルを生成する

perl で配列に要素が含まれているか調べる方法

perl で mkdir -p

以前は yum でサクッとインストールできたと記憶しているのだけど、今は yum でインストールできないようなので、ソースからインストールしました。手間がかかったので、次回へのメモとして、ログを残しておきます。

まず、memcached が使うイベント通知APIの libevent のバージョンを確認。

# rpm -q libevent
libevent-1.1a-3.2.1

1.1系と古いので、新しいものを入れます。ソースは公式サイトから、安定版のうち最新のものを持ってきます

# cd /usr/local/src
# wget http://www.monkey.org/~provos/libevent-1.4.13-stable.tar.gz
# tar xvfz libevent-1.4.13-stable.tar.gz
# cd libevent-1.4.13-stable
# ./configure --prefix=/usr/local/libevent
# make
# make install

続いて、 memcached をインストールします。ソースは公式サイトから。

# cd /usr/local/src
# wget http://memcached.googlecode.com/files/memcached-1.4.5.tar.gz
# tar xvfz memcached-1.4.5.tar.gz
# cd memcached-1.4.5
# ./configure --with-libevent=/usr/local/libevent/
# make
# make install

起動コマンドを作ってサービス登録します。といっても、そのままコピーですが。キャッシュ容量やポート番号を変えるなどしたい場合は、このスクリプトのなかをいじりましょう。

# cp /usr/local/src/memcached-1.4.5/script/memcached.sysv /etc/rc.d/init.d/memcached
# chkconfig --add memcached
# chkconfig --list memcached

用意が整ったところで、起動します。

# /etc/rc.d/init.d/memcached start

ここで、起動せずに次のようなエラーが出ることがあります。

memcached: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or directory

今回は libevent を /usr/local/libevent にあるものを使うため、ldconfig してあげなければいけませんでした。

# echo "/usr/local/libevent/lib" > /etc/ld.so.conf.d/libevent.conf
# ldconfig

このあと起動すれば、問題なく立ち上がると思います。動作確認をします。

$ telnet localhost 11211
stats
STAT pid 11440
STAT uptime 71
STAT time 1272779578
STAT version 1.4.5
STAT pointer_size 32
STAT rusage_user 0.000000
STAT rusage_system 0.010000
STAT curr_connections 10
STAT total_connections 11
STAT connection_structures 11
STAT cmd_get 0
STAT cmd_set 0
STAT cmd_flush 0
STAT get_hits 0
STAT get_misses 0
STAT delete_misses 0
STAT delete_hits 0
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 7
STAT bytes_written 0
STAT limit_maxbytes 67108864
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT bytes 0
STAT curr_items 0
STAT total_items 0
STAT evictions 0
STAT reclaimed 0
END

stats と打つとステータスが、バーっと流れるので確認しましょう。プロンプトを抜けるときには、いつもどおりで quit と打てば OK。

最近セットアップを自動化しているせいで、こうしてソースから入れるのは2年ぶりくらい。ldconfig とか忘れてしまっていて、やり方を思い出すのに、ムダに時間かかってしまいました。うーむ。

以上、おつかれさまでした。

関連記事

FileCache と Memcached を比較する

特定のサイズのファイルを生成する

bashでヒアドキュメントをリダイレクト

NULL文字を削除する

自分メモ。

LWP で ベーシック認証のかかったページにアクセスするには、authorization_basic を使えば良いらしい。簡単だ。

#!/usr/bin/perl
use strict;
use LWP::UserAgent;
use HTTP::Request;


my $req = HTTP::Request->new(GET => "https://foo.bar.com/basic/auth.html");
$req->authorization_basic('account', 'password');
my $ua = LWP::UserAgent->new();
my $res = $ua->request($req);


if ($res->is_success) {
    print $res->content;
} else {
    print $res->code;
}

関連記事

FileCache と Memcached を比較する

perl で配列に要素が含まれているか調べる方法

perl で mkdir -p

perl でビット演算の結果を数値比較する際の注意点

ファイル操作のテストなどで、特定の大きさのファイルを作成したいときがあります。そんなときは、 dd コマンドを使うと簡単に作ることができます。

dd if=/dev/zero of=test_file bs=1M count=10

上記の例だと、カレントディレクトリに「test_file」という10MBのファイルが生成されます。便利。

関連記事

FileCache と Memcached を比較する

CentOS に memcached をインストールする

bashでヒアドキュメントをリダイレクト

NULL文字を削除する

MySQL で新たにテーブルを作ったり、プライマリキー、ユニーク制約、またはインデックスを作成する際、下記のようなエラーが発生することがあります。

ERROR 1170 (42000): BLOB/TEXT column 'text_field' used in key specification without a key length 

結論として回避策から書くと、BLOB型またはTEXT型の場合は、インデックス作成時にキー長を明示してあげる必要があります。

create index new_index on table_name(text_field(100));

このエラーは、MySQL が BLOB型もしくはTEXT型 （これらに順ずる TINYTEXT型 や LONGTEXT型を含む）のような可変長カラムでは、その先頭から最大255文字分しかインデックスできないという制約から来ているようです。解決策は上記のとおり、キー長を明示するか、変わりに255以下で VARCHAR(100) のようなカラムを使って、そちらをインデックスとして使うといった工夫が考えられます。

考えてみれば当然と言える話ではあります。

題目を索引することはあれど、本文を索引した書籍など見たことがないですし、そこに意味がないことは誰もが分かるでしょう。たとえ本文を索引にするとしても、冒頭の一節というのが関の山。この MySQL の仕様は、理に適っている気がします。逆に本文を索引したい、つまり全文検索用の FULLTEXT インデックスであれば、TEXT型カラムにもちろん作成することができます。

このエラーに遭遇したときは、上記のような解決法もひとつの手ではありますが、そもそも TEXT型カラムを主キーにしたり、インデックスを張ろうという設計が正しいかどうかを考えてみた方が良いでしょう。

例外は、百人一首的に冒頭の一節から引きたいか、50音順インデックスを使うようなケースだけじゃないでしょうか。LIKE 検索で、先頭数文字で引っかけたい場合。それも、通常は最低1000 レコードを超えてこないとインデックスが効いてこなかったりするので、さらにレアケースな気がします。

エラーが起きるとついつい今すぐで回避方法を探してしまいがちですが、そもそもエラーになるような設計が正しいかどうか考えるクセは付けておきたいもんです。結局、そういう考え方が未来の自分を救ったりするんだから。

関連記事

MySQLで実行中のSQLをキャンセルする

mysql のスレーブを再構築する

MySQLのレプリ遅延の原因を調べる方法

PostgreSQLでMONTHS_BETWEEN

PostgreSQLで半角カナを全角カナに変換する関数

ある配列に特定の要素が含まれているかどうか知りたいとき、 java では List#contains が用意されていますが、どうやら perl では標準で用意されていないんですね。ここら辺を自前で書くのが perl 流といったところでしょうか。

#!/usr/bin/perl -l


my @array = qw/a b c d e f g/;
undef %tmp;
for (@array) { $tmp{$_} = 1; }


print $tmp{"a"} ? 'true' : 'false';
print $tmp{"h"} ? 'true' : 'false';

数値配列で有無をチェックする場合は、vec を使う方法で軽くできるとのこと。

関連記事

FileCache と Memcached を比較する

LWP でベーシック認証に対応する

perl で mkdir -p

perl でビット演算の結果を数値比較する際の注意点

perl で mkdir -p 同様のことをするには、File::Path の mkpath を使うと良いらしい。

#!/usr/bin/perl -w


use strict;
use warnings;
use File::Path;


my @dir = mkpath ('/data/test/1/2/3/');
for (@dir) {
    print $_ . "\n";
}

実行結果は、作成したディレクトリパスの配列。以下は、/data/test が存在していた場合の結果。

/data/test/1
/data/test/1/2
/data/test/1/2/3

ラクチンです。危なく自分でループ回すところでした。

なかなか便利なモジュールのノウハウが蓄積されないので、やりたいことがあったら、まずはモジュールを探してみる癖を付けるようにしたいなあ。perl ってサクサク書けるので、ちょっとした処理だったら自前でサブルーチン用意してしまっているんですが、本当はもったいないですよね...。

学習ベースの防備録として今後モジュール関連ネタ、メモしていきます。

関連記事

FileCache と Memcached を比較する

LWP でベーシック認証に対応する

perl で配列に要素が含まれているか調べる方法

perl でビット演算の結果を数値比較する際の注意点

レプリケーションができていないのでログを見てみたら、「Client requested master to start replication from impossible position」というエラーが出力されていた。確かに、「show slave status」で表示されるポジションが、バイナリログ内に見つからない...。

不整合の度合いがハンパないのと、運用から切り離されているサーバだったので、スレーブをゼロから再構築することにした。以下、そのときの手順メモ。

まず、マスターの更新を止めてデータをdumpします。

mysql> FLUSH TABLES WITH READ LOCK;

スレーブ開始にそなえてポジションを確認。

mysql> SHOW MASTER STATUS \G
         File: db01-bin.010
     Position: 5432
 Binlog_Do_DB: db_name
Binlog_Ignore: 
1 row in set (0.00 sec)

データをdumpします。

$ mysqldump -uroot -hdb01 db_name > /tmp/db_name.dump

マスターの更新ロックを解除。

mysql> UNLOCK TABLES;

マスター側の操作はここまで。続いて、スレーブの再構築の作業に入ります。最初に、これまでのレプリ情報を削除してしまいます。

# /etc/rc.d/init.d/mysqld stop
# rm /var/lib/mysql/master.info
# rm /var/lib/mysql/relay-log.info
# /etc/rc.d/init.d/mysqld start

データベースをゼロから作るため、今までのデータベースを削除して作り直し。

mysql> DROP DATABASE db_name;
mysql> CREATE DATABASE db_name;

マスターのdumpデータをリストア。

# scp db01:/tmp/db_name.dump /tmp/
# mysql -uroot -hdb01 db_name < /tmp/db_name.dump

レプリケーションの設定を最新のものに。ポジションとログファイルは、先ほど「SHOW MASTER STATUS」した結果のものを使用します。

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO 
  MASTER_HOST='db01',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='db01-bin.010',
  MASTER_LOG_POS=5432;

スレーブを開始します。

mysql> START SLAVE;

これでレプリケーションが正常に行われるはずです。「SHOW SLAVE STATUS」やログにエラーなど発生していないことを確認しましょう。うまくいかない場合は、しかるべきときに mysqld のプロセスがきちんと停止していなかったとか、dump がうまくいっていなかったとか、そういったところだと思います。手順が少ないので、問題になる場所も限られます。

ここまで書いて気付いたのですが、スレーブが複数ある場合は、何もマスターの更新を止めてやる必要がないですね。そして、もっとシンプルな手順でできそう。

お疲れさまでした。

関連記事

MySQLでBLOB/TEXT型カラムにインデックスを張る

MySQLのレプリ遅延の原因を調べる方法

MySQLで実行中のSQLをキャンセルする

転職を機に perl を書くようになって以来、vim 一本で開発のすべてを行っています。

かつては、何と java を vi で書いていたこともあったし、運用でしばしば vi を使う機会があったので、基本的な操作は身に付いていたんですが、本格的に vi を使うようになって色々と便利な技があることを知ったのでシェアメモ。

まずは、文字コード変換。

:e ++enc=shift_jis
:e ++enc=iso-2022-jp
:e ++enc=euc_jp

これができないと、そもそも vim 一本で開発することができないという話。テンプレ編集やメール系の開発するときに便利すぐる。

続いて画面分割

:sp

これで画面が上下に分割して編集できます。画面を切り替える場合は、Ctrl+w を2回。プログラムを書いていて、「あ、これって他はどうしてるんだっけ？」と思って一時的に参照したい場合に便利です。

現在カーソルのある画面を閉じる場合は、

:close

現在カーソルのある画面以外をすべて閉じて、通常モードに戻す場合は、

:only

diff のように行単位で違いを眺めながら編集したい場合は、

Ctrl+w → v

これで垂直分割になります。純粋に 2ファイルの diff を見るのならば、vimdiff で OK なんですが。

分割したそれぞれの画面で別のファイルを表示するには、その画面に切り替えて、

:e ファイル名

これで、新しいファイルの編集モードに入れます。

ファイルを開くという意味では、編集中のファイルにあるパスにカーソルを合わせて

gf

これで、そのパスにあるファイルを開くことができます。これ、ヤバイです。芋づる式にプログラムを編集できます。grep 結果をファイルにリダイレクトしておいて、あとで開いて順番に見ていきながら編集する場合に重宝しました。

画面分割は、「screen 使えば良いんじゃないの？」という話もありますが、ちょっとした比較には vim の画面分割はダントツに力を発揮します。特に、ノートPCやサーバのコンソールのように、小さい画面で頑張らないといけない時なんかは、知っていると知らないとでは作業効率に雲泥の差が出ますよ、ホントに。

ということで便利技をいくつか書いてきましたが、要するに「java × eclipse の開発は便利で良かったなぁ」ということです。 vim でどんなに頑張っても、さすがにアレにはかなわないですね。

MySQLのレプリ遅延の原因には、大きく分けて、転送遅延とSQL実行遅延の2つがあります。

転送遅延は、マスタでバイナリログに出力されたSQLクエリが、スレーブのリレーログに出力されていないケース。SQL実行遅延は、SQLクエリがリレーログに出力されたが、実行が遅れているケース。レプリ遅延時の問題の切り分けとして、まずどちらのケースに該当しているかを判断する必要があります。

転送遅延の判定方法

マスタでの SHOW MASTER STATUS の結果と、対象スレーブでの SHOW SLAVE STATUS の結果を比較します。比較する項目は、以下のとおり。

この2項目で差がある場合、転送遅延が起こっている。マスタとスレーブのサーバ間に何らかの問題が起こっていると考えられるので、その線で本質的な問題を追っていくことになります。

SQL実行遅延の判定方法

転送に遅延がなかった場合、こちらの調査に移ります。

対象スレーブでの SHOW SLAVE STATUS から、次の項目同士を比較して判断します。

スレーブ側における、I/OスレッドとSQLスレッドの処理差から、つまりSQLの実行処理がどのくらい遅れているのかを調べることができます。SQL実行遅延の場合、スレーブの負荷が何らかの理由で高まっているケースなどが考えられます。マスタに比べてスレーブサーバの処理性能が劣るような場合、更新クエリが詰まることも考えられます。結構、厄介な話。

SQL実行遅延の場合、ほっときゃ直るケースも多かったりするのですが、転送遅延の場合は抜本的な対策が求められることが多いような気がします。両者とも各環境に応じたノウハウの積み上げから、最終判断をする必要はありますが。

ちなみに、そもそもの話として、レプリ遅延を監視するには、SHOW SLAVE STATUS のSeconds_Behind_Master という項目を見る方法が手っ取りばやいです。ただ、MySQL4.1.1以降から対応らしいので、MySQL4.0系では、こちらで紹介されているような方法は良いですね。

SHOW MASTER STATUS 、SHOW SLAVE STATUS で見られる項目の説明については、本家が一番わかりやすいと思います。

良いレプリ運用ライフを！

関連記事

MySQLでBLOB/TEXT型カラムにインデックスを張る

mysql のスレーブを再構築する

MySQLで実行中のSQLをキャンセルする

cookie や javascript に対応したことで話題の iモードブラウザ2.0 ですが、一方で搭載機種が次々に発売停止や発売延期になっているようです。

「docomo PRIME series N-06A」の一時販売停止及び「docomo STYLE series N-08A」の販売延期のお知らせ
「docomo PRIME series P-07A」の一時販売停止のお知らせ

伝え聞いたところでは、月末発売予定だった SH-06A と F-09A も販売延期になる模様。

発売日に販売停止という異例の事態が、さらにここまで拡大してくると、「あいかわらずＮ社のデスマ品質はハンパねぇなあー」とか、笑えなくなってくる。SH あたりが本当に販売延期となると、いよいよドコモ側の仕様の問題という見方が強まるんじゃないでしょうか。いずれの機種でも、同じ脆弱性が見つかっていると聞きますし。

そもそもこの問題自体、発売後にコンテンツプロバイダーからの脆弱性の指摘を受けて発覚したもの。（実際、ユーザーからの問い合わせなどは今のところなし）にもかかわらず、ドコモからコンテンツプロバイダー側に一切の説明はなし。いくつかの公式サイトに聞いたところでは、詳細情報は下りてきていないそう。

ドコモ様の不敵っぷりは、相変わらずです。

正直これだけのバージョンアップなので、今回問題となっている脆弱性だけで終わるとは思えず、今後ひきつづき見つかっていくでしょう。そこを共に乗り越えていくべきコンテンツ・プロバイダーとの距離感は、iモード2.0 普及の必要条件だと思うんですが。

機能的には可能性があると思っている iモード2.0 なので、ぜひキャリアとコンテンツプロバイダーが連携しながら、迅速な普及を行っていって欲しいですね。

関連記事

iモードブラウザ2.0の衝撃

docomoより、かねて噂になっていた iモードブラウザ2.0 の仕様が発表されました。

iPhone や BlackBerry 、そして Android 携帯といったスマートフォン群の躍進を、iモードも黙って見ているわけはなかった。スマートフォン・ブラウザに対抗すべく、かゆいところに手が届く機能性を備えた、エポック・メイキングなアップデート。コンテンツ・プロバイダーへの衝撃は大きいですね。

作ろうiモード：iモードブラウザ2.0新機能一覧

新機能の詳細は、上記のドコモ公式サイトをご覧いただくとして、いくつか重要な機能をピックアップしていきます。

FLVとWMA 動画対応

Flash Video と Windows Media ファイルに対応。FLVのプログレッシブダウンロード、WMのストリーミング配信で最大10MBまで再生可能。これまで工夫をこらした配信で盛り上がってきた携帯動画の世界も、これで一気に敷居が低くなって裾野が広がりそう。

Ajax 対応

JavaScript に対応というのが機能の本質。しかし、XMLHttpRequest も使用可能で、広がりは無限大の機能拡張のため、あえて「Ajax 対応」と銘打ちました。

実際にどのくらい従来の Javascript と互換性があるかまでは未検証ですが、ECMA-262 3rd に準拠しているなら、prototype や jquery といったライブラリも、そのまま使えるかもしれません。（ブラウザキャッシュが500KBまでなので、必要部分のみに圧縮する必要はありそう）

Cookie 対応

これが一番びっくりした新機能。

RFC 2965 準拠の最小実装で、PCブラウザよりも制限は厳しめですが、セッション管理などを行うなら十分な仕様を満たしています。そう、ついにクッキーを使ったセッション管理ができる！

アクセス解析、視聴率測定、行動ターゲティングなど、幅広い展開が期待できるところ。

今回の対応で、ようやくdocomoでもリファラーの取得ができるようになったことを踏まえ、このあたりは非常に活発化するんじゃないでしょうか。正確な解析ができるようになって ROI を明確にできるようになれば、不況で伸び悩んでいると言われるアフィリエイト、純広枠への出稿の増加や、SEO / SEM への投資を誘導できるかも。モバイル市場拡大につながる可能性から、この cookie 対応には驚かせられました。エポック・メイキング。

さて、今後おそらく他社のブラウザもこの機能性に追従し、上回ってくることを考えれば、PCウェブと携帯ウェブの垣根がほとんど無くなる瞬間というのも、そう遠い未来の話ではなくなるのかもしれないなーと感じています。もちろんその間には、先に挙げたスマートフォンとの競争もあるし、コンテンツプロバイダーの盛衰もあって、にわかには想像しがたい話ですが、「iモード、次の10年」という括りでは夢物語ではないはず。そうなったとき、果たして強いのはPCポータル群か、モバイルコンテンツプロバイダーか、それとも。

一方、現在に目を移せば、これだけの機能追加が、果たして市場にスムーズに浸透するのかという懸念がありますね。iモードブラウザ1.0 をバージョンアップできるわけではない以上、2.0 対応にどれだけのコストを割いていくかの判断を、コンテンツプロバイダーは迫られるわけで。

そんな折に、こんなニュース。

「docomo PRIME series N-06A」の一時販売停止及び「docomo STYLE series N-08A」の販売延期のお知らせ

ブラウザに脆弱性があったということらしいですが、Javascript と cookie に対応したら、そういったセキュリティ面での問題がナーバスでしょう。セキュリティ対応という、コンテンツプロバイダーに求められる技術レベルが高くなれば、それも 2.0 対応コンテンツ普及への足かせとなりうるわけです。この販売停止騒動で、衝撃をくらったコンテンツプロバイダーも多かったんじゃないでしょうか？

だらだら書いてきましたが、Android 携帯をふくめ、今年夏以降のモバイル市場の変化には敏感でありたいですね。面白くなりそうです。（その前に、某バンクが夏を超えられるかという噂も聞きますが...）

関連記事

iモード2.0に見るドコモ様の不敵な態度