从使用ec2-consistent-snapshot拍摄的快照中还原Amazon EBS RAID0阵列

我在Amazon EC2上配置了一个新的MySQL服务器，并决定将我的数据存储在EBS RAID0阵列上。到目前为止一切顺利，我已经测试了使用ec2-consistent-snapshot拍摄这些设备的快照的效果，非常好。

现在，如何从这些快照快速在新实例上重建阵列？

当您使用ec2-consistent-snapshot创建多个卷的快照时，您将无法确定RAID中每个设备使用了哪个卷。我可能完全错了，但是由于您要跨卷分条数据，因此，您必须将每个新卷放置在RAID上与创建快照的卷相同的位置上。

一个例子：

• RAID0配置中的3x200gb卷。
• vol-1是RAID中的/ dev / sdh设备0
• vol-2是RAID中的/ dev / sdh1设备1
• vol-3是RAID中的/ dev / sdh2设备2

您可以使用创建一个ec2快照：ec2-consistent-snapshot <options> vol-1 vol-2 vol-3。

现在，您具有3个快照，并且要追溯它们是哪个设备，唯一的方法是查看源卷ID，然后查看实例上安装了源卷ID的设备，然后检查RAID的详细信息。源卷实例上的配置。

这显然是难以置信的手动操作……而且速度不快（显然，如果另一个实例失败，则很难快速启动新的mysql实例。更不用说，您当时必须在RAID上记录设备位置快照，因为如果源卷实例崩溃，则无法进入RAID配置）。

因此，结论是：

• 我是否缺少ec2-consistent-snapshot和软件RAID0阵列的工作方式？
• 如果不是，是否有不知道快照属于RAID阵列中哪个设备/位置的问题的已知解决方案/最佳实践？

我希望这很清楚，并感谢您的帮助！

由于您要跨卷分条数据，因此必须将每个NEW卷放置在RAID上与创建快照的卷相同的位置上。

我测试了您的前提，看起来似乎合乎逻辑，但观察结果却相反。

让我详细说明一下：
我的要求与您完全相同。但是，我正在使用的RAID0只有2个卷。

我正在使用Ubuntu 10，并且有2个EBS设备形成了以XFS格式化的RAID0设备。

raid0设备正在使用以下命令创建：
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

我已经安装了MYSQL和许多其他软件，这些软件配置为使用/ dev / md0来存储其数据文件。

使用相同的卷：完成后，我卸载所有组件，停止Raid并重新组装，如下所示： sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg 事情是，无论顺序如何/dev/sdg /dev/sgh，RAID都会正确地重新构成自身。

使用快照：发布后，我用来ec2-consistent-snapshot一起创建2个EBS磁盘的快照。然后，我从该磁盘创建卷，将其附加到新实例（已经为该软件配置了此实例），重新组装RAID（我也尝试过交换EBS卷的顺序），挂载它并准备就绪去。

听起来很奇怪，但是可以。

我运行类似的配置（在4个EBS卷上使用RAID0），因此也有同样的问题，需要从使用ec2-consistent-snapshot创建的快照中重构RAID阵列。

幸运的是，RAID阵列中的每个设备都包含元数据（在超级块中），该元数据记录其在阵列中的位置，阵列的UUID和阵列级别（例如RAID0）。要在任何设备上查询此超级块，请运行以下命令（与“ ^ this”匹配的行描述了所查询的设备）：

$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 2ca96b4a:9a1f1fbd:2f3c176d:b2b9da7c
  Creation Time : Mon Mar 28 23:31:41 2011
     Raid Level : raid0
  Used Dev Size : 0
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Mon Mar 28 23:31:41 2011
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : ed10058a - correct
         Events : 1

     Chunk Size : 256K

      Number   Major   Minor   RaidDevice State
this     0     202       17        0      active sync   /dev/sdb1

   0     0     202       17        0      active sync   /dev/sdb1
   1     1     202       18        1      active sync   /dev/sdb2
   2     2     202       19        2      active sync   /dev/sdb3
   3     3     202       20        3      active sync   /dev/sdb4

如果在不属于数组的设备上执行相同的查询，则会获得：

$ sudo mdadm --examine /dev/sda1
mdadm: No md superblock detected on /dev/sda1.

这证明该命令确实依赖于设备本身存储的信息，而不是某些配置文件。

也可以从RAID设备开始检查RAID阵列的设备，以获取类似信息：

$ sudo mdadm --detail /dev/md0

我将后面的内容与ec2-describe-volumes一起使用，以构建ec2-consistent-snaptshot的卷列表（-n和--debug允许测试此命令而不创建快照）。以下命令假定目录/ mysql是卷的安装点，并且AWS区域是us-west-1：

$ sudo -E ec2-consistent-snapshot --region us-west-1 --mysql --freeze-filesystem /mysql --mysql-master-status-file /mysql/master-info --description "$(date +'%Y/%m/%d %H:%M:%S') - ASR2 RAID0 (4 volumes) Snapshot" --debug -n $(ec2-describe-volumes --region us-west-1 | grep $(wget http://169.254.169.254/latest/meta-data/instance-id -O - -q) | egrep $(sudo mdadm --detail $(awk '{if($2=="/mysql") print $1}' /etc/fstab) | awk '/ \/dev\//{printf "%s ", $7}' | sed -e 's# /#|/#g') | awk '{printf "%s ", $2}')

我知道这不能回答您的问题，但是我正在使用Amazon的基本ec2-create-snapshot工具和cron脚本执行类似的操作。它的速度不如ec2-consistent-snapshot快，但是我得到了我需要的额外控制：fsync，锁定写入，最重要的是，适当命名快照，以便可以正确的顺序对其进行重构。