想将A服务器中的数据库快速转移到B服务器中，一般是先从A服务器中备份下来，下载备份数据，还原到B服务器中。使用phpMyAdmin备份和还原针对数据量很小的情况下很方便，数据量大的话很容易中断失败。
 
如何快速高效的将大数据转移到另一个服务器呢？综合起来使用命令行的方式效率最高。
 
关键词：MYSQL数据库,mysql备份，mysql还原,数据库备份，数据库还原。
 
数据库A账户信息
 
服务器地址:127.0.0.1
 
用户名:username,密码:password,数据库名：dbname
 
数据库B账户信息
 
服务器地址:127.0.0.2
 
用户名:usernameb,密码:passwordb,数据库名：dbnamenew
 
常规步骤命令行：
 
备份并压缩
 
mysqldump -uusername -ppassword dbname | gzip > /data/wwwroot/www/dbname.sql.gz
 
解压并还原
 
gunzip < /root/dbname.sql.gz | mysql -uusernameb -ppasswordb dbnamenew
 
最佳方式介绍
 
还有一种直接将数据库A直接转移到数据库B的方式(在服务器A中执行)
 
mysqldump --default-character-set=utf8mb4 --host=127.0.0.1 -uusername -ppassword --opt dbname | mysql --host=127.0.0.2 -uusernameb -ppasswordb --default-character-set=utf8mb4 -C dbnamenew
 
备注 (来此加密(https://letsencrypt.osfipin.com)：免费简单的申请Let’s Encrypt证书，不需要搭建服务器环境。)
 
 
 
1.必须保证服务器B的数据库能够服务器A访问
 
 
2.--opt命令可选，建议加上。等同于指定 --add-drop-tables--add-locking --create-option --disable-keys--extended-insert --lock-tables --quick --set-charset。它可以给出很快的转储操作并产生一个可以很快装入MySQL服务器的转储文件。
 
 
3.--default-character-set=utf8mb4 指定该数据库连接的字符类型。如果服务器默认未utf8的话，导出的数据可能会丢失四字节的unicode信息（表情之类的）
 
 
4.-C 客户端和服务器之间启用压缩传递所有信息。当然得要有咯。
 
 
mysql通过命令行快速转移数据库，一个命令（mysqldump）完成数据备份还原。

 
 
今天真汗颜啊。。。。由于我的一不小心，我把几百万条数据给删了，囧。客户的几年重要数据就这样没了，我当时愁的，还好后来找回来了。
 
 
对于大数据的操作，大家一定要慎重操作。
 
 
    在SQLServer2005中，想从一个数据库服务器迁移一个数据表的数据到另一数据库服务器的表中，大家一般会怎么做呢？
 
 
    我先来说说我今天的做法：（因为自己的笔记本上没有装软件，不能截图给大家看了，大家可以自己动手操作下）
 
 
    刚开始我利用一种方法，很笨且不安全的，大家引以为戒。
 
 
    老大交给我任务了，我一想那么多数据，总不能一条一条手工插入吧。我思考了一段时间，我决定利用SQLServer的自带工具，右键点击，导入/导出数据功能。先用T-SQL语句根据条件筛选出需要的数据，在一台数据库服务器上操作，将查询出的数据右键另存为.rpt和.txt格式的文件。然后在另一个服务器上导入这些数据。当我操作前几个表的数据正常的时候，我还洋洋得意，到了最后一个表时发现导入的数据再遇到datetime类型时，发现傻眼了，前几十条数据正常导入，到了后面的一条数据以后，后面的几万条数据导不了了啊，有木有？囧！这是为什么呢？我检查了下数据，发现到那条卡壳的数据时，那里有个null值。嗯？？？为什么空就不能导入了?varchar和datetime类型的区别，我想大家都知道吧。对，问题就出在这。当我们把数据导出去的时候，那些数据最严重的缺点就是少了字段描述了，全变成了varchar类型了。不信的话，你用导入工具导入到一个新表里试试（这里没法截图，大家自己可以试试），你会发现默认的数据都成varchar类型了。悲剧，这个方法遗憾失败！
 
 
正确的做法是：
 
 
一、              用T-SQL语句新建一个临时表，这个表和你需要导出数据表的字段定义一样。假设我们要导出的数据库表为A，那么这个临时表叫A_Temp。
 
 
 
 
 
 
 
 
 
 
看T-SQL语句:
 
 
 
 
INSERT  INTO  A_Temp  SELECT  *  FROM  A  WHERE 1 = 1  AND  BeginTime  > ’2012-11-05 00:00:00’ AND BeginTime < ‘2012-11-06 00:00:00’ 
 
将筛选出来的数据拷贝到A_Temp表中。
 
 
 
 
 
再在另一个数据库服务器上操作：
 
 
 
 
 
 
 
用T-SQL语句新建一个临时表，这个表和你需要导出数据表的字段定义一样。
 
 
 
 
 
二、              利用SQLServer导入导出工具将22的数据库表A_Temp导入到23的数据库表B_Temp中，现在再将B_Temp表中的数据添加到B表中。这样就搞定了。
 
 
 
 
 
 
 
INSERT  INTO  B  SELECT  *  FROM  B_Temp 
 
 
 
 
 
 
 
 
 
总结这样的好处：
 
 
1)         可以很清楚明白的知道你要导出的数据，方便后来维护查询；
 
 
2)         不会出现数据类型对不上的情况，当时是因为自己的粗心大意，在查询数据的时候把Delete看成了Select执行了，结果导致严重的后果，差点就赔钱了啊。汗。。。
 
 
3)         思路明确，严谨。
 
 
 
 
 
    好了，今天的总结就到这，学无止境，工作中一定要心细。大家在操作大数量的数据时，每当使用Update、Delete、Insert时一定要考虑好，重新检查一遍，想想你正在做什么？不要一失足成千古恨，到时候悔之晚矣。
 
 

 
 
本文转自shyy8712872 51CTO博客，原文链接：http://blog.51cto.com/shuyangyang/1050935，如需转载请自行联系原作者
 
 

  

 
 

 
 

  
公司有一台文件服务器，提供给设计部门，用来存放图纸，空间10T，已使用容量9.2T，文件约为100万个。由于文件服务器使用一台较为低端的DELL R320加上几个SATA硬盘做的RAID5，为安全计，需要备份数据。
  
对于备份的方案前期我们也做了一些调研，比如使用备份一体机还是使用传统的方案来进行备份。并且对各方面进行了一番对比。
  


  

备份一体机
传统
备份原理
在设计部文件服务器上安装备份代理，定期通过网络备份到一体机
通过DFS复制，实时或定期将文件副本写入新服务器，定期对新服务器存储的文件备份到本地
安全性
因为其使用linux做为底层，不易受到勒索病毒***，文件不易被删除，安全性较高
使用windows，在windows上使用备份工具备份，易受到勒索病毒***，存在安全风险
可靠性
使用单独的一体机，只用于备份设计部文件服务器时，可靠性较高
使用wsb，文件易被误删除，导致无法还原，可靠性比一体机低
如果DFS出错，未能同步，可能导致数据丢失
底层OS为windows,备份做为一种工具或程序存在，OS故障，则导致备份可能无法还原
备份时间
按备份速度为50MB/s,即网络流量为400Mbps，单次全备时间预计60个小时以上
除首次同步外，不需长时间占用网络流量，在同一台机器上备份
价格
160000
55000
优势
可靠性高，操作简单，易于验证，不易出错
价格较低，只购买一台服务器，且服务器可以用于提供文件服务（备用文件服务器）
劣势
价格较高
可靠性和安全性比备份一体机低，无售后技术支持

  


  


  
简单的来讲，使用备份一体机，就是使用一台专门的一体机，只为这10T内容进行备份。因为10T的内容按照备份速度50MB/s,需要58小时才能备份完成。如果使用原有的备份一体机，那么在这个时间段内，其他数据的备份可能存在资源冲突。也有可能，10T数据备份，加上其他数据备份到同一台，这10T数据可能需要3-5天的时间才能完成。所以需要一台专门的备份一体机来为这10T数据备份。
  
而使用传统方案，则是使用卷影副本+DFS+WSB。具体是这样操作：在原有的服务器上，我们对存放数据的10T的卷做了卷影副本，如果空间充足，可以提供多达64个以前的版本。新购买一台服务器，可用空间50T，价格约为5.5万元，数据存放划分两个区，一个20T的空间用于存放DFS的已复制文件夹，另一个30T的空间用于使用WSB进行备份。DFS即分布式文件系统，可以用来抵御因硬件损坏带来的单点故障（与备份不同），这样，如果原有的10T服务器当机后，这台机器依然可以提供给用户访问。而数据的备份就依靠windows server backup来做了，经过测试环境的检验，使用WSB默认设置，即完全备份-副本备份，其实际上做的备份会进行重复数据删除或者说实际上做的是增量备份，除第一次全备外，并不会每次备份10个T的数据，而只会备份增量的数据。通过这个方案，我们可以抵御硬件带来的单点故障，对于小量的文件恢复，可以使用卷影副本来恢复，而如果面对服务器感染勒索病毒等情况下，还有备份可以还原。当然，前提是服务器需要打好补丁，安装好正版的杀毒软件。
  
两个方案报给领导，领导决定使用传统的备份方案。
  
接下来需要准备在实验环境下进行测试了，主要是考虑到10T的数据，进行DFS的初始复制需要的时间很长。根据微软网站上的实验，1400万个文件，共10T，进行初始同步花费了24天，微软网站上把这个形成为一种针对网络的***。官方推荐的做法是预先通过将目标服务器上放置源服务器上存在的数据，并且通过导出DFS数据库，再导入数据库到目标服务器的方式来减少DFS初始同步的问题。
  
我先把要点捋一下：
  
一、 在两台服务器上都安装DFS复制组件，DFS复制与DFS命名空间是分开的，可以不安装DFS命名空间。将源服务器（10T）加入到复制组并且创建已复制文件夹。使之成为初始复制的主要成员。
  
二、在源服务器上导出DFS数据库的克隆
  
三、使用robocopy将源服务器（10T）的数据拷贝到目标服务器（50T）
  
四、 在目标服务器上将第二步在源上导入的DFS数据库导入到目标服务器
  
五、 将目标服务器加入到复制组
  
六、进行初次同步
  


  
注意问题：
  
1. 目标服务器不要在最开始的时候加入到已复制组，需要等到数据复制完成，DFS数据库导入完成后再加入。
  
2. 目标服务器和源服务器不要搞混，源服务器指拥有权威数据的服务器，它应该被设置成为初始复制的主服务器，也称为上游服务器；目标服务器是指新服务器，没有数据的50T服务器，也称为下游服务器。
  
3. 在下游服务器上，不要手动创建被同步的文件夹，这两个文件夹应该由robocopy来创建，以免文件HASH存在不一致，导致DFS初始化时间过长。
  
4. 进行初始复制的时候，由上游服务器做为权威，会去同步下游服务器。而此时下游服务器上存在，上游服务器上不存在的数据，会被存放到下游服务器的dfsrprivate\preexiting这个目录下。这个目录是隐藏的，就在你的已同步文件夹里面。显示隐藏和系统文件即可看到。
  
5. 可以适当调整暂存文件夹和冲突和已删除文件夹的大小。建议暂存文件夹至少为4需要同步的最大文件的大小，否则，可能会报错。
  
接下来，我们开始实验
  
实验环境：有两台windows server 2012的虚拟机，dc201201 IP:192.168.99.98，充当DC以及DFS复制的上游服务器； dc201202 IP:192.168.99.99,充当DFS复制的下游服务器。
  
实验目标：上游服务器上存在数千个文件，需要使用预播的方式存到下游服务器，以便初次同步能迅速完成。
  
已复制文件夹名称：部门文档
  


  
DFS复制
  
一、 在DC201201上安装AD域服务，并且将其提升为新林contoso.com中的第一个域的DC
  

  

  

  
二、 域控安装完成之后，在两台机器上分别安装DFS复制这个管理组件。
  
Install-WindowsFeature –Name Fs-Dfs-Replication -IncludeManagementTools
  

  
三、 在两台服务器上分别创建分区E和F，大约都为50G。在dc201201的E盘创建了部门文档文件夹，并且放入了4875个文件，大小约为900M。
  

  
四、在上游服务器上创建复制组，创建一个已复制文件夹，并指定该文件夹在上游服务器的物理位置。
  

  

  

  

  

  
验证：等待DFS复制的事件日志中出现4112，这表示这台服务器DC201201是初始化复制时的主文件夹。
  

  

  
五、导出上游服务器的克隆数据库和卷配置的XML文件，它还要求该卷上的任何已复制文件夹都未处于初始同步阶段。
  
在这一个通PS创建了一个e:\dfsrclone的文件夹，并且将E盘的信息做出了一个克隆，注意，这个并不是真实的数据文件的克隆。
  

  

  
在这一步实施的时候，建议让用户不要访问e:\部门文档上的内容，因为这会导致克隆的效率降低。更重要的一点是，在初始复制完成以前，绝对禁止用户访问下游（目标）服务器上的文件。
  
在克隆数据库的时候，它给出了如何将数据和数据库复制到下游服务器的命令，按照给出的命令执行即可，目标可以使用UNC路径的方式来表示。
  
五、验证数据库的导出和上游服务器初始复制已经准备好。分别通过日志2402和2002表示。日志2402表示克隆的数据库已经导出完成，2002表示初始复制已经在主服务器上准备好。
  

  
六、将已复制文件夹内的数据使用robocopy复制到下游服务器。需要特别注意的是，目标路径不能在下游服务器上手动创建，让robocopy自动创建即可。
  
通过robocopy的显示，共复制了4875个文件，1002M，花费了21秒。
  

  
执行的命令
  
```
  
Robocopy.exe“e:\部门文档”“\\dc201202\E$\部门文档”/ E / B / COPYALL / R：6 / W：5 / MT：64 / XD DfsrPrivate / TEE /LOG+:preseed.log
  
/E:
  
```
  
请勿在卷的根目录上使用robocopy / MIR选项，不要在下游服务器上手动创建已复制的文件夹，也不要运行先前已复制的robocopy文件（即如果必须重新开始，请删除目标文件夹和文件结构，并真正重新开始）。让robocopy创建所有文件夹，并在每次运行时通过/ e / b / copyall选项将所有内容复制到下游服务器。否则，您很可能最终会出现哈希不匹配。
  
接下来，我们需要将导出的E盘的数据库XML文件通过xcopy复制到下游服务器，同时，在这个时候，为了模拟上游服务器有人使用，复制了几个大文件到上游服务器。
  

  

  
七、验证文件HASH，验证两台服务器上的文件的HASH值是否一致，如果HASH一致，则表示这些文件在初始复制的时候无需再进行同步了。建议在多个目录下进行比对。
  

  
八、在下游服务器上导入数据库和XML文件，在导入之前，请确保下游服务器的e:\system volume information\dfsr这个文件夹不存在。
  

  
也可以使用以下方法来确保DFSR里不存在任何文件。
  
1. 创建一个e:\empty的文件夹
  
2. robocopy "e:\cmpty" "e:\system vloume information\dfsr" /mir
  
本文略过此步
  

  
九、验证下游服务器的数据库和XML文件导入是否成功，通过DFS复制的日志来查看，2412，2416，2404.看到日志2404则表示已经完成了导入。
  

  
十、 将下游服务器dc201202加入到复制组
  

  

  

  

  
十一、验证初始复制是否成功，需要等待DFS复制日志4104，请注意，在这里不会出现日志4102.如果在上游导出了克隆后，上游又有数据被更改了，那么这些文件将以权威的方式复制到下游服务器。
  

  
至此，DFS的复制工作完成。我们来下游服务器上看看数据是否被复制过来了。
  

  
验证一下同步功能，在下游服务器上删除红色HDTV01.MKV这个文件，查看上游是否会同步。
  

  
验证结果是可以同步。
  
卷影副本
  
vssadmin add shadowstorage /for=d: /on=e: /maxsize=2GB
  
1. 卷影副本最多可以支持多达64个以前的版本，如果超过64个，它会自动删除最前面的版本。
  
2. 卷影副本不适合大量读写的文件，可能导致CPU占用率居高不下
  
在这里，我准备的方案是在两台机器上都开启卷影副本。卷影副本占用的空间，我的做法是上游服务器1T，下游服务器2T。实验环境，都是取10%
  

  

  
首次开启卷影副本，会自动创建一次。在我的实际环境中，10T的数据空间，将卷影副本放到另外一个1T的空间。保存了64个副本。
  

  
提示：卷影副本不能完全当成备份使用，特别是你的磁盘空间不足的情况下，如果磁盘被擦写一次完整的，可能会丢失所有的卷影副本。
  
备份
  
安装windows server backup备份工具，并且进行默认的备份，默认的备份指完全备份，副本备份。下次有时候我再去执行非副本方式的备份。
  
一、在下游服务器， 通过向导安装wsb
  

  

  

  

  

  

  

  

  

  
在这里，默认的备份频率是每天一天或者多次，我们可以更改任务计划里的back的相关计划来调整频率。
  

  
进行首次备份，然后，添加1G文件，再进行第二次备份。查看两次备份总共占用的空间大小。
  

  
E盘已用空间4.42G，F盘目前占用空间为0.1G
  
备份第一次后，F盘已用空间为6.02GB
  

  
复制两个总共1G的文件，到E:\部门文档
  

  
再次执行备份，F盘已用空间为6.1G。
  

  

  
通过这个实验，我们进行了两次完全备份，第一次占用了6G空间，第二次备份，只占用了0.1G。它并没有占用两次备份的数据之和的空间。所以说明它是增量备份或者说是进行了重复数据删除的。（还要去查资料）
  
数据还原：
  
打开windows server backup,点击恢复，可以通过日期来看到备份编录。
  

  

  
灾难恢复
  
如果哪一天，50T空间的服务器操作系统故障，重装了，如何来有效的利用这上面的数据呢？
  
1. 卷影副本：
  
重装前的卷影副本有四次，
  

  
重装系统以后的数据：
  

  
2. 备份的数据
  
重装系统以前，备份的数据有以下几次
  

  
在重装后的系统启用WSB的恢复向导
  

  

  

  
请注意上图，11月2日到6日，数字加粗了，就表示有备份。这样，即使是重装了系统，也可以把原来的卷影副本和备份的数据找到。当然，由于这个备份的平台是Windows平台，一定要考虑好安全问题，一个是即时打补丁，一个是安装杀毒软件。 另外一点就是，DFS我们这个实验中设置的时实时的同步，也可以选择为非实时的，即多长时间复制一次，比如每周二、周六晚上0点到7：00进行复制，甚至也可以使用robocopy进行复制。像我原来公司的文件服务器就是每周三次的robocopy进行的复制，这样有一个好处就是万一哪天原文件服务器被勒索病毒***，加密了，我还有一个缓冲的时间，这样至多丢失三天的数据。
  


  


  


  


  
附全文脚本：（PS的脚本我也不熟悉，除了导出和导出数据库和XML以外，窃以为，其他的都可以通过GUI来实现）
  
On the upstream DC201201 server:
  
New-DfsReplicationGroup “VSS” | 
  
New-DfsReplicatedFolder -FolderName “部门文档” | Add-DfsrMember -ComputerName dc201201
  
Set-DfsrMembership –GroupName “VSS” -ComputerName dc201201 -ContentPath "E:\部门文档" -PrimaryMember $True -FolderName “部门文档” 
  
Update-DfsrConfigurationFromAD 
  
Get-WinEvent “Dfs replication”  -MaxEvents 4 | fl 
  
New-Item -Path “E:\Dfsrclone” -Type Directory 
  
Export-DfsrClone -Volume E: -Path “E:\Dfsrclone” 
  
Robocopy.exe “E:\部门文档”  “\\dc201202\E$\部门文档” /E /B /COPYALL /R:6 /W:5 /MT:64 /XD DfsrPrivate /TEE /LOG+:preseed.log 
  
Robocopy.exe E:\Dfsrclone \\dc201202\e$\Dfsrclone
  
On the downstream DC201202 server (note: you may need to stop the DFSR service to perform the first step; be sure to start it up again so that you can run the import)
  
RD “E:\System Volume Information\DFSR” –Force -Recurse 
  
Import-DfsrClone -Volume E: -Path “E:\Dfsrclone” 
  
Get-WinEvent “Dfs replication”  -MaxEvents 10 | fl 
  
Add-DfsrMember -GroupName “VSS” -ComputerName “DC201202” | Set-DfsrMembership -FolderName “部门文档” -ContentPath “E:\部门文档” 
  
Add-DfsrConnection -GroupName “VSS” -SourceComputerName “DC201201” -DestinationComputerName “DC201202” 
  
Update-DfsrConfigurationFromAD DC201201,DC201202 
  
Get-WinEvent “Dfs replication” -MaxEvents 10 | fl
  


  


  


  
 
  

  

  

 
 
 
转载于:https://blog.51cto.com/liu008qing/2313242