エンタープライズ生産環境データベースバックアップロックテーブルの問題
MySQLデータベースシーンでmysqldumpコマンドを使用してバックアップすると、ロックテーブルの問題に遭遇しますか?ロックテーブルを行うと、バックアップ中にユーザーがアクセスできなくなり、バックアップ時間が数時間長くなると、数時間以内にユーザーがデータにアクセスできなくなり、ビジネスに大きな影響を与えることを示します.テーブルをロックしないと、バックアップ中にデータが書き込まれる可能性があるため、バックアップ後のバックアップファイルのデータが目的の時点のデータであることを保証できません.
ロックテーブルの問題を解決するにはどうすればいいですか?MySQLバックアップの場合、テーブルをロックする必要があるかどうかは、会社のビジネスシーンに基づいて分析します.ケース1:ある金融コンサルティング会社では、会社のお客様はselectを主とし、つまりクエリーを主とし、会社のデータはほとんど社内導入であり、会社のデータベースエンジンはハイブリッドエンジン、MyIsamとInnodbの2種類のストレージエンジンのテーブルである.このようなビジネスシーンでは、テーブルをロックせずにデータベースを直接バックアップし、binlogログを使用してデータの一貫性(インクリメンタルバックアップ)を保証できます.MySQLのデフォルトは「lock-tables」パラメータがオンになっているため、テーブルをロックする必要がない場合は、このパラメータであるskip-lock-tablesを閉じます.LOCK TABLESでテーブルに明示的にロックをかける場合、テーブルに関連するすべてのロックを同時に取得しなければならない.すなわち、LOCK TABLESを実行した後、明示的にロックをかけたテーブルにしかアクセスできず、ロックをかけていないテーブルにアクセスできない.また、リードロックが追加されている場合は、ロックテーブルのクエリー操作しか実行できません.MyISAMは常にSQL文に必要なすべてのロックを一度に取得します.これもMyISAMテーブルにデッドロック(Deadlock Free)が現れない理由です.
ケース2:ユーザーがデータの更新が頻繁なビジネスシーンでmysqldumpコマンドを使用してMySQLデータベースをバックアップし、ロックテーブルの機能を使用してデータの一貫性を保証することができる.しかし、ロック・テーブルのバックアップ中にユーザーがデータに正常にアクセスおよび更新できないという問題が発生しました.このような場面に対しては、業務の低迷時にバックアップを行うことをお勧めします.いわゆる月黒風高殺人夜ですね.もう1つのより良い解決策は、プライマリ・セカンダリ・レプリケーションを行い、ライブラリからバックアップを行うことです.これにより、ロック・テーブルの影響はより低くなります.インターネット上では、「lock-tables読み取り専用ロック機能」(挿入データを更新できず、データロックテーブルのみを読み取る)を使用してバックアップを行い、binlogログを通じてデータの一貫性を達成するというネットユーザーもいる.これは、大量のデータが挿入される可能性があるシーンでも効果的ではありません.myisamエンジンエンタープライズ生産バックアップコマンド(すべてのエンジンまたはハイブリッドエンジンに適しています):MyISAMエンジンは表レベルのロックであるため、バックアップ時にバックアップ中にデータの書き込みによる不一致を防止する必要があるため、バックアップ時に--lock-all-tables(-x)ロックテーブルを使用します.
innodbエンジン企業生産バックアップ名:InnoDBエンジンは行ロックであるため、バックアップ時にデータベースのロック操作を行わず、オプションであるsingle-transactionを追加してバックアップすることができる.いくつかの要件があります.innodbエンジンのみです.エクスポート中、alter table、drop table、rename table、truncate tableなどのDDL文を誰にも実行できません.実際にDDLは、トランザクションがテーブルのmetadata lockの共有ロックを持っているため、DDLがmetadata lockの反発ロックを申請するため、トランザクションにブロックされます.
不適切な点があれば、よろしくお願いします.
mysqldumpパラメータの詳細:https://blog.51cto.com/13691477/2149675MySQLロックの知識:https://blog.csdn.net/mysteryhaohao/article/details/51669741
ロックテーブルの問題を解決するにはどうすればいいですか?MySQLバックアップの場合、テーブルをロックする必要があるかどうかは、会社のビジネスシーンに基づいて分析します.ケース1:ある金融コンサルティング会社では、会社のお客様はselectを主とし、つまりクエリーを主とし、会社のデータはほとんど社内導入であり、会社のデータベースエンジンはハイブリッドエンジン、MyIsamとInnodbの2種類のストレージエンジンのテーブルである.このようなビジネスシーンでは、テーブルをロックせずにデータベースを直接バックアップし、binlogログを使用してデータの一貫性(インクリメンタルバックアップ)を保証できます.MySQLのデフォルトは「lock-tables」パラメータがオンになっているため、テーブルをロックする必要がない場合は、このパラメータであるskip-lock-tablesを閉じます.LOCK TABLESでテーブルに明示的にロックをかける場合、テーブルに関連するすべてのロックを同時に取得しなければならない.すなわち、LOCK TABLESを実行した後、明示的にロックをかけたテーブルにしかアクセスできず、ロックをかけていないテーブルにアクセスできない.また、リードロックが追加されている場合は、ロックテーブルのクエリー操作しか実行できません.MyISAMは常にSQL文に必要なすべてのロックを一度に取得します.これもMyISAMテーブルにデッドロック(Deadlock Free)が現れない理由です.
# MyIsam
mysqldump -uroot -p -A -B -F -R --skip-lock-tables --events|gzip >/tmp/all_$(date +%F).sql.gzケース2:ユーザーがデータの更新が頻繁なビジネスシーンでmysqldumpコマンドを使用してMySQLデータベースをバックアップし、ロックテーブルの機能を使用してデータの一貫性を保証することができる.しかし、ロック・テーブルのバックアップ中にユーザーがデータに正常にアクセスおよび更新できないという問題が発生しました.このような場面に対しては、業務の低迷時にバックアップを行うことをお勧めします.いわゆる月黒風高殺人夜ですね.もう1つのより良い解決策は、プライマリ・セカンダリ・レプリケーションを行い、ライブラリからバックアップを行うことです.これにより、ロック・テーブルの影響はより低くなります.インターネット上では、「lock-tables読み取り専用ロック機能」(挿入データを更新できず、データロックテーブルのみを読み取る)を使用してバックアップを行い、binlogログを通じてデータの一貫性を達成するというネットユーザーもいる.これは、大量のデータが挿入される可能性があるシーンでも効果的ではありません.myisamエンジンエンタープライズ生産バックアップコマンド(すべてのエンジンまたはハイブリッドエンジンに適しています):MyISAMエンジンは表レベルのロックであるため、バックアップ時にバックアップ中にデータの書き込みによる不一致を防止する必要があるため、バックアップ時に--lock-all-tables(-x)ロックテーブルを使用します.
mysqldump -uroot -p -A -B -F -R -x -events|gzip >/tmp/all_$(date +%F).sql.gzinnodbエンジン企業生産バックアップ名:InnoDBエンジンは行ロックであるため、バックアップ時にデータベースのロック操作を行わず、オプションであるsingle-transactionを追加してバックアップすることができる.いくつかの要件があります.innodbエンジンのみです.エクスポート中、alter table、drop table、rename table、truncate tableなどのDDL文を誰にも実行できません.実際にDDLは、トランザクションがテーブルのmetadata lockの共有ロックを持っているため、DDLがmetadata lockの反発ロックを申請するため、トランザクションにブロックされます.
mysqldump -uroot -p -A -B -F -R --events --single-transaction|gzip >/tmp/all_$(date +%F).sql.gz不適切な点があれば、よろしくお願いします.
mysqldumpパラメータの詳細:https://blog.51cto.com/13691477/2149675MySQLロックの知識:https://blog.csdn.net/mysteryhaohao/article/details/51669741