Я настроил новый сервер MySQL на Amazon EC2 и решил хранить свои данные в массиве EBS RAID0. Пока все хорошо, и я протестировал создание моментальных снимков этих устройств с помощью ec2 -istent-snapshot, отлично.
Как быстро перестроить массив на новом экземпляре из этих снимков?
Когда вы используете ec2-согласованный моментальный снимок для создания моментального снимка нескольких томов, у вас нет возможности определить, какой том использовался для каждого устройства в RAID. Возможно, я совершенно ошибаюсь, но поскольку вы распределяете данные по томам, логично было бы разместить каждый НОВЫЙ том в том же месте на RAID, что и том, из которого был создан моментальный снимок.
Пример:
вы создаете снимок ec2 с помощью: ec2-consistent-snapshot <options> vol-1 vol-2 vol-3.
Теперь у вас есть 3 моментальных снимка, и единственный способ отследить, какое это устройство, - это посмотреть на идентификатор исходного тома, затем посмотреть, на каком устройстве установлен идентификатор исходного тома, как на экземпляре, а затем проверить детали RAID. конфигурация экземпляра исходного тома.
Это, очевидно, невероятно вручную ... и не быстро (что, очевидно, затрудняет быстрое создание нового экземпляра mysql, если другой не работает. Не говоря уже о том, что вам нужно будет записать позиции устройств на RAID в то время снимка, потому что в случае сбоя экземпляра исходного тома у вас не будет возможности перейти к конфигурации RAID).
Итак, в заключение:
Надеюсь, это было ясно, и спасибо за вашу помощь!
поскольку вы распределяете данные по томам, логично было бы разместить каждый НОВЫЙ том в том же месте на RAID, что и том, из которого был создан моментальный снимок.
Я проверил вашу предпосылку, и, как бы логично это ни казалось, наблюдение обстоит иначе.
Позвольте мне подробно рассказать об этом:
У меня те же требования, что и у вас. Однако в RAID0, который я использую, всего 2 тома.
Я использую Ubuntu 10 и имею 2 устройства EBS, образующие устройство RAID0, отформатированное с помощью XFS.
Устройство 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 для одновременного создания снимков двух дисков EBS. Затем я создаю тома с этого диска, присоединяю его к новому экземпляру (который уже настроен для программного обеспечения), повторно собираю RAID (я тоже пробовал менять порядок томов EBS), монтирую его, и я готов идти.
Звучит странно, но работает.
У меня аналогичная конфигурация (RAID0 более 4 томов EBS), и, следовательно, имел те же проблемы с восстановлением массива RAID из снимков, созданных с помощью ec2-согласованный снимок.
К счастью, каждое устройство в массиве raid содержит метаданные (в суперблоке), которые записывают его позицию в массиве, UUID массива и уровень массива (например, RAID0). Чтобы запросить этот суперблок на любом устройстве, выполните следующую команду (строка, соответствующая '^ это' описывает запрошенное устройство):
$ 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-описать-тома для создания списка томов для ec2-consisten-snaptshot (-n и --отлаживать позволяют протестировать эту команду без создания снимков). Следующая команда предполагает, что каталог / 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-согласованный моментальный снимок, но я получаю дополнительный контроль, который мне нужен: fsync, запись блокировок и, что наиболее важно, назовите снимки соответствующим образом, чтобы их можно было воссоздать в правильном порядке.