結局これで良いのでしょうか?

最近は Dockerを触ることもほとんど無くなりました まさしく飽きっぽい 本当に根気がない駄目人間ですねえ

ところで、自分はレンタルサーバーを用いて Webを運用しています 例の以前サーバー情報を運用の誤りで全部消してしまった FirstS*****のレンタルサーバーを用いています いやああの時は大変でした 何しろ全ての情報が消えてしまったのです この時の緊迫した状況をこのブログに書き留めていました しかし、このブログそのものも消失してしまったので、その事故以降の記録ではあります

まあその話は怒りと共に蘇りますが、今はその話ではありません 僕が使用しているレンタルサーバーは Linux上に、Apache Webe Server + PHP + MySQLがついている、というものです つまりいわゆる LAMP (= Linux, Apache, Mysql, Php)なのです しかし、自分には root権限は無く、例えば Rubyを走らせようとしてもそもそも Ruby Interpreterがインストールされていないので動かせません Root権限が無いので、自分でインストールすることもできません こんな環境なので、そもそも Dockerをインストールできないのです

ここまで色々勉強してみると、Dockerなどをインストールしてコンテナとして色々なことを試そうと思えば、どうしても Root権限のあるレンタルサーバーにせねばならないのでしょうね

しかしこの場合には、Portを潰したり、Updateをしたりも自分でせねばならなず そんなに知識が無い自分には不釣り合いです ここまで考察すれば、Dockerなどに手を出す資格が無い、そういうことでしょうかね 残念ですが能力不足なので仕方ありませんね

パリでは忙しくて、そして最後には辛くて

今年も恒例の EuroPCRという世界最大の心臓インターベンションに関するライブデモンストレーションおよび学会がパリ国際会議場で開催されました

僕はこの学会に日本人としては初めて招待者として招かれ、以来毎年20年間に渡り参加しています 以前は毎年のように僕はライブデモンストレーションを飛ばしていたのですが、ここ数年間はライブデモンストレーションを飛ばすことがなかば禁じられ、もっと若い世代がライブデモンストレーションを飛ばすようになっています

実際今回も冠動脈インターベンションのライブデモンストレーションをパネリストなどとして見る機会があったのですが、僕の目からすれば「うーん」というものばかりでした

今回は、5/14の土曜日にパリに入り、翌日5/15日曜日には Tokyo Valves 2017のための Preparatory meetingが 4時間に渡り開催され、その間ずっと日本、ヨーロッパの先生方と英語で討議したのです そして月曜日には Innovators’ dayという秘密会が開催され、そこにも顔を出しました

火曜日、水曜日には自分自身の発表、そしてmoderators、座長などがあり、その合間を縫って主として外国の会社の CEO達と打ち合わせがなされました 本当に忙しかったのです おまけに時差ボケです

自分の発表の模様は TCROSSというサイトに写真が掲載されていますので、画面コピーで貼り付けました

EuroPCR2016 presentation
EuroPCR2016 presentation
EuroPCR2016 presentation-2
EuroPCR2016 presentation-2

そう言えば昨年のこのEuroPCR 2015において僕は Kiemeneij先生と一緒に Ethica Awardという栄誉を受けたのです

それはそうなのですが、5/19の木曜日 3:00AM頃よりお腹が痛くなり、ついには 5:00AMになって激しい嘔吐、下痢そして多分発熱に見舞われたのです 明らかに何らかの食中毒です 潜伏期や食べた内容を考えても良く原因が分かりません 症状などはサルモネラ菌食中毒のように思います フランス料理レストランで食べたチーズに菌がついていたのかも知れませんが確証はありません その症状は結局 48時間後の今朝まで続きました 今はすっかり元気ですが、お蔭で皮膚もカラカラとなり、体重は大分落ちたように思います

phpMyBackupProによるSQL backup dataの文字化け

ついに見つけたツール phpMyBackupProは非常に優れたものです。完璧に SQLでバック・アップが可能なのです。本当に素晴らしいと思います。しかも、フリーでダウンロードできるのです。

ただ、日本語には対応していません。このため、backupしたデータの日本語が文字化けしてしまい、そのままでは使い物になりません。データベースには UTF-8の文字コードでデータが蓄積されているので、phpMyBackupProそのもののデータ読み書きを UTF-8にすれば良いわけです。少しプログラムを見ていくと、どうやら Latinという文字コードがdefaultとして設定されているのです。まあ、どうやらイギリスで開発されているプログラムなので、かの国ではそれが標準なのでしょう。しかし、日本語対応させようと思えば、SJISあるいはEUC-Jという文字コード、そして現在の流れとしては UTF-8に対応せねばなりません。

そもそも Latinという文字コードでは一文字が 1Byte = 8 bitsであらわされます。これに対して、UTF-8では基本的に 3Bytes = 24 bitsで一文字があらわされます。日本語では、文字の数が何万とあるので、情報量として3Bytes必要なのです。

phpMyBackupProで同様の悩みをかかえて、それを解決された方がおられるのでは? と探したところ、やはりありましたね。ここ(A)です

実は、もっと有望な解説も見つけました。それはここ(B)です。このサイトでは、何と日本語化した phpMyBackupProをダウンロードできるようにしていました。しかし、その versionが 2.1とあり、現在の version 2.3よりも古いのが少し気になります。

そこで、(A)を参考に、functions.inc.phpをエディタで開いて、その 636行目に以下の文を発見しました

        // select db
        @mysql_select_db($db);

ここに 2行を追加しました:

        // select db
        @mysql_select_db($db);
		$sql = "SET NAMES utf8";		// utf8に設定する
		$res= mysql_db_query($db,"$sql");

この簡単な追加により、見事に日本語データが文字化けせずにきちんと backupされ、downloadできるようになりました。もっとも、未だテスト段階ですので、このパソコンのローカルに設定した偽装インターネット環境での確認です。

そのようにしてダウンロードした SQL文を用いて、サーバー・データが破壊されても、再構築が完璧にできるか否かを検証したところ、問題がおこりました。

きちんと SQL文では日本語が文字化けせずにダウンロードできているのに、何故か SQL文を実行して再構築すると、データベース上のデータが文字化けするのです。これは変です。 SQL文を読んでもきちんと

DEFAULT CHARSET=utf8

と設定されているのです。そこで吐き出された SQL文を最初から見ると何とその最初に

# http://www.phpMyBackupPro.net

### used character set: Latin ###
set names Latin;

というのを発見しました。折角データをutf8で設定しているのに、肝心の書き込み段階で Latinに設定されているのです。これが原因でした。
それで、この部分の Latin -> utf8に変更したところ、見事に完全データ復旧ができるようになったのです。素晴らしいです。もう少しテストしてからサーバーに実際に uploadしてみます。何はともあれ、今度のサーバー障害により色々なことを学びました。失敗から多くを学び、発展させることができました。

ついに見つけたか

これまで PHP, MySQLを用いて Web上にデータベースを構築してきましたが、そのバック・アップには少し困っていました。

MySQL自体にバック・アップのためのコマンドを持っていますが、それを作動させるためには、コマンド・ラインから起動したりせねばなりません。つまり、まあだいたい LAMPでサーバーを構築していますから、L=Linux, A=Appache, M=MySQL, P=PHP or Perlなので、OSであるLinuxのシェルを直接起動できる権限を有していないとなりません。しかしながら、我々の用いているレンタル・サーバーでは当然のことながらこれは不可能です。
また、PHPより Sytem()コマンドなどで直接MySQLのコマンドを発行することもできますが、それも大概のレンタル・サーバーでは危険な命令語として、禁じられ、潰されています。
となると、最近のレンタル・サーバーには最初からインストールしてある、phpMyAdminという秀逸のツールを用い、その上でデータベースを選択し、エキスポート・コマンドによる SQL dumpを得る、それしか現実的な選択は無くなります。
もちろんこれでこれまでバック・アップしてきたのです。しかし、そこには問題があります。

  1. phpMyAdminを用いればデータベースの全てにアクセスできてしまうので、万が一操作を間違えば全てのデータベース消失という危険な事態になりかねない
  2. 従って、この操作権限を行使するためには、プログラミングについて相当の知識が無いといけない
  3. phpMyAdminの実行を自動スケジュールすることは困難である
  4. phpMyAdminの実行を自動化することも困難である

これらの問題点から 知らない人々からは「どうしてバック・アップを私たちにさせてくれないの?」 などという非難を浴びつつ、そんなこと説明するためにはどれだけたくさんの知識をあらかじめ教授せねばならないの? と、そんな非難を自分の中で噛み潰してきたのです。

次の解決法としては、PHPでデータベースにアクセスするプログラムを書き、データのみをテーブル毎にダンプして、それをバック・アップすることです。もちろんこのプログラム作成はそれ程大変な作業ではありません。しかし、問題点としては、データというものの概念の中に、データ同士の関係、という重要な意味がある、ということなのです。特に MySQLなどの SQLデータベースは、関係データベースと称されるように、個々のテーブルに蓄えられたデータの互いの関連が重要な意味を持っているのです。

このPHPによるデータ・バック・アップでは、個々のテーブルデータをダウンロードすることはできますが、関係そのものを記録することは困難です。そのためには、 SQLにより記述したデータベース構造が必要なのです。 phpMyAdminを用いれば、SQL dumpが可能ですので、個々のテーブルデータのみならず、SQLで記述したデータ構造をもダンプできるのです。従って、データベースから全てが消失してもデータベースの完全復旧が可能なのです。

先日の、サーバー・データ消失事件においても、僕がこの SQL dumpをしていたためにデータ復旧が可能だったのです。これに反して、”Where is Dr. Saito?”で用いていたデータベースでは、このバック・アップがされていなかったため、未だに復旧できていないのです。

前置きはさておいて、ついに見つけました。素晴らしいバック・アップ・ツールを しかも完全にフリーなのです。その名前は、phpMyBackupProです。試みにこれをダウンロードしてローカルにインストールしました。素晴らしい、の一言です。しかし、大きな問題が一つ、それは データの中の日本語が文字化けしているのです。

まあ、これはMySQLにアクセスする部分でUTF-8を指定するようにプログラムを書きなおせば済むでしょう。何しろ、この優れたツールは全て PHPで記述された膨大なプログラムなのです。ですから、その部分をエディタで探して、UTF-8指定を入れればいいでしょう。チャレンジしましょう。

サーバー再度の危機

TRI 20周年記念キャラバン初日、本来の予定では何も問題は起こらず、むしろ札幌の先生方とのTRIでの協調が促進され、素晴らしかったのです。

しかし、世の中そんなうまく行きません、それは07/02 17:15に起こりました。僕はこの札幌でメールを受け取りました。

「これまでのパスワードでログインできない」というクレームです。

そんな馬鹿な、そんなことあり得ない、と思いながら自分のパスワードでログインを試みましたが、確かにログインできないのです。

この時点で再び自分の頭の中は真っ白、「あーーーーー どうすれば」 「臨床試験データが無くなればどれだけの責めを負うか」など色々な思いが駆け巡りました。

既に時刻はこれからKiemeneij先生講演に向かう 18:30に近づいていました。それでも、瞬時に頭を巡らしました。「何が悪かったのが」、そして思い至りました。その直前、自分で書いたプログラムの改良のために、ある部分を uploadしていたのです。その中の configuration fileが現在の本当のパスワードでなく、昔の事故前のものになっていたのです。

それが原因でした。これに気が付き、すぐにそれこそ5分以内に修復したのです。危ない間違いでした。

やっぱりね

今 googleでニュースを見たところ、トップに今回のサーバー障害が掲載されいます。やはり非常に大規模な普通ではあり得ない障害だったようです。

詳細はこれを見て下さい。いや引用してしまいましょう。ヤフーの子会社だそうですね。ヤフーにとってもこれは痛手でしょう。きちんと対応しないと、これまで上り調子の Yahooの看板にも傷がつきそうですね。

ヤフー子会社でレンタルサーバを手がけるファーストサーバの大規模障害で、同社は6月23日、
共有サーバサービスとクラウドサーバサービスについて「データ復旧を行うことは不可能と判断した」
と発表した。専用サーバサービスも短期間でのデータ復旧は不可能とし、仮に復旧できたとして
も部分的にとどまるという。

 データ復旧を断念したのは共有サーバ「ビズ」「ビズ2」と、EC向けクラウドサービスの「
EC-CUBEクラウドサーバ マネージドクラウド」。「弊社ならびに外部専門業者を交え、データ復旧を
試み続けて参りました。しかしながら、極めて遺憾ではございますが、データ復旧を行うことは不可能
と判断いたしました」という。再構築は顧客が持っているバックアップデータで行うよう求めている。

 専用サーバ「エントリービズ」「エンタープライズ3」についても「短期間でのデータ復旧は不可能」
として顧客のバックアップデータで再構築を行うよう要請。復旧できたとして部分的なものにとどまる
上、復旧既刊は数カ月以上必要という。

 今後サービス約款に従って損害賠償を行うが、時期、や手続き、方法などは検討中という。同社の
レンタルサーバサービス約款では「本サービスが本質的に情報の喪失、改変、破壊などの危険が内在
するインターネット通信網を介したサービスであることを理解した上で」顧客が自らの責任でデータ
バックアップを行うものとし、顧客がバックアップしなかったことによる損害について同社は何ら責任
を負わないとしている(16条)。

 障害は20日午後5時以降に発生。大阪市の水族館「海遊館」や小林製薬の製品情報サイトなど多数の
Webサイトがダウンし、サイト上にアップロードされたデータやメールデータが消失した。影響した
顧客数は約5000に上る。原因は「メンテナンス作業において用いる特定の管理プログラムのバグ」
という。

しかし、管理プログラムのバグなんて、許せないですよね。しかも一番重要な専用サーバーがやられたのです。共有レンタルサーバーには障害が発生しなかったのです。何と 5,000サイトですよ。とんでもないことですね。

サーバー・トラブルその後

さてサンパウロからロンドンに飛行機で 12時間飛んでいる間、つまり日本時刻 6/23 12:00頃から 6/24 0:00AM頃にかけて 彼のレンタルサーバー会社から二本のメールが届いていました。その一分を掲載しましょう まずは一本目

     インターネットサーバ 障害復旧のお知らせ

平素は格別のご高配を賜り厚く御礼申し上げます。6月20日に発生いたしましたWEB・メールなどデータ
が消失したインターネットサーバー障害にて、多大なるご迷惑をおかけし誠に申し訳ございません。

ご利用いただいておりますサーバーにおきまして、障害発生時に消失したデータを復元いたしましたが、
不具合があることが判明したため、一旦メール受信・FTPサービスを停止し、サーバー修復作業を実施
いたしました。
現在はメール受信・FTPサービスの復旧を確認いたしております。
ご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。

記

■障害時間  2012年6月22日(金) 午後 9:30 頃から
■障害復旧  2012年6月23日(土) 午前 4:43 頃まで
■障害内容  上記時間内において、メール受信操作やFTPサーバーへアクセス
ができない状況でございました。また、WEBサーバーは正常に稼働しておりました。
■障害原因  リカバリーデータの不具合

■対応経緯
1) メール受信、FTPサーバー機能の停止を行いました。
2) 6月20日以前のリカバリーデータより復元した、各アカウントのメール
データのみ削除いたしました。6月21日の再設定完了以降、各アカウント宛
に届いたメールにつきましては問題ございませんでした。
3) 「RECOVERED_FILES」ディレクトリでご提供しておりました、リカバリー
データにつきまして、不具合を発見したため削除いたしました。
4) メール受信、FTPサーバー機能を再開し正常稼働を確認いたしました。

6月20日から発生している障害状況のご報告つきましては、改めてお知らせいた
します。

引き続きサーバー設定の見直しを含め安定稼働をめざし調整を行ってまいります。

以上

全く、こっちが必死でリカバーしたのに、それを台無しにするようなリカバーを勝手にするんじゃないよ!! そして二本目のメールはもっと腹立たしいものです

            専用サービスをお使いのお客様へのお願いとご案内

平素は格別のご高配を賜り厚く御礼申し上げます。

6月20日に発生いたしましたWEB・メールなどデータが消失したインターネット
サーバー障害にて、多大なるご迷惑をおかけし誠に申し訳ございません。

障害発生以来、弊社ならびに外部専門業者を交え、データ復旧を試み続けて参
りましたが、極めて遺憾ではございますが、短期間でのデータ復旧は不可能で
あることが判明いたしました。

データ復旧にかかる期間が長期に及ぶことが判明いたしましたので、今後はお
客様からのご要望を元にデータ復旧作業を行わせていただきたく存じます。

データ復旧をご希望のお客様はお手数ですが、以下の内容を本メールの返信に
てお知らせください。あらためて詳細なご案内を差し上げます。

 -----------------------------------------------------------------
  契約番号 :
  契約者名 :
  ご担当者名:
  ドメイン名:
  連絡先電話番号:
 -----------------------------------------------------------------

※ご留意事項
  データを完全に復旧することは技術的に不可能であり、仮に復旧できた場
  合でも復旧データの精度、量は相当部分的なものにとどまるものと想定さ
  れ、復旧に要します期間につきましては数ヶ月以上要します。

お手数ではございますが、以下サイトにて詳細な情報をご案内しておりますの
でご確認ください。

どう思いますか? これではまるで脅しメールのようではありませんか
まあ、この会社もとんでもないことが起こってしまい、大変混乱しているのでしょう。だって今後大規模な損害賠償請求訴訟が当然起こるでしょうから・・・

サーバー復旧作業その後

何とかサーバー復旧しました。ひどい話です。突然全てのデータが完全に消失したのです。全てのデータとは

  1. ホームベージのデータ これにはhtml, css, Javascript, jQuery, cgiなどのデータやプログラムが含まれます
  2. 膨大なプログラム群 これにはPHP, Javascript, jQuery, SQLなどで書かれたプログラムがあります
  3. データベースに蓄えられたデータそのもの これはDatabase MySQLの中に格納されたデータです
  4. サーバーの各種設定 これにはデータベース接続、メール、FTPなどのユーザーネームとパスワードがあります

これら全てが一瞬にして無くなったのです。まずは4番から設定に入りました。そして、次に MySQLを開始させました。MySQLといえどもLinux Server上で走るプログラムの一つですのでまず走らせねばなりません。一旦走らせたらば、永久に走り続けるのです。そして、その MySQL上にバックアップしてあった 2012-05-23までのデータを含んだ SQL文を転送し、そしてSQLを実行しました。これでひとまずデータベースがその時点まで復旧しました。3の部分の復旧です。

次に行ったのは、2番です。膨大な主にPHPで書かれたプログラムを uploadしました。もともとサーバー側では PHPの実行プログラム (インタープリーター)が走っていますので、それでもう書いたプログラムが走り始めました。

最後にしたのは 1番です。これでブラウザからアクセス可能となりました。

ここまでの作業は正直それ程時間がかかる作業ではなく、主に uploadにかかる時間に依存します。つまり回線速度に依存しました。だいたい 1時間ぐらいでした。

問題はそれからでした。5-24から6-20までに登録されたデータがあります。この中で重要なものは、無作為割付を含んだ症例です。幸いプログラムが、登録があれば、あるメルアドに「登録がありました」という情報を送るようにしてありました。もちろん個人を同定できる情報は含まれません。このメールは消去せず蓄積していましたので、そのデータを用いて症例登録をすることにしました。

ただ、このためにはデータベースの色々なテーブルを参照しながらデータを作成せねばなりません。とても手作業でできる仕事ではありませんので、そのように PHPでプログラムを書かねばなりませんでした。時差ボケの中、しかもインターネット接続が不安定の中、大変な作業であり、効率の悪いものでしたので、これに 10時間ぐらいがかかってしまったのです。

そしてようやく出来る範囲最大限のデータ復活を成し遂げました。次に行ったのは、それらのデータが復活したことを、登録して頂いた先生方にメールで知らせることでした。これも手作業でできる仕事ではありませんので、プログラムを書かねばなりませんでした。自動的にメールを発信するプログラムは結構難しいのです。それでも2時間ぐらいで完成し、走らせました。

もう少しチューニングが必要かも知れません。何れにしても大変な経験をしました。バックアップを毎日のように取る必要があるかも知れませんね。

Salvadorでとんでもない事態に遭遇

先の原発事故では、「想定外の」という言葉が問題となりました。今回、この日本の反対側サルバドールで僕にとっては「想定外の」事態に遭遇することになりました。

時差ボケの中、ここまで四時間かけて出来る範囲で手を打ちました。大変な作業でした。

急性心筋梗塞の再灌流療法として、非薬剤溶出性ステントによる再灌流か、薬剤溶出性ステントによる再灌流かどちらが有効かを明らかにする研究者主導型臨床試験である、NAUSICA AMI臨床試験を皆のご協力により走らせています。この試験においては、無駄を排除し、経費節減を図るために、その登録サイトの全てを私自身がプログラム書いています。言語は、PHP, Javascript, Perl, XHTML, CSSです。

そして、そのサイトを運用するために、信頼のおけるレンタルサーバー会社のサーバーを占有でレンタルし、ドメインも特定非営利活動法人ティー・アール・アイ国際ネットワークから独自に取得して開設しています。

もちろん、データのバックアップも頻回ではありませんが、定期的に行なってきました。まさか、そのレンタルサーバー会社の運用で事故が起こるとは全く想定していなかったのです。しかし、日本時刻 6/20 17:00頃より、サイトにアクセスできなくなった、との一報がもたらされました。

もちろん僕はこのサルバドールです。「まさかそんなことあり得ない」と、思いながらアクセスすると、そのドメイン名は存在しない、とのエラーが返されます。サイトの管理画面にアクセスしようとしても同様です。この時点で考えたことは、ひょっとしてこの tri-international.orgというドメイン名の契約が切れているのでは? と思いました。そこで調査するとその可能性も否定しきれないので、早速契約更新を依頼しました。

しかし、事態はもっと深刻だったのです。数時間前にこんなメールが送られてきました。

【重要】6月20日に発生のサーバー障害についてのご報告

平素は格別のご高配を賜り厚く御礼申し上げます。

この度はご利用いただいているサーバーに、障害が発生し長時間に渡りご利用
いただけない状況となり、誠に申し訳ございません。
また、本件についてのご報告が大変遅くなり重ねてお詫び申し上げます。

本障害では弊社メンテナンス作業において用いる特定の管理プログラムにバグ
があり、お客様データが消失したことが判明いたしました。

消失したデータの復旧作業を進めておりましたが、データの復旧にはなお時間
を要することを確認いたしました。
早期にサービスを復旧させるため、サーバーを初期状態に戻し、現時点で可能
な範囲での復旧作業を実施しサービスを再開することといたしました。

お客様には大変ご迷惑をおかけすることとなり、心苦しく存じますが、何卒
ご了承いただきますようお願い申し上げます。

なお、データの復旧作業は総力をあげ継続しております。

誠に恐縮ではございますが、弊社でのデータ復旧作業とは別にお客様にて以下
に記載のサーバー初期設定方法をご確認いただき、メール送受信ならびに WEB
コンテンツの公開作業をお願いいたします。

   ■発生日時 2012年6月20日 17時ごろより

   ■発生原因 運用管理ツールの不具合

   ■事  象 サーバー上のデータの消失

まさしくガーンと衝撃でした。ということは、データベース上のデータも消失しているに違いない、何しろサーバーを初期化するのだから・・・

早速このパソコンにあるローカルのデータベースを参照しました。最後のバックアップは 5/17でした。ということは、それ以降の登録データが消失しているのです。管理者としては今更ジタバタしても仕方ありません。責任の追求などは後にするとして、とにかく可及的速やかに現状復帰をせねばなりません。早速この MacBook Proを用いて、サーバーデータを uploadしました。このマシンで行うのは初めてでしたので、少し手間取りましたが、何とか復旧しました。そして、 5/17までのデータについてはupdateしました。

念の為に復旧した画面を確認して下さい。

特定非営利活動法人ティー・アール・アイ国際ネットワークのホームページは http://www.tri-international.orgです。

そして、NAUSICA AMI臨床試験サイトは https://www.tri-international.org/ami/です。

失われたデータに関しては、これから個々に対応するしかありません。全く想定外の事態でした。もちろんこの事故に関しては IRBにも報告する義務があります。

本日はこのサルバドールでライブデモンストレーションの術者をせねばなりませんが、全くそれどころではありませんでした。ここまで復旧し、この後ライブデモンストレーションに向けて心を落ち着かせねばなりません。目の前のことに全力を尽くさねば人間として失礼に当たります。もう時差ボケなんて言ってられません。