mysqlのデータベースを復元したが全てのテーブルのレコードが0件になっている！

mysqlのデータベースを復元したのですが、SQLでテーブルを確認するとレコードが0件になっていました。
実際のテーブルファイル自体は10メガ以上あるものもあるため、何かの設定等が壊れているだけだと思われるのですが、どんな原因が考えられますか。

前の質問が自動的に締め切られてしまったため、タイトルを変更して再度質問させてもらっています。
前の質問をした時にはSQLでのアクセスすらできなかったのですが、パーミッションを777にしたらSQLは通るようになりました。その後660に戻しても問題なくSQLが通るようになりました。これも意味不明です。
前の質問もお読みいただけると幸いです。
https://oshiete.goo.ne.jp/qa/11176576.html

No.6 ベストアンサー 回答者： bx2 回答日時： 2019/07/02 14:20

mysqlhotcopy によるバックアップは、メモリ上のデータをファイルに書き出して、他の人が書き込まないようにテーブルをロックしてから、/var/lib/mysql/ のファイルをコピーします。

だから、復元するときはファイルを元の場所に戻すだけです。復元るときに CREATE 文等は不要です。

正常に復元できないのは、復元する場所（ファイル名）が間違っているか、そもそも、正常にバックアップできていないかです。

mysqlhotcopy によるバックアップは、ストレージエンジンが MyISAM の場合に使用できます。InnoDB には対応していません。

既存テーブルのストレージエンジンは下記コマンドで確認できます。

mysql> show create table テーブル名 \G

mysql> select table_schema, table_name, engine from information_schema.tables ;

この回答へのお礼

そもそも、正常にバックアップできていない気がしてまいりました。
正常にバックアップできていない原因として何が考えられますか。

バックアップの手順としては、次の9行のPerlスクリプト中でmysqlhotcopyを実行しているだけなのです。

#!/usr/bin/perl -w
use strict;
push(@_, (localtime)[3 .. 5]);
system('mysqlhotcopy try /tmp >/dev/null');
chmod(0755, '/tmp/try');
chmod(0644, </tmp/try/*>);
system('sudo -u webmaster scp -r /tmp/try cat:mysql/try' . join('_', $_[2] - 100, $_[1] + 1, $_[0]) . ' >/dev/null');
unlink(</tmp/try/*>);
rmdir('/tmp/try')

mysqlhotcopyで作成されたディレクトリーを日付つきの名前に変更してリモートホストへ退避させているだけで、特段あやしい箇所は無いと思われるのです。
やはり日本語のテーブル名がmysqlhotcopyの実行結果に悪影響を与えているのでしょうか？？？
ちょっと実験してみます。

お礼日時：2019/07/03 01:08

No.5 回答者： ぐーるぐる 回答日時： 2019/07/02 13:43

とりあえず、Accessとか、Excelあるでしょ？それでリレーション貼って、読み込んでみたら？

dataがあれば、引っ張れるでしょ。

この回答へのお礼

MySQL Connector/ODBCというツールを入れて接続を試みました。
iptablesもSELinuxも停止したのですが、
Connection Failed
[MySQL][ODBC 8.0(a) Driver]Bad handshake:
とエラーメッセージが出て接続できませんでした。

Excelでリレーション貼って、読み込むやり方を教えていただけると・・・^^;

お礼日時：2019/07/03 00:46

No.4 回答者： bx2 回答日時： 2019/07/02 13:17

mysqlhotcopy でバックアップしたファイルを復元するなら、mysqlサービスを停止してから、データファイルを上書きして、mysqlサービスを起動する、などの手順が必要です。

この回答へのお礼

mysqlサービスを停止して復元、停止しないで復元、
復元手順に関しては、データファイルを手動で削除してからコピー、CREATE文でテーブルを作成してから上書きコピー、
ここ数日間で、いろいろ試しているのですが、なかなかうまくいきません。
分かった事といえば、ファイルを手動で削除してからコピーすると、SQLが読み込みエラーで通らないので、CREATE文でテーブルを作成してから上書きコピーした方が良いという事ぐらいでしょうか。
上書きコピーした場合にはSQL自体は通るものの、返ってくるレコードは0件なのです。
あと思い当たることは、テーブル名に日本語を使っており、ファイル名は文字化けしています。
ファイル名の文字化けは正常運用時から発生しているもので、今回のトラブルでは問題視していません。

お礼日時：2019/07/02 13:43

No.3 回答者： ぐーるぐる 回答日時： 2019/07/02 10:59

SQLの書き方が問題でレコード自体が本当に存在するのか、別の方法で確認できてるのかな？

他のアプリとかUIとか。
10メガあるとはいえ、レコード自体が消えてるってことはないですか？

この回答へのお礼

実際にDELETE文でテーブルを初期化してみると、実ファイルが0バイトになることから、レコード自体は存在していると思われます。

mysql> show tables;
+---------------+
| Tables_in_try |
+---------------+
| ユーザー |
| 競走 |
| 結果 |
+---------------+
3 rows in set (0.00 sec)

mysql> select * from `競走`;
Empty set (0.00 sec)

これはSQL実行時のUI画面を、そのままコピーしたものです。
問題を特定するために3テーブルだけ残して、他のテーブルは全て削除しています。

レコード自体が本当に存在するのか、簡単に確認する方法を教えていただければと存じます。

お礼日時：2019/07/02 11:34

No.2 回答者： 長久命の蝶助 回答日時： 2019/07/02 09:23

＞どんな原因が考えられますか。

最後に初期化したw

この回答へのお礼

実際にDELETE文でテーブルを初期化してみると、実ファイルが0バイトになりました。
今回の現象はファイルサイズが10メガもあるのにSELECT文でレコードを検索しても0件になってしまうのです。

お礼日時：2019/07/02 11:17

No.1 回答者： ぐーるぐる 回答日時： 2019/07/02 09:22

全部読んでないけど、単純ミスなことが多いはず。

テーブル名のタイポとかじゃないかな？タイプミスね。

この回答へのお礼

テーブル名のタイポの場合は、そのようなテーブルは存在しませんとエラーメッセージが出るので、タイポではないと思われます。

お礼日時：2019/07/02 09:28