『売上猫くん on MySQL』開発日記 - 番外6 - リモートのログを mysqlbinlog できない

市販のソフトウェアでログ（MySQLではバイナリログ）からのリカバリ機能を実装しているものはあまり無いような気がする。　以前、某有名財務ソフトのSEに、「ログからのリカバリはできるんですか？」と聞いたことがある。　答えは「そういうのが必要なときは、うちのSEがやりますよ」とのこと。　確かに、下手にユーザがリカバリを行うと大変なことになるので、こういう機能は組み込まないのが正解なのかもしれない。　また、小中規模のデータベースシステムなら、フルバックアップを日に何回か取って、障害発生時には最新のフルバックアップでリストアまでし、最終フルバックアップ以降の更新は、ユーザがせっせと入れる、というが実態なのかとも思う。　また、“ユーザがせってと”できないようなクリティカルなシステムは、自社のシステム管理者や外部のSI業者がしっかりリカバリする体制ができているのだろう。　

さて、『売上猫くん on MySQL』には、一応、バックアップ、フルバックアップからのリストア、バイナリログからのリカバリ機能を実装する予定で、バイナリログからのリカバリをテストしている。　MySQLが載っているサーバ機を使用し、そのサーバ上のログによりリカバリ（mysqlbinlog）を実行するのは、マニュアル通りに動く。　
ところが、ローカルPCからリモートサーバ上のログをリモートサーバに対してリカバリすべく下記を実行すると失敗する。

> mysqlbinlog --disable-log-bin --read-from-remote-server //remote-server/***/log-bin mysql --user=root --password=passord --host=remote-server --database=neko"

例によってググりながら、疑わしきところを弄りながら、異なる2台のサーバに対して試すこと数時間。　どうしても「Misconfigured master - server id was not set」　とか、「error reading packet from server: binary log is not open」みたいなエラーが出力される（この2つのエラーはレプリケーション絡みで出力されるようだが…）。

諦めかけたところ、いきなりプロンプト画面に正常な出力が行われる。データを見ると、確かに更新分が反映されている。そこで実行文を見直してみると、--read-from-remote-server を入れ忘れて実行していた。結果、成功。
--read-from-remote-server はマニュアルによると、「バイナリログをローカルファイルから読み取らずにMySQLサーバから読み取ります」とあるので、このオプションは必要と思ったのだが…

結局、半日以上を費やして、--read-from-remote-server の正しい使用方法は分からずじまいだが、目的は達したので良しとしよう。


関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

『売上猫くん on MySQL』開発日記 - 番外5 - ポータルで検索できない

MySQL等の外部DBを使用し、複数のリレーションを設定したポータル内では、検索を実行できません。　たとえば、売上と売上明細のテーブルを［売上No］と［区分］という二つのフィールドでリレートし、ポータルに売上明細のフィールドを置き、これらで検索しても失敗します。
FMのバグでしょう。


関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

『売上猫くん on MySQL』開発日記 - 番外4 - mysqldump で文字化け？

mysqldumpで作成したテキスト(ｓｑｌ)ファイルを WordPad で開いてみる。　文字化けだらけ。
MySQLクライアントを使用しても、phpMyAdmin を使用しても結果は変わらず。ただ、phpMyAdminで実行結果を画面に出力するとちゃんと表示される奇怪。
「mysqldump 文字化け」でググってみるといろいろと記事があり、それを見ながら --default-character-set やら、my.ini やらでいろいろ試してみるが解決には至らず。　
半日ほど頑張ってみたが埒があかないので、念のため、隣の人に聞いてみた。すると「WordPadを使ってませんか？」　。　「はぁ？」　、固まる小生。　WordPadって、NotePadの上位エディタじゃないの？　NotePadで　確かに、NotePadは UTF-8とUnicodeの保存オプションがあるのに、 WordPadにはUnicodeのみ。　読み込みできるキャラクタセットが違うらしい。 WordPad のUnicodeはUTF-16LE対応.
Notepadはこれに加えてUTF-8対応。　あー、とんんだ恥さらし記事だけど、小生の同類がいるかもしれないので、恥を忍んで上げておこう。


関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

『売上猫くん on MySQL』開発日記 - 番外3 - 0を書き込みできない

売上明細テーブル（ vw_salesdtls）のInt型のフィールド（balanceFlg）に値を書き込もうとする。他の値は書き込みできるのだが、“0”の書き込みが実行できない。　ログで何が起こっているのか確認する。

Commitに失敗している場合はバイナリログには記録されないので、mysqlbinlog は使えない。　そこで、一般ログというものを、

mysql> set global general_log="ON";

で作成してみる。　以下、1を立てて成功したログと、0で失敗したログ（一部抜粋）。

【1立てで成功】
9 Query SELECT ID,`売上番号`,balanceFlg, ～略～ FROM vw_salesdtls WHERE ID=8340 FOR UPDATE
9 Query UPDATE vw_salesdtls SET balanceFlg=1 WHERE ID=8340

【0立てで失敗】
8 Query SELECT ID,`売上番号`,balanceFlg, ～略～ FROM vw_salesdtls WHERE ID=8341

失敗したほうでは、なぜか FOR UPDATE 以下が発行されず、当然これでは更新できない。　当初はInnoDB側に何か問題があるのかと疑ったが、FileMakerが適切なクエリを発行していないことがわかった。　ちなみに、類似した他のテーブルでは、1、0の値に関係なく、更新(Update)は成功する。

いろいろとやってみた。FMのファイルを修復したり、レイアウトモードにして数字の書式を変更してみたり、フィールド定義を眺めてみたり。　そして、これが FileMaker のバグだと判明。　なんと、FileMaker は　空欄(null)→0　への変更は変更と認識しない、null=0 と認識するのである。　更新と認識しないので、　Update が発行されない。　恐ろしい。

結論
ということで、null と 0 を区別して扱う必要がある場合は、非常に注意が必要だ。 0 を参照キーするのは極力避けるべきた。　MySQL側で初期値を0に設定しておく、というのは一案かもしれない。
ちなみに、上述のように「null=0 と認識」するので、0→空欄lに変更を行っても、コミットすると 0 のままである。



関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

『売上猫くん on MySQL』開発日記 - 番外2 - MySQLミラーサイト

MySQL サイトが今朝から落ちてる。　レファレンスマニュアルが見れない、つまり開発できない。Googleのキャッシュは遅すぎる。　MySQLの全機能を網羅し、信頼の置けるドキュメントはここにしかない（と思う）。「MySQLの開発者はこういうときどうしているのだろう？」等と思いつつ、、、ミラーサイトをみつけた。これタイの大学のサイト。Googleキャッシュよりはずっと早い。　この大学のトップページにはなぜか秋篠宮殿下が…



関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

『売上猫くん on MySQL』開発日記 - 番外1 - 全データベース削除→リストア

あるサーバにあるデータベースダンプを別のサーバに移動。その後、MySQLのすべてのデータベースを削除し、リストアのテストを行おう思い、まず、

> drop database information_schema
（だったと思う）

を実行してみた。　すると、「information_schemaは削除できない」旨のメッセージが表示される。
その後、mysqlを再起動しようとするとエラーが出て起動しない。　データフォルダをみると、ｍｙｓｑｌを含むすべてのデータベースは削除されている。エラーログをチェック（←これ大事）すると、 mysql データベースは起動に必須らしい。そこで、元のサーバから無理やりこのmysql フォルダをコピーし（サーバ停止無、こんなことやっていいいのか？）、丸ごと、起動しなくなった別サーバ内にコピー。　その後は再起動できた（ここまで半日潰れる）。

そこで、

> show databases

を実行すると、やはり表示されるのは、mysql データベースのみ。　そこで、コマンドプロンプトからリストアを実行すると、以下のようなエラーが出る。

InnoDB: Error: table test/parent already exists in InnoDB internal
InnoDB: data dictionary. Have you deleted the .frm file
InnoDB: and not used DROP TABLE? Have you used DROP DATABASE
InnoDB: for InnoDB tables in MySQL version <= 3.23.43? InnoDB: See the Restrictions section of the InnoDB manual. InnoDB: You can drop the orphaned table inside InnoDB by InnoDB: creating an InnoDB table with the same name in another
InnoDB: database and moving the .frm file to the current database.
InnoDB: Then MySQL thinks the table exists, and DROP TABLE will
InnoDB: succeed.

InnoDB内部の記録と不整合があるらしいので、一旦、同名の空のデータベースを作成し、それを削除したあとにもう一度リストアをやってみるとやっと成功。　めでたし、めでたし

参考サイト：トラブルシューティング InnoDB データ ディクショナリ操作



関連リンク：『売上猫くん on MySQL』開発日記の記事一覧