【问题标题】:Mysql Percona backup is shutting down the mysql instanceMysql Percona 备份正在关闭 mysql 实例
【发布时间】:2020-02-13 17:58:23
【问题描述】:

我正在运行我的 mysql 数据库的基本备份。我不确定它为什么要关闭。我收到备份完成消息,准备完成后我正在完成。但是实例仍然崩溃。我正在运行两个实例,我只在备份一个。

xtrabackup --defaults-file=/etc/alternatives/my.cnf --defaults-group=mysqld5 --socket=/var/run/mysqld/db5.sock --user=mysqladmin --password=password --backup --throttle 400 --target-dir=/mysqlbackup/current --no-timestamp 2> /var/backup.log;

我收集日志文件以确保它已完成并且确实完成了。然后我运行准备

xtrabackup --prepare --use-memory=5G --target-dir=/mysqlbackup/current 2 >> /var/backup.log;

我的日志文件有

xtrabackup: cd to /mysqlbackup/current
xtrabackup: This target seems to be not prepared yet.                                                                                                                                                                                                                                                                                                                           

Doing recovery: scanned up to log sequence number 5642017177088 (8%)
Doing recovery: scanned up to log sequence number 5642076559654 (99%)
Database was not shutdown normally
Starting crash recovery
Progress in percent: 0 1 2 ... 99
Apply batch completed
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.                                                                                                                                                                                                                                                                                                
InnoDB: 32 non-redo rollback segment(s) are active.                                                                                                                                                                                                                                                                                                                              
InnoDB: page_cleaner: 1000ms intended loop took 748935ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)                                                                                                                                                                                                                                         
InnoDB: 5.7.26 started; log sequence number 5642076559654 
xtrabackup: Last MySQL binlog file position 7017599, file name binlog.000009
xtrabackup: Recovered WSREP position: febfad99-09fe-11ea-ad83-57c73422d738:27384750                                                                                                                                                                                                                                                                                              
xtrabackup: starting shutdown with innodb_fast_shutdown = 1                                                                                                                                                                                                                                                                                                                      
InnoDB: FTS optimize thread exiting.                                                                                                                                                                                                                                                                                                                                             
InnoDB: Starting shutdown...                                                                                                                                                                                                                                                                                                                                                     
InnoDB: Shutdown completed; log sequence number 5642076561674                                                                                                                                                                                                                                                                                                                    
InnoDB: Number of pools: 1                                      
xtrabackup:   innodb_data_home_dir = . 
InnoDB: New log files created, LSN=5642076561674
InnoDB: Doing recovery: scanned up to log sequence number 5642076561941 (0%) 
InnoDB: Database was not shutdown normally! 
InnoDB: Starting crash recovery
InnoDB: Starting shutdown...                                                                                                                                                                                                                                                                                                                                                     
InnoDB: Shutdown completed; log sequence number 5642076561960                                                                                                                                                                                                                                                                                                                    
200213 08:05:36 completed OK!  

【问题讨论】:

  • percona.com/doc/percona-xtrabackup/8.0/… "它会复制您的 InnoDB 数据文件,这会导致数据内部不一致;但随后会对文件执行崩溃恢复,以使它们再次成为一致、可用的数据库。"跨度>
  • 崩溃恢复结束后,数据库应准备好连接。 dev.mysql.com/doc/refman/8.0/en/…
  • 备份后您的数据库实际上还没有准备好连接吗?就像,您必须再次手动启动它?如果有,您的服务器有多少 RAM?
  • 是的,我必须手动启动 mysql。我有 120 次演出的 ram

标签: mysql percona


【解决方案1】:

连接到您正在运行的 MySQL 服务器,并在客户端中运行它:

mysql> SHOW STATUS LIKE 'Uptime';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Uptime        | 268121 |
+---------------+--------+

该值是自您的 MySQL 服务器上次启动以来的秒数(我上面显示的示例来自我自己笔记本电脑上的 mysql,计算结果为 74 小时,这是我上次重新启动的时间)。

我认为您会发现 uptime 值表明您的 MySQL 服务器在备份期间一直运行良好。

Percona XtraBackup 不会重新启动您的 MySQL 服务器。它重新启动自己的 InnoDB 引擎,以针对刚刚备份的文件模拟崩溃恢复。

XtraBackup 使用了大量从 MySQL 本身的 InnoDB 引擎借用的代码,因此它保持与 InnoDB 文件格式的兼容性。它使用 InnoDB 的崩溃恢复功能来“准备”其 InnoDB 文件的副本,以解决任何未完成的事务。

通过借用 InnoDB 引擎的代码,输出类似的消息。

【讨论】:

  • 备份和准备工作完成后,我必须手动重启 mysql 实例。所以服务器宕机了。检查时间给我19576,大约是5 hours
  • 这对于 XtraBackup 来说是不正常的体验。在我的工作中,我们每晚在数千个 MySQL 实例上使用 XtraBackup,它不会导致它们宕机。我的猜测是当你做--use-memory=5G时它太多了,导致mysqld进程由于系统内存耗尽而崩溃。
  • 我最近刚刚添加了--use-memory=5G 以阻止崩溃。网络管理员说 oom Killer 正在被解雇,这正在杀死 mysql
  • 使用pstop 计算你的mysqld 进程正在使用多少内存,使用freetop 计算你有多少内存可用。您可以自行管理内存使用情况,以免超出服务器上的物理内存。
  • “网络管理员说 oom Killer 正在被解雇,这正在杀死 mysql” 这将是包含在您的问题中的很好的信息......它似乎回答了它。
猜你喜欢
  • 2020-11-23
  • 1970-01-01
  • 2013-06-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-07-24
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多