MYSQL备份比较常用的2种方式

在工作中我们数据库可能会遭遇各式各样的不测(硬件故障、软件故障、黑客攻击、误操作占比最大)从而导致数据丢失,下面给小伙伴介绍一下MYSQL备份比较常用的2种方式

MYSQL备份比较常用的2种方式

 

一、使用cp进行备份

查看数据库的信息

mysql> SHOW DATABASES;    
+--------------------+
| Database           |
+--------------------+
| information_schema |
| employees          |
| mysql              |
| test               |
+--------------------+
3 rows in set (0.00 sec)

mysql> USE employees;
Database changed
mysql> SHOW TABLES;         
+---------------------+
| Tables_in_employees |
+---------------------+
| departments         |
| dept_emp            |
| dept_manager        |
| employees           |
| salaries            |
| titles              |
+---------------------+
5 rows in set (0.00 sec)

mysql> SELECT COUNT(*) FROM employees;   
+----------+
| COUNT(*) |
+----------+
|   300026 |
+----------+
2 row in set (0.05 sec)

备份数据文件

[root@node1 ~]# mkdir /backup   #创建文件夹存放备份数据库文件
[root@node1 ~]# cp -a /var/lib/mysql/* /backup     #保留权限的拷贝源数据文件
[root@node1 ~]# ls /backup   
employees  ibdata1  ib_logfile0  ib_logfile1  mysql  mysql.sock  test

数据恢复

[root@node1 ~]# cp -a /backup/* /var/lib/mysql/    #将备份的数据文件拷贝回去
[root@node1 ~]# service mysqld restart  #重启MySQL



mysql> SHOW DATABASES;    
+--------------------+
| Database           |
+--------------------+
| information_schema |
| employees          |
| mysql              |
| test               |
+--------------------+
4 rows in set (0.00 sec)

mysql> USE employees;      

mysql> SELECT COUNT(*) FROM employees;   
+----------+
| COUNT(*) |
+----------+
|   300024 |
+----------+
1 row in set (0.06 sec)


##完成

这里使用的是使用yum安装的mysql-5.1的版本

二、使用Xtrabackup备份

备份过程

[root@node1 ~]# mkdir /extrabackup  #创建备份目录
[root@node1 ~]# innobackupex --user=root /extrabackup/ #备份数据
###################提示complete表示成功*********************

[root@node1 ~]# ls /extrabackup/  
2021-09-27_07-30-48 

备份完成后, 数据不能用于恢复操作因此我们需要准备一个完全备份

root@node1 ~]# innobackupex --apply-log /extrabackup/2021-09-27_07-30-48 /  #指定备份文件的目录

InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 369661462
160427 07:40:11 completed OK!

[root@node1 ~]# cd /extrabackup/2016-04-27_07-30-48/
[root@node1 2021-09-27_07-30-48 ]# ls -hl  #查看备份文件
total 31M
-rw-r----- 1 root root  386 Apr 27 07:30 backup-my.cnf
drwx------ 2 root root 4.0K Apr 27 07:30 employees
-rw-r----- 1 root root  18M Apr 27 07:40 ibdata1
-rw-r--r-- 1 root root 5.0M Apr 27 07:40 ib_logfile0
-rw-r--r-- 1 root root 5.0M Apr 27 07:40 ib_logfile1
drwx------ 2 root root 4.0K Apr 27 07:30 mysql
drwx------ 2 root root 4.0K Apr 27 07:30 performance_schema
drwx------ 2 root root 4.0K Apr 27 07:30 test
-rw-r----- 1 root root   25 Apr 27 07:30 xtrabackup_binlog_info
-rw-r--r-- 1 root root   27 Apr 27 07:40 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root  118 Apr 27 07:40 xtrabackup_checkpoints
-rw-r----- 1 root root  471 Apr 27 07:30 xtrabackup_info
-rw-r----- 1 root root 2.0M Apr 27 07:40 xtrabackup_logfile

恢复数据

[root@node1 ~]# rm -rf /data/* 



[root@node1 ~]# innobackupex --copy-back /extrabackup/2016-04-27_07-30-48/   #


[root@node1 data]# killall mysqld

[root@node1 ~]# chown -R mysql:mysql ./* 
[root@node1 ~]# ll /data/     
total 28704
-rw-rw---- 1 mysql mysql    16384 Apr 27 07:43 aria_log.00000001
-rw-rw---- 1 mysql mysql       52 Apr 27 07:43 aria_log_control
-rw-rw---- 1 mysql mysql 18874368 Apr 27 07:43 ibdata1
-rw-rw---- 1 mysql mysql  5242880 Apr 27 07:43 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 Apr 27 07:43 ib_logfile1
-rw-rw---- 1 mysql mysql      264 Apr 27 07:43 mysql-bin.000001
-rw-rw---- 1 mysql mysql       19 Apr 27 07:43 mysql-bin.index
-rw-r----- 1 mysql mysql     2166 Apr 27 07:43 node1.anyisalin.com.err


[root@node1 data]# service mysqld restart
MySQL server PID file could not be found!                  [FAILED]
Starting MySQL.                                           [  OK  ]

MariaDB [(none)]> SHOW DATABASES; 
+--------------------+
| Database           |
+--------------------+
| information_schema |
| employees          |
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec

使用CP进行备份,备份速度快、恢复速度也很快但是功能相对比较弱一般用于少量数据备份,但是xtrabackup 进行备份功能强大对于备份规模比较大的来说比较实用。

以上就是关于“MYSQL备份比较常用的2种方式”的相关解答如需购买测试PHP主机,推荐酷番云共享虚拟主机、独享IP虚拟主机齐备,各类配置均有,满足不同网站建设需求;另外提供免费虚拟主机,可供测试,让您快速上线网站。

选购地址:https://www.kufanyun.com/host/

图片来源于AI模型,如侵权请联系管理员。作者:路飞,如若转载,请注明出处:https://www.kufanyun.com/ask/1080.html

(0)
上一篇 2021年9月27日 16:42
下一篇 2021年9月29日 15:29

相关推荐

  • 立思辰3731cdn传送带清零,背后原因是什么?技术故障还是另有隐情?

    在信息技术高速发展的今天,数据传输和存储的安全性与效率显得尤为重要,立思辰3731cdn传送带清零事件,无疑为我们敲响了警钟,也提醒了我们在数据传输过程中需要更加注重安全防护,本文将围绕立思辰3731cdn传送带清零事件,分析其背景、影响及防范措施,事件背景立思辰3731cdn传送带清零事件,是指立思辰公司旗下……

    2025年11月8日
    01360
  • 如何监控ASP.NET连接池?关键疑问点与解决方法全解析?

    ASP.NET连接池是数据库连接复用的重要机制,通过维护一个连接池对象管理数据库连接,减少连接创建和销毁的开销,显著提升应用性能,连接池配置不当或运行异常会导致资源浪费、性能瓶颈甚至系统故障,对ASP.NET连接池进行有效监控至关重要,本文将从连接池基础、监控重要性、方法与实践、经验案例等方面展开,结合酷番云云……

    2026年1月11日
    0960
    • 服务器间歇性无响应是什么原因?如何排查解决?

      根源分析、排查逻辑与解决方案服务器间歇性无响应是IT运维中常见的复杂问题,指服务器在特定场景下(如高并发时段、特定操作触发时)出现短暂无响应、延迟或服务中断,而非持续性的宕机,这类问题对业务连续性、用户体验和系统稳定性构成直接威胁,需结合多维度因素深入排查与解决,常见原因分析:从硬件到软件的多维溯源服务器间歇性……

      2026年1月10日
      020
  • 如何高效实现ASP.NET的增删改功能?常见问题与解决方案详解。

    ASP.NET增删改:核心机制、技术实现与最佳实践ASP.NET作为微软主流的Web开发框架,增删改(CRUD)操作是其构建动态Web应用的基础,本文系统阐述ASP.NET中增、删、改的技术实现逻辑,结合酷番云的实际案例,从专业视角解析CRUD操作的关键细节,助力开发者深入理解并高效应用ASP.NET的CRUD……

    2026年1月11日
    0940
  • CDN究竟是什么,为什么没有它网站加载速度会很慢?

    想象一下,你在网上购物,这家电商公司的总部仓库在北京,而你在海南,每次你下单,商品都得从北京千里迢迢地寄过来,不仅慢,而且万一北京仓库出了问题,你就收不到货了,这家公司在全国各地都建立了分仓,你的订单直接从离你最近的广州仓库发货,速度快多了,即使北京仓库暂时瘫痪,也不影响你收货,CDN(Content Deli……

    2025年10月23日
    01010

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注