Memcached master-to-master replication

Имеем два сервера (fail-over), на которых крутятся несколько веб сайтов. Естественно, оба mysql-сервера работают по схеме master-to-master replication. Все вроде бы хорошо, файлы автоматически обновляются раз в 15 минут (rsync), базы также (master-to-master replication). При падении одного из серверов – второй вполне нормально справляется. Для снижения нагрузки файлы сессий стали писать в мемкашед-сервер.
И вот тут столкнулись с проблемой потери сессий в случае сбоя одного из серверов.

Проблему решили благодаря использованию патча для мемкашед сервера – repcached
repcached – add data replication feature to memcached 1.2.x
Этот патч позволяет получить мульти-мастер репликации,
также поддерживается асинхронный режим репликаций,
поддерживаются все memcached команды: set, add, delete, incr/decr, flush_all, cas

Качаем уже патченые исходники и распаковываем.
Read more Memcached master-to-master replication

Восстановление software raid после сбоя

На днях “выпал” из софтварного raid1 один из разделов.

# cat /proc/mdstat
Personalities : [raid1] md2 : active raid1 sdb3[1] 34178176 blocks [2/1] [_U]

md1 : active raid1 sda2[0] sdb2[1]
      19534976 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      240832 blocks [2/2] [UU]

По данным smart-а диск в порядке, в логах ничего не замечено.

Пробуем восстановить. Помечаем диск как сбойный:

# mdadm /dev/md2 -f /dev/sda3

Удаляем его из рейда

# mdadm /dev/md2 -r /dev/sda3

И пробуем его добавить обратно

# mdadm /dev/md2 -a /dev/sda3
mdadm: re-added /dev/sda3

Статус раздела после добавления обратно в массив:

# mdadm --detail /dev/md2
/dev/md2:
        Version : 00.90
  Creation Time : Fri Mar 19 18:53:17 2010
     Raid Level : raid1
     Array Size : 34178176 (32.59 GiB 35.00 GB)
  Used Dev Size : 34178176 (32.59 GiB 35.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Sat May 15 01:42:31 2010
          State : active, degraded, recovering
 Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1 Rebuild Status : 7% complete

           UUID : d841d3cd:6e2537ed:02c08aff:db0fd513
         Events : 0.3905

    Number   Major   Minor   RaidDevice State
 2 8 4 0 spare rebuilding /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

Ждем пока завершиться ребилдинг  и надеемся, что сбой был не на физическом уровне 🙂
В противном случае придется менять диск.

Восстановление raid массива после замены физического диска.
Перед тем как менять диск, необходимо исключить все разделы сбойного диска из рейда (на всякий случай).

Помечаем все разделы сбойного диска как fail и удаляем их из рейда.


mdadm /dev/md0 -f /dev/sda1
mdadm /dev/md1 -f /dev/sda2
mdadm /dev/md2 -f /dev/sda3
mdadm /dev/md0 -r /dev/sda1
mdadm /dev/md1 -r /dev/sda2
mdadm /dev/md2 -r /dev/sda3

меняем диск на новый, стартуем.
Подготавливаем диск для добавления в рейд.

Копируем разметку с живого диска (sdb) на новый (sda)

# sfdisk -d /dev/sdb | sfdisk -f /dev/sda

Проверим, что оба диска имеют одинаковую разметку

# fdisk -l

Теперь добавим все разделы в массив рейда

# mdadm -a /dev/md0 /dev/sda1
# mdadm -a /dev/md1 /dev/sda2
# mdadm -a /dev/md2 /dev/sda3

Если сервер нагружен, можно указать максимальную скорость синхронизации дисков (указывается в кб/сек), это немного понизит нагрузку:

echo 3000 >/sys/block/md1/md/sync_speed_max

Не забываем установить grub на новый диск:

# grub
grub> root (hd0,1) # hd0 - указываем, что надо использовать диск sda, 1 - номер /boot раздела
grub> setup (hd0) # устанавливаем grub в MBR нового диска
grub> quit

Проверить текущий статус raid-массива можно так:

# cat /proc/mdstat

В принципе все … ну или как-то так 🙂