У меня есть настройка pacemaker / corosync / drbd на 2 физически идентичных серверах Ubuntu 16.04 LTS, и я пытаюсь добиться высокой доступности для MySQL 5.7 и Apache 2.4.
Оба сервера настроены одинаково и имеют одинаковые пакеты. Единственные различия - это имена хостов, IP-адреса и конфигурация ведущий / ведомый в pacemaker / corosync / drbd.
Моя проблема в том, что кардиостимулятор может запустить сервер MySQL и любую другую службу на узле 1, но когда я имитирую сбой узла 1, кардиостимулятор не может запустить службу MySQL на узле 2.
Это результат работы crm_mon (оба узла в сети):
Last updated: Wed Jan 10 18:57:02 2018 Last change: Wed Jan 10 18:00:19
2018 by root via crm_attribute on Server1
Stack: corosync
Current DC: Server1 (version 1.1.14-70404b0) - partition with quorum
2 nodes and 7 resources configured
Online: [ Server1 Server2 ]
Master/Slave Set: ms_r0 [r0]
Masters: [ Server1 ]
Slaves: [ Server2 ]
Resource Group: WebServer
ClusterIP (ocf::heartbeat:IPaddr2): Started Server1
WebFS (ocf::heartbeat:Filesystem): Started Server1
Links (ocf::heartbeat:drbdlinks): Started Server1
DBase (ocf::heartbeat:mysql): Started Server1
WebSite (ocf::heartbeat:apache): Started Server1
Но когда я имитирую крах узла 1, я получаю:
Last updated: Wed Jan 10 19:05:25 2018 Last change: Wed Jan 10 19:05:17
2018 by root via crm_attribute on Server1
Stack: corosync
Current DC: Server1 (version 1.1.14-70404b0) - partition with quorum
2 nodes and 7 resources configured
Node Server1: standby
Online: [ Server2 ]
Master/Slave Set: ms_r0 [r0]
Masters: [ Server2 ]
Resource Group: WebServer
ClusterIP (ocf::heartbeat:IPaddr2): Started Server2
WebFS (ocf::heartbeat:Filesystem): Started Server2
Links (ocf::heartbeat:drbdlinks): Started Server2
DBase (ocf::heartbeat:mysql): Stopped
WebSite (ocf::heartbeat:apache): Stopped
Failed Actions:
* DBase_start_0 on Server2 'unknown error' (1): call=45, status=complete
, exitreason='MySQL server failed to start (pid=3346) (rc=1), please check your
installation',
last-rc-change='Wed Jan 10 17:58:15 2018', queued=0ms, exec=2202ms
Это была моя изначальная конфигурация кардиостимулятора: https://pastebin.com/kEYjjgKw
После того, как я понял, что есть проблема с запуском MySQL на узле 2, я провел небольшое исследование и прочитал, что один shoudl передает некоторые дополнительные параметры MySQL в конфигурации кардиостимулятора. Вот почему я изменил конфигурацию кардиостимулятора на эту: https://pastebin.com/J7Zk1kBA
К сожалению, это не решило проблему.
Насколько я понимаю, Pacemaker использует одну и ту же команду на обеих машинах для запуска демона MySQL. Вот почему мне кажется абсурдным, что MySQL не запускается на узле 2, который был настроен точно так же.
drbd0 монтируется кардиостимулятором, а drbdlinks создает символические ссылки для / var / www и / var / lib / mysql
Я протестировал эту функциональность, и, похоже, она работает. Когда узел 1 отключен, drbd0 монтируется на узле 2 и создаются символические ссылки. / var / lib / mysql указывает на drbd0, и все файлы находятся в каталоге.
Если у вас есть идеи / советы о том, как сузить причину этой проблемы, я был бы очень благодарен, если бы вы разместили их здесь.
Если потребуется дополнительная информация, я с радостью ее предоставлю.
Заранее спасибо!
С уважением, PAlbrecht
Когда мне приходилось работать с кардиостимулятором в прошлом, я использую несколько различных процедур для устранения неполадок такого рода. Общая идея состоит в том, чтобы проверить каждый "уровень" зависимостей в конфигурации кардиостимулятора, где график зависимостей выглядит следующим образом:
mysql -> mounting of filesystem -> DRBD master
Также Кластеры с нуля имеет хорошее пошаговое руководство по очень похожей конфигурации.
Прежде всего, убедитесь, что DRBD настроен и синхронизирован. На любом узле запустите:
cat /proc/drbd
Выходные данные должны показать примерно следующее, если DRBD полностью синхронизирован и готов к аварийному переключению (см. Стр. 45 CfS):
[root@pcmk-1 ~]# cat /proc/drbd
version: 8.4.6 (api:1/proto:86-101)
GIT-hash: 833d830e0152d1e457fa7856e71e11248ccf3f70 build by phil@Build64R7, 2015-04-10
05:13:52
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:1048508 nr:0 dw:0 dr:1049420 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Если
cat /proc/drbd
выводит что-то вроде (также на стр. 45 CfS)
[root@ovz-node1 ~]# cat /proc/drbd
version: 0.7.17 (api:77/proto:74)
SVN Revision: 2093 build by phil@mescal, 2006-03-06 15:04:12
0: cs:SyncSource st:Primary/Secondary ld:Consistent
ns:627252 nr:0 dw:0 dr:629812 al:0 bm:38 lo:640 pe:0 ua:640 ap:0
[=>..................] sync'ed: 6.6% (8805/9418)M
finish: 0:04:51 speed: 30,888 (27,268) K/sec
тогда система не в том состоянии, в котором она может успешно переключиться. Подождите, пока он завершится, а затем повторите тест переключения при отказе.
Предполагая, что DRBD был синхронизирован до смоделированного сбоя node1, следующее, что нужно попробовать после переключения на node2, когда БД не работает на node2, - это войти в node2 и проверить следующее:
cat /proc/drbd показать узел2 как основной?mount показать / dev / drbd0, смонтированный в настроенной точке монтирования (из pastebin, это должно быть '/ sync')?и самое главное, если на все эти вопросы дан положительный ответ:
/etc/init.d/mysql start или эквивалент systemctl)?Если MySQL запускается вручную, то, вероятно, что-то не так в конфигурации его кардиостимулятора.
Полное раскрытие: я лично не использовал ресурс ocf :: heartbeat: mysql; вместо этого я использовал ресурс lsb lsb: mysql.