mysql-デフォルトデータベースmysql,performance_schemaが誤って削除されたテストケース
3238 ワード
前提:イントラネットテストライブラリのデフォルトデータベースmsql,performance_schemaはうっかり削除された.新しいカスタムデータベースmcc_が作成されました2013_user、ストレージ・プロシージャの作成準備中にエラーが発生しました.ヒントmysql.Procが見つかりません.その後、データ辞書テーブルにエラーがあるのではなく、システム全体のデフォルトのデータベースがdropによって削除されていることがわかりました.
注意:バックアップはありません.
1.最初のステップでは、同じ2つのデータベース・ファイルをコピーします.
>>システムデフォルトデータベースの手動作成
私は手動で同じ名前のデータベースを作成して、データベースの中で同じ名前のデータベースの辞書の表を創立して、ストレージの過程は順調に作成することができますか?答え:はい、データベースを再起動しない限り、エラーは表示されません.データベースは一時的に借用され、チェックされません.
それから私はまたmcc_2013_userデータベースには、テーブルベースのタイミングタスクがいくつか作成されています.
データベースが再起動すると、ログにイベント対応のユーザーm 1が見つからず、バイナリログファイルが急増し、ディスクディレクトリが一気に97%に上昇した.
ログインシステムはps-ef|grep mysqlプロセスを検索するが、mysql-um 1-p-S/tmp/mysq.socksは全然入れない.悲しいことにmysqlのrootパスワードも忘れてしまった.覚えていても入れないだろう.データ辞書表が認識されていないからだ.
>>外部ネットワーク・データベースから同じ名前のシステム・デフォルト・データベースをコピー
圧縮コマンドでパッケージ:zip-r mysql-performance.zip mysql performance_schemaは、イントラネットデータベースにコピーし、dataディレクトリに解凍します.
質問:2つのデータベースのバージョンが異なり、イントラネットは5.1で、外部ネットは5.5です.結果はどうなのか分からないが、やってみなければならない.
このときデータベースを閉じてみますが、閉じることはできません.まずrootのパスワードを取り戻して話したいと思っています.
2.ステップ2、rootパスワードのリセット
>>Mysqlプロファイルを変更するmy.cnf: # vi/date/mysql/3306/my.cnf[mysqld]のセグメントにskip-grant-tablesという文を付ける
>>データベースmysqlを再起動して、データベースは今閉鎖できなくて、また登れなくて、どうしますか、mysqlのプロセスを調べて、1つの死の決意を下して、killコマンドでプロセスを殺しました.その後、データベースは不思議に再開されました.イントラネットデータベースのおかげで、そうする勇気がない.>>MySQLのrootパスワード#/date/mysql/bin/mysql mysql>use mysqlにログインして変更します.mysql> update user set password = password ( 'root') where user = 'root' ; mysql> flush privileges ; >>mysqlのmy.cnfプロファイルのskip-grant-tablesコメントを削除するか、削除します.データベースを再起動します.
このステップは成功し、コピーしたデータベースファイルも認識されました.rootユーザーもログインできます.次に、binlogログをクリーンアップします.
3.ステップ3 binlogのクリーンアップ
>>binlog情報の照会
show binary logs,発見最後のログは000359.
>>最後のログを除くbinlogをすべて削除します.
mysql> purge binary logs to 'mysql-bin.000359';
Query OK, 0 rows affected (0.00 sec)
--binlogリストが表示され、ログが1つ残っていますmysql>show binary logsG Log_name: mysql-bin.000359 File_size: 106
--binlog eventsの表示
mysql> show binlog events\G Log_name: mysql-bin.000359 Pos: 4 Event_type: Format_desc Server_id: 1
End_log_pos: 106 Info: Server ver: 5.1.36-log, Binlog ver: 4
>>mysql binlogログを自動的にクリーンアップし、myを構成するように設定します.cnf:expire_logs_days = 5 .
最後のステップでは、現在保持されている最後のログを含まないすべてのログをクリーンアップします.この一歩はまた間違った.私はすべてのログを整理しました.バックアップを忘れました.バックアップは重要で、すべてより重要で、データベースが再び閉じた後、また起きられません.エラー:mysqld_safe mysqld from pid file/data/mysql/3306/mysql.pid ended.
どうしようかな?考えて、バイナリログファイルを閉じてみることにしました.
3.ステップ4 binlogを完全に閉じる
データベースの再起動に成功しました.その後、log-binログのパスを変更しました.shutdownデータベースを1回起動した後、バイナリログファイルを再適用します.
今度はデータベースが完全に復元された.使用を再開する.
小結:初めて自分でこのような故障を処理しました.イントラネットテストライブラリですが.プロセスを完了すると、考え方は少しはっきりしていて、コピーされたデフォルトのデータベースは外部ネットワークテストライブラリで、たぶん同じですが、ユーザー名のuserデータ辞書表を保存して、rootのパスワードを認識しないで、再設定しなければなりません.データ辞書表に全く違うものがあれば、ユーザーだけでなく、ストレージプロセス、イベント、おそらく再作成しなければならないと思います.バージョンの問題が心配され始めましたが、今から見れば、高バージョンは低バージョンと互換性があるようです.もう一つの試みはbinlogを利用して他の削除されたデータベースを復元するテーブルを作ることです.しかし、ネット上でこれを見るのはちょっと面倒です.今度実験をします.binlogをよく研究してください.
注意:バックアップはありません.
1.最初のステップでは、同じ2つのデータベース・ファイルをコピーします.
>>システムデフォルトデータベースの手動作成
私は手動で同じ名前のデータベースを作成して、データベースの中で同じ名前のデータベースの辞書の表を創立して、ストレージの過程は順調に作成することができますか?答え:はい、データベースを再起動しない限り、エラーは表示されません.データベースは一時的に借用され、チェックされません.
それから私はまたmcc_2013_userデータベースには、テーブルベースのタイミングタスクがいくつか作成されています.
データベースが再起動すると、ログにイベント対応のユーザーm 1が見つからず、バイナリログファイルが急増し、ディスクディレクトリが一気に97%に上昇した.
ログインシステムはps-ef|grep mysqlプロセスを検索するが、mysql-um 1-p-S/tmp/mysq.socksは全然入れない.悲しいことにmysqlのrootパスワードも忘れてしまった.覚えていても入れないだろう.データ辞書表が認識されていないからだ.
>>外部ネットワーク・データベースから同じ名前のシステム・デフォルト・データベースをコピー
圧縮コマンドでパッケージ:zip-r mysql-performance.zip mysql performance_schemaは、イントラネットデータベースにコピーし、dataディレクトリに解凍します.
質問:2つのデータベースのバージョンが異なり、イントラネットは5.1で、外部ネットは5.5です.結果はどうなのか分からないが、やってみなければならない.
このときデータベースを閉じてみますが、閉じることはできません.まずrootのパスワードを取り戻して話したいと思っています.
2.ステップ2、rootパスワードのリセット
>>Mysqlプロファイルを変更するmy.cnf: # vi/date/mysql/3306/my.cnf[mysqld]のセグメントにskip-grant-tablesという文を付ける
>>データベースmysqlを再起動して、データベースは今閉鎖できなくて、また登れなくて、どうしますか、mysqlのプロセスを調べて、1つの死の決意を下して、killコマンドでプロセスを殺しました.その後、データベースは不思議に再開されました.イントラネットデータベースのおかげで、そうする勇気がない.>>MySQLのrootパスワード#/date/mysql/bin/mysql mysql>use mysqlにログインして変更します.mysql> update user set password = password ( 'root') where user = 'root' ; mysql> flush privileges ; >>mysqlのmy.cnfプロファイルのskip-grant-tablesコメントを削除するか、削除します.データベースを再起動します.
このステップは成功し、コピーしたデータベースファイルも認識されました.rootユーザーもログインできます.次に、binlogログをクリーンアップします.
3.ステップ3 binlogのクリーンアップ
>>binlog情報の照会
show binary logs,発見最後のログは000359.
>>最後のログを除くbinlogをすべて削除します.
mysql> purge binary logs to 'mysql-bin.000359';
Query OK, 0 rows affected (0.00 sec)
--binlogリストが表示され、ログが1つ残っていますmysql>show binary logsG Log_name: mysql-bin.000359 File_size: 106
--binlog eventsの表示
mysql> show binlog events\G Log_name: mysql-bin.000359 Pos: 4 Event_type: Format_desc Server_id: 1
End_log_pos: 106 Info: Server ver: 5.1.36-log, Binlog ver: 4
>>mysql binlogログを自動的にクリーンアップし、myを構成するように設定します.cnf:expire_logs_days = 5 .
最後のステップでは、現在保持されている最後のログを含まないすべてのログをクリーンアップします.この一歩はまた間違った.私はすべてのログを整理しました.バックアップを忘れました.バックアップは重要で、すべてより重要で、データベースが再び閉じた後、また起きられません.エラー:mysqld_safe mysqld from pid file/data/mysql/3306/mysql.pid ended.
どうしようかな?考えて、バイナリログファイルを閉じてみることにしました.
3.ステップ4 binlogを完全に閉じる
mysql ： log-bin=mysql-bin binlog_format=mixed データベースの再起動に成功しました.その後、log-binログのパスを変更しました.shutdownデータベースを1回起動した後、バイナリログファイルを再適用します.
今度はデータベースが完全に復元された.使用を再開する.
小結:初めて自分でこのような故障を処理しました.イントラネットテストライブラリですが.プロセスを完了すると、考え方は少しはっきりしていて、コピーされたデフォルトのデータベースは外部ネットワークテストライブラリで、たぶん同じですが、ユーザー名のuserデータ辞書表を保存して、rootのパスワードを認識しないで、再設定しなければなりません.データ辞書表に全く違うものがあれば、ユーザーだけでなく、ストレージプロセス、イベント、おそらく再作成しなければならないと思います.バージョンの問題が心配され始めましたが、今から見れば、高バージョンは低バージョンと互換性があるようです.もう一つの試みはbinlogを利用して他の削除されたデータベースを復元するテーブルを作ることです.しかし、ネット上でこれを見るのはちょっと面倒です.今度実験をします.binlogをよく研究してください.