Я установил DRBD на 2 узлах и вчера начал его использовать. Примерно через час было повторно синхронизировано 50% раздела. Прошло еще 12 часов, и это до 79%, причем движется ОЧЕНЬ медленно.
Вот что показывает cat / proc / drbd:
1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r-----
ns:464931976 nr:191087032 dw:656013660 dr:214780588 al:100703 bm:21100 lo:7 pe:0 ua:0 ap:7 ep:1 wo:f oos:92241852
[==============>.....] sync'ed: 79.2% (90076/431396)M
finish: 76:13:38 speed: 332 (8,680) want: 19,480 K/sec
Я посмотрел на сетевой трафик и использую от 1 до 20 МБ на интерфейсе 1G. Пытался запустить iperf, пока все это происходит, и получил 930 млн. Пытался настроить скорость синхронизации до 10M, 50M, 500M, но безрезультатно. Подправили размер пакета тоже без удачи.
Предупреждение, как вы можете видеть из статуса, заключается в том, что мой основной узел несовместим. Поэтому я предполагаю, что ОС работает по существу со вторичным узлом, пока идет повторная синхронизация. Но учитывая такую низкую пропускную способность, я не понимаю, почему синхронизация не выполняется быстрее.
Есть идеи, что я могу попробовать дальше? Расчетное время завершения в 76 часов - это не то, чего я с нетерпением жду :( Особенно не зная причины, так что произойдет своего рода сбой, я бы не знал, как быстро привести массив к согласованности.
Спасибо!
РЕДАКТИРОВАТЬ: Я безрезультатно пробовал следующие настройки в сетевом разделе:
sndbuf-size 512k;
max-buffers 20480;
max-epoch-size 16384;
unplug-watermark 20480;
РЕДАКТИРОВАТЬ 2: Без видимой причины скорость подскочила до 10 ~ 30M после того, как я перестал настраивать все конфиги. Получил до 98,8% синхронизации и упал до ~ 300 КБ. Нет сообщений в логах ни на одном из серверов. По совпадению, я вижу всплеск активности INSERT в базе данных MySQL, которая запускается из этого раздела. Любые идеи?
РЕДАКТИРОВАТЬ 3: Версия: 8.4.2 (api: 1 / proto: 86-101)
После комментария @Nils я начал изучать, насколько используются диски. И заметил, что получаю гораздо больше операций чтения, чем было до перенастройки системы на DRBD. Дальнейшие исследования показали, что использование диска составляет почти 100%, а также замедление пакетных процессов, которые выполнялись в то время. Исправление конфигурации MySQL для увеличения размера пула буферов для устранения большинства операций чтения похоже на устранение проблемы.
Таким образом, проблема заключалась в том, что диски были настолько загружены, что не могли справиться с большим объемом работы по повторной синхронизации, которую DRBD хотел им бросить.
Попробуйте установить частоту синхронизации
drbdsetup /dev/drbd0 syncer -r 100M
Вы также можете настроить это после перезагрузки через синхронизатор {} в конфигурации
Вы уже нашли источник проблемы - тяжелое чтение io. Настройка sndbuf-size помогает при тяжелой записи-io (но увеличивает асинхронность в режиме протокола A), rcvbuf-size мог бы помочь в вашем случае.
Но лучшим решением было удалить корень вашей проблемы.
Больше чтений также может быть связано с DRBD-мета-устройством (хотя я ожидал бы, что больше и в ситуациях записи).