需要一些康复的帮助
所以我走了，做了一件可怕的错事，太匆忙了，没有好好思考。我有一个PXC (percona集群)。我猜mysql集群有Galera?)运行时，只有一个正在引导(已经不好)作为生产服务器运行。
现在，我们收到了一位同事的请求，他迫切需要从大约一周前的数据库中恢复一些数据，因为他想从数据库中恢复一些设置。我们不使用xtrabackup或mysqldumps等进行任何备份。但我们确实拍了LVM的快照。因此，我尝试从我正在运行的另一个(测试) mysql服务器上的特定数据库恢复文件。但是因为它不是PXC，所以恢复经常失败。
我决定在PXC上创建一个新的数据库(让我们将它命名为DB-B)，运行我想要的数据库的mysqldump (让我们命名为DB-A)，将它导入到新的数据库中。删除该数据库目录中的文件，然后从LVM备份中复制数据库目录中的文件。
当然，PXC集群立即崩溃(因为我忘记关闭它)，系统无法再次启动。现在，根据我所掌握的少量MySQL知识，我猜这是因为innodb仍然跟踪ibdata文件中的文件和seqno。
现在，在日志中，我可以看到，这是防止PXC再次启动的问题。即使使用所有的innodb_force_recovery设置1-5，我也会得到以下错误：
2020-07-01T11:36:11.840315Z 13339321 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=535955, page number=4], should be [page id: space=620409, page number=4]
2020-07-01T11:36:11.840385Z 13339321 [ERROR] InnoDB: Trying to access page number 1630627123 in space 620409, space name DB-B/liveuser_authlog, which is outside the tablespace bounds. Byte offset 0, len 16384, i/o type read. If you get this error at mysqld startup, please check that your my.cnf matches the ibdata files that you have in the MySQL server.现在，如果我设置innodb_force_recovery=6 (我知道这是不好的)，那么PXC就会启动。但我知道是DB-B数据库造成了问题，我希望我能把它删除。重新启动服务器，我可以在新的一天后悔我所有的错误。但是，当我试图在删除DB-B数据库之后启动它时，我一直收到以下错误：
2020-07-01T13:18:40.771446Z 0 [Warning] InnoDB: Tablespace 620453 was not found at ./DB-B/mail_queue.ibd, and innodb_force_recovery was set. All redo log for this tablespace will be ignored!
2020-07-01T13:18:40.949631Z 0 [ERROR] [FATAL] InnoDB: Missing MLOG_FILE_NAME or MLOG_FILE_DELETE for redo log record 39 (page 559566:3) at 3425204536239
2020-07-01 08:18:40 0x7f5a56830880 InnoDB: Assertion failure in thread 140025975212160 in file ut0ut.cc line 943有什么办法可以通过在某个地方删除DB记录并重新启动这个PXC，然后尝试在其他地方恢复这个数据库来解决这个问题吗？总之，整个DB数据库不是生产数据库，所以我不介意删除它。
我的配置：
#
# The Percona XtraDB Cluster 5.7 configuration file.
#
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
# Please make any edits and changes to the appropriate sectional files
# included below.
#
!includedir /etc/my.cnf.d/
!includedir /etc/percona-xtradb-cluster.conf.d/
# Node/SQL Settings
[mysqld]
server-id=1
port=3306
datadir=/mysql-data/data
socket=/mysql-data/mysql.sock
pid-file=/var/run/mysqld/mysqld.pid
innodb_force_recovery=6
max_allowed_packet=1G
sql_mode="NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
log_output=file
slow_query_log=ON
long_query_time=0
log_slow_rate_limit=100
log_slow_rate_type=query
log_slow_verbosity=full
log_slow_admin_statements=ON
log_slow_slave_statements=ON
slow_query_log_always_write_time=1
slow_query_log_use_global_control=all
innodb_monitor_enable=all
userstat=1
innodb_stats_on_metadata=0
max_connections = 2048
# InnoDB Settings
innodb_buffer_pool_size = 24G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
optimizer_switch="derived_merge=off"
# PXC Cluster Settings
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_name=ams-clus
wsrep_cluster_address=gcomm://ip1,ip2,ip3
wsrep_node_name=name-1
wsrep_node_address=ip1
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=usr:passwd
pxc_strict_mode=DISABLED
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2回答 1
Database Administration用户
发布于 2020-07-02 16:08:57
所以我能从这件事中恢复过来。我会把这个留给遇到同样事情的人。
PXC无法启动并返回错误的部分：
2020-07-01T13:18:40.949631Z 0 [ERROR] [FATAL] InnoDB: Missing MLOG_FILE_NAME or MLOG_FILE_DELETE for redo log record 39 (page 559566:3) at 3425204536239似乎是一个与PXC (Percona)或MySQL相关的bug。然而，它与损坏的InnoDB表直接相关。在InnoDB重做日志中，最有可能出错的地方是它试图恢复数据不再存在的表。
此时我唯一的选择是设置innodb_force_recovery=6以避免要触发的重做日志，并继续将所有数据库从此服务器转储到mysqldump。在这个阶段，您无法从这个恢复模式中恢复，因为恢复模式6(从MySQL5.6和我认为是以后的)将mode引擎设置为只读模式。
https://dba.stackexchange.com/questions/270191
复制相似问题
腾讯云开发者
