MYSQL数据库备份可以直接复制MYSQL下的DATA文件夹吗

Posted 2023-04-29

可以的，注意的是复制前要关闭MYSQL程序，然后才复制，要不数据表在读写中，复制出来的表容易出问题，复制不全面。 参考技术A 可以的，整个data文件夹就是放数据库的地方 参考技术B 把你的备份导入就可以了吧 参考技术C

每当我们讨论一项（新的）领域技术的时候，最好的方式通常是首先抛出一些问题，这些问题大致分为三类：

诶？这项技术又是什么玩意（What）?

这项技术为什么会存在？我们已经有那么多解决方案（Method）了，我们为什么要用它（Why）？

如果这项技术那么好且我们正好有场景可以用到这项技术，且能使我们的系统得到很乐观的优化，那么我们怎么用呢（How）？




大概已经有同学觉得这些问题很熟悉了，是的，这就是黄金全法则提出的三个问题，对于每种新鲜事物我们首先基于这三个问题去了解，更有利于弄清楚事情的本质，端正态度去了解，而不是因为新，因为大家都说好，才要去了解……。说了那么多前奏，我们可以开始了，今天我们就带着黄金圈法则提出的三个问题去看看MySQL数据库复制这项领域技术，然后再结合实际应用扩展一些问题，本文也仅仅是结合自己了解的皮毛以抛砖引玉的态度和大家一起分享。

WHAT？

MySQL复制使得一台MySQL数据库服务器的数据被拷贝到其他一台或者多台数据库服务器，前者通常被叫做Master，后者通常被叫做Slave。

MySQL复制示意图

复制的结果是集群（Cluster）中的所有数据库服务器得到的数据理论上都是一样的，都是同一份数据，只是有多个copy。MySQL默认内建的复制策略是异步的，基于不同的配置，Slave不一定要一直和Master保持连接不断的复制或等待复制，我们指定复制所有的数据库，一部分数据库，甚至是某个数据库的某部分的表。

MySQL复制支持多种不同的复制策略，包括同步、半同步、异步和延迟策略等。

同步策略：Master要等待所有Slave应答之后才会提交（MySql对DB操作的提交通常是先对操作事件进行二进制日志文件写入然后再进行提交）。

半同步策略：Master等待至少一个Slave应答就可以提交。

异步策略：Master不需要等待Slave应答就可以提交。

延迟策略：Slave要至少落后Master指定的时间。

MySQL复制同时支持多种不同的复制模式：

基于语句的复制，Statement Based Replication（SBR）。

基于行的复制Row Based Replication（RBR）。

混合复制（Mixed）。

WHY?

这个问题其实也就是MySQL复制有什么好处，我们可以将复制的好处归结于下面几类：

性能方面：MySQL复制是一种Scale-out方案，也即“水平扩展”，将原来的单点负载扩散到多台Slave机器中去，从而提高总体的服务性能。在这种方式下，所有的写操作，当然包括UPDATE操作，都要发生在Master服务器上。读操作发生在一台或者多台Slave机器上。这种模型可以在一定程度上提高总体的服务性能，Master服务器专注于写和更新操作，Slave服务器专注于读操作，我们同时可以通过增加Slave服务器的数量来提高读服务的性能。

防腐化：由于数据被复制到了Slave，Slave可以暂停复制进程，进行数据备份，因此可以防止数据腐化。

故障恢复：同时多台Slave如果有一台Slave挂掉之后我们还可以从其他Slave读取，如果配置了主从切换的话，当Master挂掉之后我们还可以选择一台Slave作为Master继续提供写服务，这大大增加了应用的可靠性。

数据分析：实时数据可以存储在Master，而数据分析可以从Slave读取，这样不会影响Master的性能。

HOW?

这里我们只介绍一下MySQL的复制是如何工作的，至于配置，网上也有很多相关的介绍，读者具体应用的时候可以再去查阅。我们拿最常用的基于二进制文件的复制来看看。

MySQL复制工作示意图

请点击输入图片描述

请点击输入图片描述

MySQL的复制过程大概如下：

首先，主库在每次准备提交事务完成数据更新操作之前都会将数据更改操作记录到二进制日志中，这些日志是以二进制的方式记录数据更改的事件。值得一提的是二进制日志中记录的顺序实际上是事务的提交顺序，而非SQL执行语句的顺序。在记录二进制日志之后，主库会告诉存储引擎事务可以提交了。

然后，备库会启动一个IO线程，之所以叫做IO线程是因为这个线程专门做IO相关的工作，包括和主库建立连接，然后在主库上启动一个特殊的二进制转储线程，这个转储线程会不断的读取二进制日志中的事件，发送给备库的IO线程，备库的IO线程会将事件记录到中继日志中。

备库会有一个叫做SQL的线程被开启，这个线程做的事情是读取中继日志中的DB操作事件在备库执行，从而实现数据更新。

总的来说，在发生复制的主库服务器和备库服务器中，一共有三个线程在工作。

上面我们已经大概了解的什么是复制？为什么要复制？如何复制？这三个问题了，接下来我们基于上面的介绍，提出一些实际应用可能会发生的问题来思考如何解决。博主自问自答的方式-。-

问答环节

问题一：通过复制模型虽然读能力可以通过扩展slave机器来达到提高，而写能力却不能，如果写达到瓶颈我们应该怎么做呢？

答：我们首先会得出结论，这种复制模型对于写少读多型应用是非常有优势的，其次，当遇到这种问题的时候我们可以对数据库进行分库操作，所谓分库，就是将业务相关性比较大的表放在同一个数据库中，例如之前数据库有A，B，C，D四张表，A表和B表关系比较大，而C表和D表关系比较大，这样我们把C表和D表分离出去成为一个单独的数据库，通过这种方式，我们可以将原有的单点写变成双点写或多点些，从而降低原有主库的写负载。

问题二：因为复制是有延迟的，肯定会发生主库写了，但是从库还没有读到的情况，遇到这种问题怎么办？

答：MySQL支持不同的复制策略，基于不同的复制策略达到的效果也是不一样的，如果是异步复制，MySQL不能保证从库立马能够读到主库实时写入的数据，这个时候我们要权衡选择不同复制策略的利弊来进行取舍。所谓利弊，就是我们是否对从库的读有那么高的实时性要求，如果真的有，我们可以考虑使用同步复制策略，但是这种策略相比于异步复制策略会大大降低主库的响应时间和性能。我们是否可以在应用的设计层面去避开这个问题？

问题三：复制的不同模式有什么优缺点？我们如何选择？

答：基于语句的复制实际上是把主库上执行的SQL在从库上重新执行一遍，这么做的好处是实现起来简单，当前也有缺点，比如我们SQL里面使用了NOW()，当同一条SQL在从库中执行的时候显然和在主库中执行的结果是不一样的，注入此类问题可以类推。其次问题就是这种复制必须是串行的，为了保证串行执行，就需要更多的锁。

基于行的复制的时候二进制日志中记录的实际上是数据本身，这样从库可以得到正确的数据，这种方式缺点很明显，数据必须要存储在二进制日志文件中，这无疑增加的二进制日志文件的大小，同时增加的IO线程的负载和网络带宽消耗。而相比于基于语句的复制还有一个优点就是基于行的复制无需重放查询，省去了很多性能消耗。

无论哪种复制模式都不是完美的，日志如何选择，这个问题可以在理解他们的优缺点之后进行权衡。

问题四：复制的工作过程只有三个线程来完成，对于Master来说，写是并发的，也就出现了一个IO线程要把所有并发的数据变更事件记录，这个IO线程会不会累死？当一个Master对应多个Slave的时候，其实在Master中会唤起多个IO线程，这无疑会增加Master的资源开销，如果出现事件堆积，也就是事件太多，来不及及时发送出去怎么办？另外就是Slave那边的IO线程和SQL线程也会有对应主库并发数据变更事件，而Slave方单个线程处理的问题，这个时候Slave线程会不会累死？

答：上面的问题确实会发生，上面第一个问题和第二个问题其实是写负载的问题，当事件堆积太多，从库时延就会变大，Slave单SQL线程问题据说有参数可以开启并行操作，这个大家可以确认一下。

问题五：针对复制工作过程可能会出现的问题，主库写完二进制日志文件同时都会保存二进制日志的偏移量，但是当断电的时候，二进制日志文件没有刷新到磁盘，主库重新启动之后，从库尝试读该偏移量的二进制日志，会出现读不到的情况，这个问题应该怎么解决？

答：首先如果开启了sync_binlog选项，对于innodb同时设置innodb_flush_log_at_trx_commot=1，则可以保证二进制日志文件会被写入磁盘，但MyISAM引擎可能会导致数据损坏。如果没有开启这个选项，则可以通过制定从库的二进制偏移量为下一个二进制日志文件的开头，但是不能解决事件丢失问题。

问题六：从库在非计划的关闭或重启时，回去读master.info文件去找上次停止复制的位置，这同样会有一个问题，如果master.info不正确，就会导致复制数据不一致的情况，遇到这个问题怎么办？

答：这个问题可以通过两种方式解决，一是控制master.info在从库非计划关闭或重启的时候让master.info能够同步到磁盘，这样下次启动的时候就不会读取错误的信息，这有助于减少错误的发生概率。另外想要找到正确的复制位置是困难的，我们也可以选择忽略错误。



请点击输入图片描述

请点击输入图片描述

LINUX下如何直接对MYSQL数据库进行备份？

复制来的 希望对你有帮助 学会搜索 我只是帮你的问题原封不动的去google搜索了下

用命令实现备份

MySQLl提供了一个mysqldump命令，我们可以用它进行数据备份。

按提示输入密码，这就把tm数据库所有的表结构和# mysqldump -u root -p tm > tm_050519.sql数据备份到tm_050519.sql了，因为要总进行备份工作，如果数据量大会占用很大空间，这时可以利用gzip压缩数据，命令如下：

# mysqldump -u root -p tm | gzip > tm_050519.sql.gz
系统崩溃，重建系统时，可以这样恢复数据：

# mysqldump -u root -p tm < tm_050519.sql
从压缩文件直接恢复：

#gzip < tm_050519.sql.gz | mysqldump -u root -p tm
当然，有很多MySQL工具提供更直观的备份恢复功能，比如用phpMyAdmin就很方便。但我认为，mysqldump是最基本、最通用的。

二、利用crontab，系统每天定时备份mysql数据库

利用系统crontab来定时执行备份文件，按日期对备份结果进行保存，达到备份的目的。

1、创建保存备份文件的路径/var/backup/mysqlbak

# mkdir -p /var/backup/mysqlbak
2、创建/usr/sbin/bakmysql文件

#vi /usr/sbin/bakmysql.sh

#!/bin/bash
# mysql备份脚本
cd /var/backup/mysqlbak/
dateDIR=`date +"%y-%m-%d"`
mkdir -p $dateDIR/data
for i in `/usr/local/www/mysql/bin/mysql -uroot -plin31415926 -e "show databases" |
grep -v "Database" | grep -v "information_schema"`
do
/usr/local/www/mysql/bin/mysqldump -uroot -plin31415926 $i |
gzip > /var/backup/mysqlbak/$dateDIR/$i_$dateDIR.gz
done
3、修改文件属性，使其可执行

# chmod +x /usr/sbin/bakmysql
4、修改/etc/crontab

# crontab -e
在下面添加
01 3 * * * root /usr/sbin/bakmysql
#表示每天3点钟执行备份

这样每天就可以在/var/backup/mysqlbak下看到备份的sql文件 了！ 参考技术A 用到MySQL的mysqldump工具，基本用法是：

shell> mysqldump [OPTIONS] database [tables]

如果你不给定任何表，整个数据库将被导出。
通过执行mysqldump --help，你能得到你mysqldump的版本支持的选项表。
注意，如果你运行mysqldump没有--quick或--opt选项，mysqldump将在导出结果前装载整个结果集到内存中，如果你正在导出一个大的数据库，这将可能是一个问题。
1.1、mysqldump支持下列选项：
--add-locks
在每个表导出之前增加LOCK TABLES并且之后UNLOCK TABLE。(为了使得更快地插入到MySQL)。
--add-drop-table
在每个create语句之前增加一个drop table。
--allow-keywords
允许创建是关键词的列名字。这由表名前缀于每个列名做到。
-c, --complete-insert
使用完整的insert语句(用列名字)。
-C, --compress
如果客户和服务器均支持压缩，压缩两者间所有的信息。
--delayed
用INSERT DELAYED命令插入行。
-e, --extended-insert
使用全新多行INSERT语法。（给出更紧缩并且更快的插入语句）
-#, --debug[=option_string]
跟踪程序的使用(为了调试)。
--help
显示一条帮助消息并且退出。

LOAD DATA INFILE
--fields-terminated-by=...
--fields-enclosed-by=...
--fields-optionally-enclosed-by=...
--fields-escaped-by=...
--fields-terminated-by=...
这些选择与-T选择一起使用，并且有相应的LOAD DATA INFILE子句相同的含义。
LOAD DATA INFILE语法。
-F, --flush-logs
在开始导出前，洗掉在MySQL服务器中的日志文件。
-f, --force,
即使我们在一个表导出期间得到一个SQL错误，继续。
-h, --host=..
从命名的主机上的MySQL服务器导出数据。缺省主机是localhost。
-l, --lock-tables.
为开始导出锁定所有表。
-t, --no-create-info
不写入表创建信息(CREATE TABLE语句）
-d, --no-data
不写入表的任何行信息。如果你只想得到一个表的结构的导出，这是很有用的！
--opt
同--quick --add-drop-table --add-locks --extended-insert --lock-tables。
应该给你为读入一个MySQL服务器的尽可能最快的导出。
-pyour_pass, --password[=your_pass]
与服务器连接时使用的口令。如果你不指定“=your_pass”部分，mysqldump需要来自终端的口令。
-P port_num, --port=port_num
与一台主机连接时使用的TCP/IP端口号。（这用于连接到localhost以外的主机，因为它使用 Unix套接字。）
-q, --quick
不缓冲查询，直接导出至stdout；使用mysql_use_result()做它。
-S /path/to/socket, --socket=/path/to/socket
与localhost连接时（它是缺省主机)使用的套接字文件。
-T, --tab=path-to-some-directory
对于每个给定的表，创建一个 table_name.sql文件，它包含SQL CREATE 命令，和一个table_name.txt文件，它包含数据。 注意：这只有在mysqldump运行在mysqld守护进程运行的同一台机器上的时候才工作。.txt文件的格式根据--fields-xxx和 --lines--xxx选项来定。
-u user_name, --user=user_name
与服务器连接时，MySQL使用的用户名。缺省值是你的Unix登录名。
-O var=option, --set-variable var=option设置一个变量的值。可能的变量被列在下面。
-v, --verbose
冗长模式。打印出程序所做的更多的信息。
-V, --version
打印版本信息并且退出。
-w, --where=''''where-condition''''
只导出被选择了的记录；注意引号是强制的！
"--where=user=''''jimf''''" "-wuserid>1" "-wuserid<1"

1.2、最常见的mysqldump的一个备份：
虽然mysqldump支持的命令有很多，对于大多数人而言，我们只需要使用-opt这个命令就已经足够了，为你的数据库做一个完整的备份：

mysqldump --opt database > backup-file.sql

但是它对用来自于一个数据库的信息充实另外一个MySQL数据库也是有用的：

mysqldump --opt database | mysql --host=remote-host -C database

1.3、使用mysqldump导出的文件恢复数据库
由于mysqldump导出的是完整的SQL语句，所以用mysql客户程序很容易就能把数据导入了：

shell> mysqladmin create target_db_name
shell> mysql target_db_name < backup-file.sql

就是
shell> mysql 库名 < 文件名
二、使用mysqldump定时备份数据库的脚本
2.1、备份脚本
使用脚本每天定期执行数据库备份操作，对每个使用mysql数据库的人来说都很有必要，这样的脚本网上有很多，这里摘抄一个朋友的脚本 dbbackup：

这个脚本每天最多只执行一次，而且只保留最近五天的备份在服务器上。

dbbackup代码:

#!/bin/bash
#This is a ShellScript For Auto DB Backup
#Powered by aspbiz
#2004-09

#Setting
#设置数据库名，数据库登录名，密码，备份路径，日志路径，数据文件位置，以及备份方式
#默认情况下备份方式是tar，还可以是mysqldump,mysqldotcopy
#默认情况下，用root(空)登录mysql数据库，备份至/root/dbxxxxx.tgz
DBName=mysql
DBUser=root
DBPasswd=
BackupPath=/root/
LogFile=/root/db.log
DBPath=/var/lib/mysql/
#BackupMethod=mysqldump
#BackupMethod=mysqlhotcopy
#BackupMethod=tar
#Setting End

NewFile="$BackupPath"db$(date +%y%m%d).tgz
DumpFile="$BackupPath"db$(date +%y%m%d)
OldFile="$BackupPath"db$(date +%y%m%d --date=''''5 days ago'''').tgz

echo "-------------------------------------------" >> $LogFile
echo $(date +"%y-%m-%d %H:%M:%S") >> $LogFile
echo "--------------------------" >> $LogFile
#Delete Old File
if [ -f $OldFile ]
then
rm -f $OldFile >> $LogFile 2>&1
echo "[$OldFile]Delete Old File Success!" >> $LogFile
else
echo "[$OldFile]No Old Backup File!" >> $LogFile
fi

if [ -f $NewFile ]
then
echo "[$NewFile]The Backup File is exists,Can''''t Backup!" >> $LogFile
else
case $BackupMethod in
mysqldump)
if [ -z $DBPasswd ]
then
mysqldump -u $DBUser --opt $DBName > $DumpFile
else
mysqldump -u $DBUser -p$DBPasswd --opt $DBName > $DumpFile
fi
tar czvf $NewFile $DumpFile >> $LogFile 2>&1
echo "[$NewFile]Backup Success!" >> $LogFile
rm -rf $DumpFile
;;
mysqlhotcopy)
rm -rf $DumpFile
mkdir $DumpFile
if [ -z $DBPasswd ]
then
mysqlhotcopy -u $DBUser $DBName $DumpFile >> $LogFile 2>&1
else
mysqlhotcopy -u $DBUser -p $DBPasswd $DBName $DumpFile >>$LogFile 2>&1
fi
tar czvf $NewFile $DumpFile >> $LogFile 2>&1
echo "[$NewFile]Backup Success!" >> $LogFile
rm -rf $DumpFile
;;
*)
/etc/init.d/mysqld stop >/dev/null 2>&1
tar czvf $NewFile $DBPath$DBName >> $LogFile 2>&1
/etc/init.d/mysqld start >/dev/null 2>&1
echo "[$NewFile]Backup Success!" >> $LogFile
;;
esac
fi

echo "-------------------------------------------" >> $LogFile

2.2、放入crontab定期执行dbbackup
假定dbbackup在/root目录下。我们通过使用crontab命令，设置每天0点10分执行/root/dbbakup脚本。
1、 使用 crontab –e编辑crontab
2、 在crontab中加入：

#back for jabber database
10 0 * * * /root/dbbackup
另外,虚机团上产品团购,超级便宜 参考技术B MYSQL提供了数据导入与导出的两个命令，分别是mysqlimport（导入）和 mysqldump（导出或者转储）。详细用法请百度一下。