MySQLパフォーマンスのチューニングとアーキテクチャ設計(4):バックアップとリカバリ

14887 ワード

バックアップリカバリバックアップバックアップと復元 mysql

前言

データベースのバックアップとリカバリは、DBA作業の中で最も重要な部分であり、基本的な作業の一つでもあります.

正式な環境のデータベースには、完全なバックアップ計画とリカバリテストが必要です.この章では、主にMySQLデータベースのバックアップとリカバリに関する内容について説明します.

データベースのバックアップシーンの使用

データベースのバックアップは、いくつかの理由で一部または全部のデータが失われた場合、失われたデータを取り戻すのに便利です.

しかし、異なるタイプのデータベースバックアップでは、対応できる状況が異なり、データベースのバックアップは他にも多くの役割を果たしています.

次に、データベースのバックアップに使用する必要があるいくつかの比較的一般的な状況

（1）        ：
    【1】                ；
    【2】  BUG            ；
    【3】                  ；
    【4】              ； 
（2）          ：
    【1】                 ； 
    【2】           
    【3】           ； 
    【4】         ；

を列挙する.
論理バックアップとリカバリテスト
一、論理バックアップの前言

皆さんご存知のように、データベースはデータを返して私たちに使用するとき、私たちが最初に設計した一定の論理関連フォーマットの形式に従って1つ1つのデータを示しています.一定のビジネスロジック属性を持っています.物理ストレージの面では、データベースソフトウェアはデータベースソフトウェアによって設計された特定のフォーマットに従って一定の処理を経て保存されています.

データベースの論理バックアップとは、バックアップソフトウェアが私たちが最初に設計した論理関係に従って、データベースの論理構造オブジェクト単位で、データベース内のデータを予め定義された論理関連フォーマットに従って1つ1つの関連テキストファイルを生成し、バックアップの目的を達成することである.

論理バックアップは最も簡単であり、現在中小規模システムで最もよく使われているバックアップ方式でもある.

mysqlでよく使われる論理バックアップは主に2つで、1つはデータを現在のデータベースのデータを完全に再現できるINSERT文を生成し、もう1つは私たちのデータベースのテーブルデータを論理バックアップソフトウェアを通じて、特定の区切り記号で区切ってテキストファイルに記録することです.

二、よく使うロジックバックアップ

INSERT文バックアップ

（1） mysql ，        mysql             mysqldump     INSERT         。
（2）      ：Dumping definition and data mysql database or table
mysqldump [OPTIONS] database [tables] 
OR   mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...] 
OR   mysqldump [OPTIONS] --all-databases [OPTIONS] 
（3）  mysqldump         ，               “mysqldump --help”   。
（4）       MySQL                      mysqldump                              。
（5）     ，                   ，                    ，                  。
（6）             ，                     。
（7）                                 ，  mysqldump                                             INSERT          。
（8）          ，          ，                  ，        ymsqldump          。
（9）                     ，                 。
（10）                       ，                                ，            。
（11）      ，      ？    ，          ，             ：
    【1】          
         「1」       ，      ，    ？    ，         ，         ，                。
         「2」  ，                       ，        ，       ，                        。
         「3」  ，           ， Innodb  BDB ，                         ，               ，  mysqldump                      ，    “--single-transaction”  ，               。
    【2】             。
         「1」    ，         ，           。
         「2」                    ，       ，                     ， mysqldump            ，           。
         「3」mysqldump             “--lock-tables” “--lock-all-tables”，         ，           。
         「4」         ，“--lock-tables”         dump      ，               ，                 ，     “--lock-all-tables”            。
（12）         “--master-data[=value]”
    【1】   mysqldump  INSERT          ，                 ，   “--master-data[=value]”。
    【2】    “--master-data=1”   ，mysqldump    mysql   binlog           dump   ，    CHANGE_MASTER       ，        “--master-data”  “--master-data=2”， CHANGE_MASTER          。
    【3】       slave              ，          slave，                     binlog        。
（13）  “--where=where-condition”
    【1】      ，                         ，                  ，       mysqldump “--where=where-condition”   ；
    【2】       dump         
（14）    ：
    【1】“no-data“    dump         
    【2】“--no-create-info“  dump

を生成

特定のフォーマットのプレーンテキストバックアップデータファイルバックアップ

（1）    INSERT          ，                                        ，          。
（2）        INSERT      ，            ，          ，    。
（3）                       ，            。
（4）           ，                       ，                       。
（5）          ：
    【1】    SELECT ... TO OUTFILE FROM ...     
         「1」mysql      SELECT  ，      sql                    ，                                   。
         「2」            ：
              《1》         “FIELDS ESCAPED BY ['name']”               ；
              《2》             “FIELDS [OPTIONALLY] ENCLOSED BY 'name'”，     “OPTIONALLY”                 “  ”，  “OPTIONALLY”  ，               “  ”。 
              《3》  "FIELDS TERMINATED BY"               ；
              《4》   “LINES TERMINATED BY”    MySQL                      。
    【2】  mysqldump   
         「1」       mysqldump           INSERT             ，       INSERT    ，mysqldump        “SELECT ... TO OUTFILE FROM ...”      ，                        。
         「2」          dump，                   。
         「3」mysqldump -uroot -T/tmp/mysqldump test test_outfile --fields-enclosed-by=\" --fields-terminated-by=,

を生成する.
三、論理バックアップの回復方法

バックアップがあるだけでは十分ではありません.これらのバックアップの使用方法を知らなければなりません.次に、上記の論理バックアップのリカバリ方法を見てみましょう.

すべてのバックアップデータは、私たちの最初のデータベース構造の設計に関連する形式で格納されているため、論理バックアップのリカバリも比較的簡単です.

では、2つの異なる論理バックアップ形式について、リカバリ方法も少し異なります.

の2つの論理バックアップのリカバリ方法:

（1）INSERT       ：
    【1】 INSERT                 ，                SQL    。
    【2】         ，          “mysql < backup.sql”                 ，             。
    【3】        mysql，        mysql   “source/path/backup.sql”  “\./path/baclup.sql”     。
（2）          ：
    【1】             ，          。
    【2】                   ，                        。
    【3】        ，    “LOAD DATA INFILE”     ，         mysql     mysqldump   。

四、論理バックアップは何ができますか.何ができないの?

論理バックアップにより、関連するsqlまたはコマンドを実行することで、関連しないデータに影響を与えることなく、データベース内の関連データをバックアップ時の状態に完全に復元できます.

フルライブラリの論理バックアップにより、mysqlが置かれているプラットフォームの制限を受けずに、新しいmysql交換でバックアップ時と同じデータベースを完全に再構築できます.

特定の条件下での論理バックアップにより、特定のデータを他のmysqlまたは他のデータベース環境に簡単に移行(または同期)できます.

論理バックアップにより、すべてのリカバリを必要とせずに、バックアップセットの一部のデータのみをリカバリできます.

論理バックアップでは、バックアップ時刻以外の時刻にデータをリカバリできません.

五、論理バックアップ回復テスト

は、シミュレーションリカバリテストを周期的に行い、バックアップセットが本当に有効であるかどうか、バックアップの予想通りにリカバリできるかどうかを確認します.

リカバリテストはどうすればいいですか?本当にオンラインのデータを復元できませんか?はい、オンライン上のデータは確かに回復できませんが、テスト環境や他の場所で行うことができます.バックアップが有効であるかどうか、予想に達しているかどうかを確認し、回復後、データを抽出して手動で検査すればいいです.

物理バックアップとリカバリテスト
一、どのようなバックアップがデータベース物理バックアップですか.

物理バックアップである以上、データベースの物理オブジェクトに対応しているに違いありません.論理バックアップは、ビジネスロジックに基づいて設計されたデータベースロジックオブジェクトに基づいて設計されたバックアップと同様に、データベースの物理バックアップは、データベースの物理オブジェクトに対するバックアップです.

データベースの物理オブジェクトは、主にデータベースの物理データファイル、ログファイル、プロファイルなどから構成されます.

mysqlデータベースでは、mysqlシステムが共有するログファイルとシステムテーブルのデータファイルのほか、ストレージエンジンごとに異なる物理オブジェクトがあります.

次に、集中的に使用されるストレージエンジンのそれぞれに対応する物理オブジェクト(物理ファイル)を詳細にリストし、各ストレージエンジンが物理バックアップを行うときにどのファイルがバックアップを必要とし、バックアップを必要としないのかを明確に知ることができます.

二、物理バックアップに必要なファイル

MyISAMストレージエンジン:

（1）MyISAM             MySQL       “datadir”   。
（2）           myisam          ，         “datadir”         。
（3）          MyISAM              ，            “.frm”  ，      “.MYD”  ，         “.MYI”  。
（4）  MyISAM             ，            。
（5）  MyISAM         ，    mysql           ，               。

InnoDBストレージエンジン:

（1）Innodb            ，             MyISAM        ，         Innodb        。
（2）  Innodb          “innodb_data_home_dir”、“innodb_data_file_path” “innodb_log_group_home_dir”           ，        innodb           “innodb_file_per_table”。                    ，        innodb                         。
（3）                 ，  Innodb    “innodb_data_home_dir” “innodb_data_file_path”            ，“datadir”            Innodb      “.frm”  。
（4）             ，                           ，       “datadir”            “.idb”  ，                Innodb        。
（5）       ，          ，                “    ”      ？
（6）              ，            Innodb         “datadir”          “.idb”   。
（7）         ，“.idb”                 ，      ，Innodb        ，    undo redo   ，   Innodb                       ，      undo              ，     “innodb_data_home_dir” “innodb_data_file_path”              。
（8）    ，Innodb      redo               “innodb_log_group_home_dir”        。    innodb        ，       “innodb_log_group_home_dir”            。

NDB Clusterストレージエンジン:

（1）NDB Cluster                     ：
    【1】   （Metadata）：                ；
    【2】   （Table Records）：         ；
    【3】      （Transtaction Log）：           ，               。
（2）          ，    NDB Cluster             ，               ，                             。  ，       ，             ，     。

三、各ストレージエンジンの常用物理バックアップ方法

は、ストレージエンジンによってバックアップが必要な物理オブジェクト(ファイル)が異なり、データファイルに対するストレージエンジンごとの一貫性の要求も異なるため、各ストレージエンジンが物理バックアップを行う際に使用するバックアップ方法にも違いがある.

もちろん、もし私たちが冷たいバックアップ(データベースを停止した後のバックアップ)をするならば、私たちがしなければならないことはすべて簡単です.それは、すべてのデータファイルとログファイルをバックアップセットに保存する必要がある場所に直接copyすればいいということです.どのストレージエンジンでもそうすることができます.

実際のアプリケーション環境では、日常的なバックアップを停止できることはめったにありません.データベースがサービスを提供している場合にのみ、データベースのバックアップを完了することができます.これが一般的なホット物理バックアップです.

各ストレージエンジンで最も一般的なホット物理バックアップ方法:

（1）MyISAM    ：
    【1】       MyISAM               ，         redo undo  ，                ，  MyISAM              ，   MyISAM     copy    。
    【2】  MyISAM          ，           Innodb           ，  MyISAM                             。
    【3】 MyISAM                       ，            ，          ，  ，            。
    【4】  ，                            ，              ？          ，                               ，              MyISAM            MyISAM         ，       ，                    。
    【5】MySQL         mysqlhotcopy，           MyISAM     。
    【6】        MyISAM             ，              ，         ，    mysqlhotcopy           ，    ：mysqlhotcopy db_name[./table_regex/] [new_db_name | directory]
    【7】mysqlhotcopy           ，     ，                           。                               。
    【8】mysqlhotcopy   perl       ，         LOCK  ，    FLUSH TABLES  ，            ，  fsync   fsyn，      OS     （cp ）  ，                              。
    【9】  ，         mysql     ，                          ，      copy  ，       session（         ）
（2）InnoDB    ：
    【1】InnoDB              ， redo   undo  ，                 MyISAM    ，  InnoDB       MyISAM       ，                 ，        InnoDB           。
    【2】InnoDB        （Innobase  ）       ibbackup       ，    InnoDB               。
    【3】ibbackup     MySQL        ，       InnoDB          ，       InnoDB      。
（3）NDB Cluster    ：
    【1】NDB Cluster             ， InnoDB   redo  。
    【2】NDB Cluster             ，           。  ，            。
    【3】         ：
         「1」        ；
         「2」        “START BACKUP”  ；
         「3」             ，                   ，       ；
         「4」                                     。               ，          。
         「5」                ，        “    ”       。
    【4】  NDB Cluster   ，            ，              ，          “Ctrl + c”             ，  NDB Cluster                      。
    【5】      ：
         「1」      ；
         「2」  “ABOT BACKUP backup_id”，    backup_id                ；
         「3」        “       backup_id”      ，  ，                      。
         「4」                         ，                           ，    “  backup_id ***   ”。
         「5」  ，        。
    【6】  NDB Cluster           ，                        ，             ，    ：
         「1」BACKUP-backup_id.node_id.ctl，                    。                       。
         「2」BACKUP-backup_id-n.node_id.data，      ，             ，      ，                     ，                        ，                    ，           。
         「3」BACKUP-backup_id.node_id.log，                      ，                 ，                ，                        。
         「4」   backup_id     ，                  ，node_id                 ，             n       。

四、各ストレージエンジンの常用物理バックアップ回復方法

以前の論理バックアップと同様に、バックアップがあるだけでは意味がなく、効率的なリカバリをバックアップできる必要があります.

物理バックアップは論理バックアップと比較して最大の利点は、主に物理ファイルのコピーであるため、バックアップファイルをリカバリが必要な場所にコピーし、簡単な操作を行えばよいため、リカバリ速度が速いことです.

MyISAMストレージエンジン:

（1）MyISAM     ，           。
（2）                                  ，                                               。
（3）     mysqlhotcopy           ，                       ，                    。

InnoDBストレージエンジン:

（1）     ，Innodb                           ，         （           ）          。
（2）                  ，                 。
（3）    ibbackup      ，                ，                     。

NDB Clusterストレージエンジン:

（1）      ，                   ，                                        ，            。
（2）   NDB Cluster               ，             ndb_restore   。
（3）ndb_restore                   ，  ndb_restore                  。                  ，          ndb_restore。
（4）      ndb_restore       ，        ，              。

バックアップポリシーの設計構想

バックアップが完全であるかどうか、要件を満たしているかどうか、重要なのは設計されたバックアップポリシーが合理的であるかどうか、およびバックアップ操作が設計されたバックアップポリシーに従って行われているかどうかです.

は、用途によって必要なバックアップタイプが異なるため、必要なバックアップポリシーも異なります.

オンラインアプリケーションのデータ損失に対応するためには、バックアップを迅速にリカバリする必要があります.また、インクリメンタルリカバリだけで必要なデータをリカバリできることが望ましいです.このようなニーズに対しては、オンラインでリカバリが一部遅延しているバックアップ用データベースが望ましい.

は、必要なデータを最短時間で取り戻すことができ、一部のハードウェアデバイスに障害が発生した場合でも、代替ライブラリを直接開発して対外的にサービスを提供することができるからです.

もちろん、リソースが不足している場合、このバックアップの責任を負うのに十分なバックアップハードウェアデバイスを見つけることが難しい場合、物理バックアップによって解決することもできます.結局、物理バックアップのリカバリ速度は論理バックアップのリカバリ速度よりも速いです.

で、データ損失のないアプリケーションシーンでは、ほとんどの場合、リカバリ速度の要件はそれほど高くありません.完全に利用可能なデータベースをリカバリできればいいです.したがって、物理バックアップでも論理バックアップでも影響は大きくありません.

は、ニーズに応じて異なるレベルで、

（1）             ，            MySQL           ，          ，            ，                     。                      ，                  。 
（2）              ，            ，        ，                    MySQL，                      ，     （          ）              。                ，           。                  。
（3）               ，                ，                      ，             。                            ，          ，              。

（4）                  ，                     ，               ，                   。

という合理的なバックアップポリシーを設計するために、次のいくつかの考え方を使用します.
まとめ:

総じて、MySQLのバックアップとリカバリは複雑ではなく、方法も単一です.論理バックアップはともかく、物理バックアップにとっては、まだ十分ではありません.オープンソースの比較的良いオンラインホット物理バックアップソフトウェアが欠けているのは、MySQLの比較的大きな残念なことであり、すべてのMySQLユーザーが憂鬱なことでもある.

もちろん、オープンソースのバックアップソフトウェアが使用されていません.非オープンソースのビジネスソフトウェアもあります.有名なZmandaバックアップリカバリソフトウェアのように、機能は比較的全面的で、使用も複雑ではありません.ビジネスのMySQLバックアップリカバリソフトウェア市場では高いシェアを持っています.また、Zmandaはコミュニティバージョンの無料ダウンロードも提供しています.

しかし、少し慰めになるのはMySQLが実際の応用シーンでは1台以上のSlaveマシンをホットとして備えていることが多いことです.バックアップが必要なときにSlaveでバックアップするのも難しくありませんし、Slave上のSQLスレッドを一時停止することで、Slaveマシンにすべてのデータ書き込み操作を停止させ、オンラインでバックアップ操作を行うことができます.だから商用ソフトが買えなくても、あまり買いたくなくても関係は大きくありません.

リファレンスリンク
https://www.cnblogs.com/jesse...

C言語における文字配列の初期化のいくつかの方法

Table'xxx'is marked as crashed and should be repaired解決方法