最近要将使用xtrabackup备份的多台MySQL Server的数据还原到另外一台MySQL服务器上并使用不同的端口启动多个实例来作为review环境
最近要将使用xtrabackup备份的多台MySQL Server的数据还原到另外一台MySQL服务器上并使用不同的端口启动多个实例来作为review环境。实用程序执行自动还原的过程中有几个数据库实例启动失败。检查数据目录中的错误日志,发现如下启动错误:
2015-02-02 12:31:36 27876 [Note] Plugin 'FEDERATED' is disabled.
2015-02-02 12:31:36 27876 [Note] InnoDB: The InnoDB memory heap is disabled
2015-02-02 12:31:36 27876 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-02-02 12:31:36 27876 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-02-02 12:31:36 27876 [Note] InnoDB: Using CPU crc32 instructions
2015-02-02 12:31:36 27876 [Note] InnoDB: Initializing buffer pool, size = 500.0M
2015-02-02 12:31:36 27876 [Note] InnoDB: Completed initialization of buffer pool
2015-02-02 12:31:36 27876 [Note] InnoDB: Highest supported file format is Barracuda.
2015-02-02 12:31:36 27876 [Note] InnoDB: The log sequence numbers 13637542590703 and 13637542590703 in ibdata files do not match the log sequence number 13637542595176 in the ib_logfiles!
2015-02-02 12:31:36 27876 [Note] InnoDB: Database was not shutdown normally!
2015-02-02 12:31:36 27876 [Note] InnoDB: Starting crash recovery.
2015-02-02 12:31:36 27876 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-02-02 12:31:37 27876 [Note] InnoDB: Restoring possible half-written data pages
2015-02-02 12:31:37 27876 [Note] InnoDB: from the doublewrite buffer...
2015-02-02 12:31:37 2aeb2d96a590 InnoDB: Error: page 7 log sequence number 36755345241838
InnoDB: is in the future! Current system log sequence number 13637542595176.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB:
InnoDB: for more information.
2015-02-02 12:31:37 2aeb2d96a590 InnoDB: Error: page 1 log sequence number 35468208055287
InnoDB: is in the future! Current system log sequence number 13637542595176.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB:
InnoDB: for more information.
……
是说ibdata文件中的日志序列号与ib_logfiles文件中的日志序列号不一致,启动崩溃恢复过程,从.ibd文件读表空间信息,从双写缓冲恢复数据页。但发现页中的日志序列号超前于当前系统日志序列号。提示数据库可能损毁。或者备份时只备了表空间没备日志文件。因此,推测错误可能发生在两个环节:一备份文件本身损坏了;二备份文件本身没有问题,在应用日志的时候出现了问题。
先从简单的情况验证
手动拉取前一天的xtrabackup全备文件一步步执行还原过程,,在应用日志阶段。发现如下报错:
……
150202 12:36:35 innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_file=/etc/my.cnf;mysql_read_default_group=xtrabackup' as 'usvr_serveradmin' (using password: YES).
150202 12:36:35 innobackupex: Connected to MySQL server
Connected successfully
Can't call method "disconnect" on an undefined value at /usr/bin/innobackupex line 1482.
……
正常情况下当输出complete ok!所以断定是这里出问题了。所有机器都是使用同样的还原程序进行还原的,为什么只有某几台发生这样的问题?经查看,这些机器是安装的MySQL版本为5.6.21,xtrabackup版本为2.2.24。而最终要还原到的MySQL Server实例本身是5.6.12的,xtrabackup版本为2.1.3。
使用xtrabackup2.2.24替换2.1.3后重新对全备文件应用日志,发现可以成功执行。所以最终问题定位到了这里。也即,使用高版本的xtrabackup备份的全备文件,在使用低版本的xtrabackup应用日志时会出问题。(与MySQL Server本身的版本木有必然联系)
但接下来问题又来了,其余的一些机器中也存在少数几台MySQL5.6.21的,xtrabackup版本为2.2.24的。为什么还原成功??观察这几台机器的数据库,发现数据库均为空,这样也就不存在对全备应用日志的情况。因而全备还原会成功。
综上:使用高版本的xtrabackup备的全备在使用低版本的xtrabackup应用日志时存在问题,这一点需注意。
MySQL管理之使用XtraBackup进行热备
MySQL开源备份工具Xtrabackup备份部署
MySQL Xtrabackup备份和恢复
用XtraBackup实现MySQL的主从复制快速部署【主不锁表】
安装和使用 Percona 推出的 Xtrabackup 备份 MySQL
XtraBackup 的详细介绍:请点这里
XtraBackup 的下载地址:请点这里
本文永久更新链接地址:

酸性属性には、原子性、一貫性、分離、耐久性が含まれ、データベース設計の基礎です。 1.原子性は、トランザクションが完全に成功するか、完全に失敗することを保証します。 2.一貫性により、データベースがトランザクションの前後に一貫性を保証します。 3.分離により、トランザクションが互いに干渉しないようにします。 4.永続性により、トランザクションの提出後にデータが永久に保存されることが保証されます。

MySQLは、データベース管理システム(DBMS)であるだけでなく、プログラミング言語にも密接に関連しています。 1)DBMSとして、MySQLはデータを保存、整理、取得するために使用され、インデックスを最適化するとクエリのパフォーマンスが向上する可能性があります。 2)SQLとPythonに埋め込まれたプログラミング言語とSQLalchemyなどのORMツールを使用すると、操作を簡素化できます。 3)パフォーマンスの最適化には、インデックス、クエリ、キャッシュ、ライブラリ、テーブル分割、およびトランザクション管理が含まれます。

MySQLはSQLコマンドを使用してデータを管理します。 1.基本コマンドには、select、挿入、更新、削除が含まれます。 2。高度な使用には、参加、サブクエリ、および集計関数が含まれます。 3.一般的なエラーには、構文、ロジック、パフォーマンスの問題が含まれます。 4。最適化のヒントには、インデックスの使用、Select*の回避、制限の使用が含まれます。

MySQLは、データの保存と管理に適した効率的なリレーショナルデータベース管理システムです。その利点には、高性能クエリ、柔軟なトランザクション処理、豊富なデータ型が含まれます。実際のアプリケーションでは、MySQLはeコマースプラットフォーム、ソーシャルネットワーク、コンテンツ管理システムでよく使用されますが、パフォーマンスの最適化、データセキュリティ、スケーラビリティに注意を払う必要があります。

SQLとMySQLの関係は、標準言語と特定の実装との関係です。 1.SQLは、リレーショナルデータベースの管理と操作に使用される標準言語であり、データの追加、削除、変更、クエリを可能にします。 2.MYSQLは、SQLを運用言語として使用し、効率的なデータストレージと管理を提供する特定のデータベース管理システムです。

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1)タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2)キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3)行はスキャンされた行の数を推定し、クエリのパフォーマンスに影響します。 4)追加の情報を最適化する必要があるというFilesortプロンプトを使用するなど、追加情報を提供します。

Temporaryを使用すると、MySQLクエリに一時テーブルを作成する必要があることが示されています。これは、異なる列、またはインデックスされていない列を使用して順番に一般的に見られます。インデックスの発生を回避し、クエリを書き直し、クエリのパフォーマンスを改善できます。具体的には、expliect出力に使用を使用する場合、MySQLがクエリを処理するために一時テーブルを作成する必要があることを意味します。これは通常、次の場合に発生します。1)個別またはグループビーを使用する場合の重複排除またはグループ化。 2)Orderbyに非インデックス列が含まれているときに並べ替えます。 3)複雑なサブクエリを使用するか、操作に参加します。最適化方法には以下が含まれます。1)OrderbyとGroupB


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

AtomエディタMac版ダウンロード
最も人気のあるオープンソースエディター

MinGW - Minimalist GNU for Windows
このプロジェクトは osdn.net/projects/mingw に移行中です。引き続きそこでフォローしていただけます。 MinGW: GNU Compiler Collection (GCC) のネイティブ Windows ポートであり、ネイティブ Windows アプリケーションを構築するための自由に配布可能なインポート ライブラリとヘッダー ファイルであり、C99 機能をサポートする MSVC ランタイムの拡張機能が含まれています。すべての MinGW ソフトウェアは 64 ビット Windows プラットフォームで実行できます。

EditPlus 中国語クラック版
サイズが小さく、構文の強調表示、コード プロンプト機能はサポートされていません

Dreamweaver Mac版
ビジュアル Web 開発ツール

メモ帳++7.3.1
使いやすく無料のコードエディター
