тот что в репозитории не совпадает с версией drbd в новом ядре https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1103656 так что были два варианта - собирать новые утилиты или откатывать ядро. Я сначала собрал новые утилиты, но в итоге откатил ядро.
> T> 1. Да, после обновления ядра собирал userland-утилиты вручную и в скрипты > их не добавил. > а чем плох тот что из репозитария ? > > T> 2. Через 0, т.е. было написано что она начата, 0%, скорость 0, потом > теряется. > T> 3. Только drbd > T> 4. Пересоздать - как я понимаю затерание метаданных это аналогично > T> пересозданию диска - я пробовал, но в целом сотни гигабайт копировать дело > не быстрое. > > T> В итоге диски и синхронизацию починил, вариантов и попыток было > T> много, приведу окончательную последовательность действий, которые решили > проблему. > T> Возможно можно было обойтись без отката ядра/drbd, и начать с > T> пункта 5 или но я на тот момент его уже сделал. > можно и обратно сделать - зато будут достоверные данные. > и если его не удаляли как я понял оно должно быть в списке загрузки. > > > ПО ходу вопрос о ядрах. > что за пакеты ? > linux-headers-generic-lts-quantal > linux-image-generic-lts-quantal > > вроде не они грузятся, но есть... а тогда зачем > можно ли убрать их ? > > > T> 1. drbdadm down all - выключить все диски > на какой машине выполнялись эти команды ? осн. или дублер ? > > T> 2. drbdadm apply-al all - применить изменения из журналов > T> 3. apt-get install linux-image-3.2.0-54-generic > T> 4. Перезагрузиться с новым ядром, проверить что загрузилось 3.5 > T> 5. Поменял secret в настройках, он у меня был со спец. символами, > T> предположительно из-за этого команды могли выполняться неправильно > T> если параметры спец. образом не экранировались, а судя по > T> сообщениям об ошибках при повторным drbdadm connect они не > T> экранируются. Оставил только буквы и цифры. > T> 6. На сервере со вторичными дисками drbdadm down all для выключения дисков > T> 7. На сервере с первичными дисками drbdadm disconnect all; drbdadm connect > all > T> 8. На сервере со вторичными дисками drbdadm up all > > T> После этого синхронизация пошла. В этот момент на сервере с > T> первичными дисками работал drbd 8.4 на сервере со вторичными 8.3 > T> Затем переключил все сервисы на запасной сервер и сделал downgrade ядра и > drbd на первом сервере. > >>> 1. а почему надо делать вручную поднятия дисков для зеркала ? >>> автомат не прописан ? >>> >>> 2. Синхр начиначется и через сколько процентов теряется? >>> >>> 3. У вас только DrBD или HB еще ? >>> >>> 4. Есть ли резон возиться с дисками дублерами, если их можно >>> пересоздать и заполнить заново с основных? >>> >>> >>> >>> T> DRBD вошел в странное состояние >>> >>> T> Есть два сервера, на них настроено несколько дисков, >>> T> синхронизирующихся по DRBD (в основном 10-50Гб), диски поверх LVM. >>> T> Всё работало хорошо, пока я не перезагрузил сервер с secondary-дисками. >>> >>> T> Перезагружаю вторичный сервер. делаю drbdadm up all >>> >>> T> По моим представлениям он должен за несколько секунд всё >>> T> синхронизировать и войти в обычное состояние (операций записи не много). >>> T> Что получается на практике: >>> T> 1. Для дисков на которы запись не идет вообще синхронизация >>> T> занимает 5-10 минут. (очень медленное переключение между состояниями >>> синхронизации) >>> T> 2. Для дисков на которые идет запись синхронизация не проходит: >>> T> сначала она вроде как начинается, но скорость синхронизации >>> T> показывается 0, затем она обрывается как бы по ошибке сети и через >>> T> несколько минут ситуация повторяется и зацикливается. >>> >>> T> Вот так жто выглядит со стороны Primary >>> T> SyncSource Primary/Secondary UpToDate/Inconsistent C r---n- >>> T> [>....................] sync'ed: 0.1% >>> T> (32764/32764)Mfinish: 652:25:36 speed: 0 (0) K/sec >>> >>> T> Через пару минут связь теряется с переходит в WFConnection >>> >>> T> Со стороны Secondary связь теряется после WFSyncUUID и вместо >>> T> SyncTarget переходит в NetworkFailure. >>> >>> T> Связь между серверами хорошая (iperf показывает 600Мбит, ping >>> T> показывает задержку 0.2-0.3 милисекунды и 0% потерь). >>> >>> T> Перезагрузка обоих серверов не помогла. >>> T> Кроме перезагрузки пробовал вручную выставлять скорость >>> T> синхронизации, пересоздавать метаданные на одном из вторичных дисков. >>> >>> T> Попробовал создать новый диск, он синхронизируется хорошо, за >>> T> несколько секунд как и должно быть. >>> >>> T> Система: Ubuntu 12.04 64-bit >>> T> cat /proc/drbd >>> T> version: 8.4.2 (api:1/proto:86-101) >>> T> srcversion: 18C7EBE1B3F8CCCB5CF512C >>> >>> T> Ввиду того бага что ядро в ubuntu обновилось, а userspace-утилиты >>> T> нет - утилиты собраны вручную, модуль из дистрибутива. >>> >>> T> Как заставить синхронизироваться старые диски и/или включить >>> T> какие-то подробные логи откуда будет понятно что происходит. >>> >>> >>> >>> -- >>> С уважением, >>> Роман mailto:idi...@rambler.ru >>> >>> >>> -- >>> ubuntu-ru mailing list >>> ubuntu-ru@lists.ubuntu.com >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru > > > > > -- > С уважением, > Роман mailto:idi...@rambler.ru > > > -- > ubuntu-ru mailing list > ubuntu-ru@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru -- ubuntu-ru mailing list ubuntu-ru@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru