1. дома
  2. Вопрос и ответ
  3. Кассандра разделяет разделение мозга

Кассандра разделяет разделение мозга

2015-08-31 1 views
4

Мы используем 6-узловой кластер cassandra в двух зонах доступности AWS (ap-юго-восток-1 и ap-юго-восток-2).Кассандра разделяет разделение мозга

После успешной работы в течение нескольких месяцев кластеру был проведен скользящий перезапуск, чтобы исправить поврежденный ремонт, и теперь каждая группа думает, что другой отключен.

Cluster Information: 
    Name: MegaportGlobal 
    Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch 
    Partitioner: org.apache.cassandra.dht.Murmur3Partitioner 
    Schema versions: 
     220727fa-88d2-366f-9473-777e32744c37: [10.5.13.117, 10.5.12.245, 10.5.13.93] 

     UNREACHABLE: [10.4.0.112, 10.4.0.169, 10.4.2.186] 

Cluster Information: 
    Name: MegaportGlobal 
    Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch 
    Partitioner: org.apache.cassandra.dht.Murmur3Partitioner 
    Schema versions: 
     3932d237-b907-3ef8-95bc-4276dc7f32e6: [10.4.0.112, 10.4.0.169, 10.4.2.186] 

     UNREACHABLE: [10.5.13.117, 10.5.12.245, 10.5.13.93]

От Сиднея, 'статус nodetool' сообщает, что большинство узлов Сингапур вниз:

Datacenter: ap-southeast-2 
========================== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens Owns Host ID        Rack 
UN 10.4.0.112 9.04 GB 256  ?  b9c19de4-4939-4112-bf07-d136d8a57b57 2a 
UN 10.4.0.169 9.34 GB 256  ?  2d7c3ac4-ae94-43d6-9afe-7d421c06b951 2a 
UN 10.4.2.186 10.72 GB 256  ?  4dc8b155-8f9a-4532-86ec-d958ac207f40 2b 
Datacenter: ap-southeast-1 
========================== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens Owns Host ID        Rack 
UN 10.5.13.117 9.45 GB 256  ?  324ee189-3e72-465f-987f-cbc9f7bf740b 1a 
DN 10.5.12.245 10.25 GB 256  ?  bee281c9-715b-4134-a033-00479a390f1e 1b 
DN 10.5.13.93 12.29 GB 256  ?  a8262244-91bb-458f-9603-f8c8fe455924 1a

Но из Сингапура, все узлы Сидней представлены как вниз:

ap-southeast-2 
========================== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens Owns Host ID        Rack 
DN 10.4.0.112 8.91 GB 256  ?  b9c19de4-4939-4112-bf07-d136d8a57b57 2a 
DN 10.4.0.169 ?   256  ?  2d7c3ac4-ae94-43d6-9afe-7d421c06b951 2a 
DN 10.4.2.186 ?   256  ?  4dc8b155-8f9a-4532-86ec-d958ac207f40 2b 
Datacenter: ap-southeast-1 
========================== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address  Load  Tokens Owns Host ID        Rack 
UN 10.5.13.117 9.45 GB 256  ?  324ee189-3e72-465f-987f-cbc9f7bf740b 1a 
UN 10.5.12.245 10.25 GB 256  ?  bee281c9-715b-4134-a033-00479a390f1e 1b 
UN 10.5.13.93 12.29 GB 256  ?  a8262244-91bb-458f-9603-f8c8fe455924 1a

Еще более запутанный, «nodetool gossipinfo», выполненный в Сиднее, сообщает, что все в порядке с Status - Normal:

/10.5.13.117 
    generation:1440735653 
    heartbeat:724504 
    SEVERITY:0.0 
    DC:ap-southeast-1 
    LOAD:1.0149565738E10 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RACK:1a 
    STATUS:NORMAL,-1059943672916788858 
    RELEASE_VERSION:2.1.6 
    NET_VERSION:8 
    RPC_ADDRESS:10.5.13.117 
    INTERNAL_IP:10.5.13.117 
    HOST_ID:324ee189-3e72-465f-987f-cbc9f7bf740b 
/10.5.12.245 
    generation:1440734497 
    heartbeat:728014 
    SEVERITY:0.0 
    DC:ap-southeast-1 
    LOAD:1.100647505E10 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RACK:1b 
    STATUS:NORMAL,-1029869455226513030 
    RELEASE_VERSION:2.1.6 
    NET_VERSION:8 
    RPC_ADDRESS:10.5.12.245 
    INTERNAL_IP:10.5.12.245 
    HOST_ID:bee281c9-715b-4134-a033-00479a390f1e 
/10.4.0.112 
    generation:1440973751 
    heartbeat:4135 
    SEVERITY:0.0 
    DC:ap-southeast-2 
    LOAD:9.70297176E9 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RACK:2a 
    RELEASE_VERSION:2.1.6 
    STATUS:NORMAL,-1016623069114845926 
    NET_VERSION:8 
    RPC_ADDRESS:10.4.0.112 
    INTERNAL_IP:10.4.0.112 
    HOST_ID:b9c19de4-4939-4112-bf07-d136d8a57b57 
/10.5.13.93 
    generation:1440734532 
    heartbeat:727909 
    SEVERITY:0.0 
    DC:ap-southeast-1 
    LOAD:1.3197536002E10 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RACK:1a 
    STATUS:NORMAL,-1021689296016263011 
    RELEASE_VERSION:2.1.6 
    NET_VERSION:8 
    RPC_ADDRESS:10.5.13.93 
    INTERNAL_IP:10.5.13.93 
    HOST_ID:a8262244-91bb-458f-9603-f8c8fe455924 
/10.4.0.169 
    generation:1440974511 
    heartbeat:1832 
    SEVERITY:0.0 
    DC:ap-southeast-2 
    LOAD:1.0023502338E10 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RACK:2a 
    RELEASE_VERSION:2.1.6 
    STATUS:NORMAL,-1004223692762353764 
    NET_VERSION:8 
    RPC_ADDRESS:10.4.0.169 
    INTERNAL_IP:10.4.0.169 
    HOST_ID:2d7c3ac4-ae94-43d6-9afe-7d421c06b951 
/10.4.2.186 
    generation:1440734382 
    heartbeat:730171 
    SEVERITY:0.0 
    DC:ap-southeast-2 
    LOAD:1.1507595081E10 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RACK:2b 
    STATUS:NORMAL,-10099894685483463 
    RELEASE_VERSION:2.1.6 
    NET_VERSION:8 
    RPC_ADDRESS:10.4.2.186 
    INTERNAL_IP:10.4.2.186 
    HOST_ID:4dc8b155-8f9a-4532-86ec-d958ac207f40

Та же команда, выполненная в Сингапуре не включает в себя STATUS для любых узлов в Сиднее:

/10.5.12.245 
    generation:1440974710 
    heartbeat:1372 
    SEVERITY:0.0 
    LOAD:1.100835806E10 
    RPC_ADDRESS:10.5.12.245 
    NET_VERSION:8 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RELEASE_VERSION:2.1.6 
    STATUS:NORMAL,-1029869455226513030 
    DC:ap-southeast-1 
    RACK:1b 
    INTERNAL_IP:10.5.12.245 
    HOST_ID:bee281c9-715b-4134-a033-00479a390f1e 
/10.5.13.117 
    generation:1440974648 
    heartbeat:1561 
    SEVERITY:0.0 
    LOAD:1.0149992022E10 
    RPC_ADDRESS:10.5.13.117 
    NET_VERSION:8 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RELEASE_VERSION:2.1.6 
    STATUS:NORMAL,-1059943672916788858 
    DC:ap-southeast-1 
    RACK:1a 
    HOST_ID:324ee189-3e72-465f-987f-cbc9f7bf740b 
    INTERNAL_IP:10.5.13.117 
/10.4.0.112 
    generation:1440735420 
    heartbeat:23 
    SEVERITY:0.0 
    LOAD:9.570546197E9 
    RPC_ADDRESS:10.4.0.112 
    NET_VERSION:8 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RELEASE_VERSION:2.1.6 
    DC:ap-southeast-2 
    RACK:2a 
    INTERNAL_IP:10.4.0.112 
    HOST_ID:b9c19de4-4939-4112-bf07-d136d8a57b57 
/10.5.13.93 
    generation:1440734532 
    heartbeat:729862 
    SEVERITY:0.0 
    LOAD:1.3197536002E10 
    RPC_ADDRESS:10.5.13.93 
    NET_VERSION:8 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RELEASE_VERSION:2.1.6 
    STATUS:NORMAL,-1021689296016263011 
    DC:ap-southeast-1 
    RACK:1a 
    INTERNAL_IP:10.5.13.93 
    HOST_ID:a8262244-91bb-458f-9603-f8c8fe455924 
/10.4.0.169 
    generation:1440974511 
    heartbeat:15 
    SEVERITY:0.5076141953468323 
    RPC_ADDRESS:10.4.0.169 
    NET_VERSION:8 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RELEASE_VERSION:2.1.6 
    DC:ap-southeast-2 
    RACK:2a 
    INTERNAL_IP:10.4.0.169 
    HOST_ID:2d7c3ac4-ae94-43d6-9afe-7d421c06b951 
/10.4.2.186 
    generation:1440734382 
    heartbeat:15 
    SEVERITY:0.0 
    RPC_ADDRESS:10.4.2.186 
    NET_VERSION:8 
    SCHEMA:7bf335ee-61ae-36c6-a902-c70d785ec7a3 
    RELEASE_VERSION:2.1.6 
    DC:ap-southeast-2 
    RACK:2b 
    INTERNAL_IP:10.4.2.186 
    HOST_ID:4dc8b155-8f9a-4532-86ec-d958ac207f40

Во время перезагрузки, каждый узел может видеть удаленный DC некоторое время:

INFO [GossipStage:1] 2015-08-31 10:53:07,638 OutboundTcpConnection.java:97 - OutboundTcpConnection using coalescing strategy DISABLED 
INFO [HANDSHAKE-/10.4.2.186] 2015-08-31 10:53:08,267 OutboundTcpConnection.java:485 - Handshaking version with /10.4.2.186 
INFO [HANDSHAKE-/10.4.0.169] 2015-08-31 10:53:08,287 OutboundTcpConnection.java:485 - Handshaking version with /10.4.0.169 
INFO [HANDSHAKE-/10.5.12.245] 2015-08-31 10:53:08,391 OutboundTcpConnection.java:485 - Handshaking version with /10.5.12.245 
INFO [HANDSHAKE-/10.5.13.93] 2015-08-31 10:53:08,498 OutboundTcpConnection.java:485 - Handshaking version with /10.5.13.93 
INFO [GossipStage:1] 2015-08-31 10:53:08,537 Gossiper.java:987 - Node /10.5.12.245 has restarted, now UP 
INFO [HANDSHAKE-/10.5.13.117] 2015-08-31 10:53:08,537 OutboundTcpConnection.java:485 - Handshaking version with /10.5.13.117 
INFO [GossipStage:1] 2015-08-31 10:53:08,656 StorageService.java:1642 - Node /10.5.12.245 state jump to normal 
INFO [GossipStage:1] 2015-08-31 10:53:08,820 Gossiper.java:987 - Node /10.5.13.117 has restarted, now UP 
INFO [GossipStage:1] 2015-08-31 10:53:08,852 Gossiper.java:987 - Node /10.5.13.93 has restarted, now UP 
INFO [SharedPool-Worker-33] 2015-08-31 10:53:08,907 Gossiper.java:954 - InetAddress /10.5.12.245 is now UP 
INFO [GossipStage:1] 2015-08-31 10:53:08,947 StorageService.java:1642 - Node /10.5.13.93 state jump to normal 
INFO [GossipStage:1] 2015-08-31 10:53:09,007 Gossiper.java:987 - Node /10.4.0.169 has restarted, now UP 
WARN [GossipTasks:1] 2015-08-31 10:53:09,123 FailureDetector.java:251 - Not marking nodes down due to local pause of 7948322997 > 5000000000 
INFO [GossipStage:1] 2015-08-31 10:53:09,192 StorageService.java:1642 - Node /10.4.0.169 state jump to normal 
INFO [HANDSHAKE-/10.5.12.245] 2015-08-31 10:53:09,199 OutboundTcpConnection.java:485 - Handshaking version with /10.5.12.245 
INFO [GossipStage:1] 2015-08-31 10:53:09,203 Gossiper.java:987 - Node /10.4.2.186 has restarted, now UP 
INFO [GossipStage:1] 2015-08-31 10:53:09,206 StorageService.java:1642 - Node /10.4.2.186 state jump to normal 
INFO [SharedPool-Worker-34] 2015-08-31 10:53:09,215 Gossiper.java:954 - InetAddress /10.5.13.93 is now UP 
INFO [SharedPool-Worker-33] 2015-08-31 10:53:09,259 Gossiper.java:954 - InetAddress /10.5.13.117 is now UP 
INFO [SharedPool-Worker-33] 2015-08-31 10:53:09,259 Gossiper.java:954 - InetAddress /10.4.0.169 is now UP 
INFO [SharedPool-Worker-33] 2015-08-31 10:53:09,259 Gossiper.java:954 - InetAddress /10.4.2.186 is now UP 
INFO [GossipStage:1] 2015-08-31 10:53:09,296 StorageService.java:1642 - Node /10.4.0.169 state jump to normal 
INFO [GossipStage:1] 2015-08-31 10:53:09,491 StorageService.java:1642 - Node /10.5.12.245 state jump to normal 
INFO [HANDSHAKE-/10.5.13.117] 2015-08-31 10:53:09,509 OutboundTcpConnection.java:485 - Handshaking version with /10.5.13.117 
INFO [GossipStage:1] 2015-08-31 10:53:09,511 StorageService.java:1642 - Node /10.5.13.93 state jump to normal 
INFO [HANDSHAKE-/10.5.13.93] 2015-08-31 10:53:09,538 OutboundTcpConnection.java:485 - Handshaking version with /10.5.13.93

Тогда, без каких-либо ошибок, узлы помечены как вниз:

INFO [GossipTasks:1] 2015-08-31 10:53:34,410 Gossiper.java:968 - InetAddress /10.5.13.117 is now DOWN 
INFO [GossipTasks:1] 2015-08-31 10:53:34,411 Gossiper.java:968 - InetAddress /10.5.12.245 is now DOWN 
INFO [GossipTasks:1] 2015-08-31 10:53:34,411 Gossiper.java:968 - InetAddress /10.5.13.93 is now DOWN

Мы попробовали несколько перезапусков, но поведение остается прежним.

* редактировать

Это выглядит быть связано с протоколом Сплетни ... Включение дополнительной отладки показывает, что значения ФИ неуклонно растет:

TRACE [GossipTasks:1] 2015-08-31 16:46:44,706 FailureDetector.java:262 - PHI for /10.4.0.112 : 2.9395029255 
TRACE [GossipTasks:1] 2015-08-31 16:46:45,727 FailureDetector.java:262 - PHI for /10.4.0.112 : 3.449690761 
TRACE [GossipTasks:1] 2015-08-31 16:46:46,728 FailureDetector.java:262 - PHI for /10.4.0.112 : 3.95049114 
TRACE [GossipTasks:1] 2015-08-31 16:46:47,730 FailureDetector.java:262 - PHI for /10.4.0.112 : 4.451317456 
TRACE [GossipTasks:1] 2015-08-31 16:46:48,732 FailureDetector.java:262 - PHI for /10.4.0.112 : 4.952114357 
TRACE [GossipTasks:1] 2015-08-31 16:46:49,733 FailureDetector.java:262 - PHI for /10.4.0.112 : 5.4529339645 
TRACE [GossipTasks:1] 2015-08-31 16:46:50,735 FailureDetector.java:262 - PHI for /10.4.0.112 : 5.953951289 
TRACE [GossipTasks:1] 2015-08-31 16:46:51,737 FailureDetector.java:262 - PHI for /10.4.0.112 : 6.4547808165 
TRACE [GossipTasks:1] 2015-08-31 16:46:52,738 FailureDetector.java:262 - PHI for /10.4.0.112 : 6.955600038 
TRACE [GossipTasks:1] 2015-08-31 16:46:53,740 FailureDetector.java:262 - PHI for /10.4.0.112 : 7.456422601 
TRACE [GossipTasks:1] 2015-08-31 16:46:54,742 FailureDetector.java:262 - PHI for /10.4.0.112 : 7.957303284 
TRACE [GossipTasks:1] 2015-08-31 16:46:55,751 FailureDetector.java:262 - PHI for /10.4.0.112 : 8.461658576 
TRACE [GossipTasks:1] 2015-08-31 16:46:56,755 FailureDetector.java:262 - PHI for /10.4.0.112 : 8.9636610545 
TRACE [GossipTasks:1] 2015-08-31 16:46:57,763 FailureDetector.java:262 - PHI for /10.4.0.112 : 9.4676926445

Значения PHI неуклонно возрастать после перезагрузки , пока они не превысят порог отказа и не будут отмечены как DOWN.

Любые предложения о том, как действовать?

источник

2015-08-31 Adam Wells

+0

Статус, показанный 'nodetool gossipinfo', будет указывать только статус начальной загрузки/нормального/остаточного жизненного цикла, объявленный соответствующим узлом с помощью сплетен.Он соответствует полю «State = Normal/Leaving/Joining/Moving» в состоянии «nodetool», но не указывает, достигнут ли узел всеми другими узлами («Состояние вверх/вниз»). В вашем случае, похоже, это проблемы с подключением между узлами, которые могут быть вызваны сетевыми проблемами. Вы должны запустить 'tcpdump' на двух узлах, пытающихся сплетничать между собой, чтобы узнать, так ли это. –

ответ

2

Для локальной сети поднимите порог обнаружения ошибки phi до 12 или 15. Это обычно требуется в AWS, особенно в кросс-области.

источник

2015-09-01 04:24:40

+0

Мы уже увеличили его до 12, как в документах. Значение PHI начинается с низкого уровня, но растет быстро и линейно с течением времени и превышает пороговое значение примерно через 30 секунд. Оно быстро проникает в 1000, поэтому даже большее значение не поможет. Текущее мышление состоит в том, чтобы очистить состояние сплетен и выполните весь перезапуск кластера ... –

+0

Вы сделали tcpdump, чтобы убедиться, что они действительно общаются? Значение phi должно продолжать увеличиваться каждый раз, когда сердцебиение пропущено - если он поднимается Конечно, это не общение правильно? Предположительно, группы безопасности должны быть правильными, но tcpdump между узлами на 7000, чтобы увидеть, удаляет ли потоки tcp? –

+0

мы запускаем tcdump, и мы видим связь. В C * logs (TRACE) я вижу GossipDigestSynMessage, а затем GossipDigestAckMessage, но не GossipDigestAck2Message ... Возможно, проблема MTU? Вам нужно потратить больше времени на tcpdump ... –

2

Проблема оказалась сетевыми связями с AWS, в частности сетевым MTU. Из-за тонкой проблемы с нашей конфигурацией маршрутизации путь данных стал асимметричным между Сиднеем и Сингапурским AWS.

Я думаю, что извлеченный урок состоит в том, что если режимы счастливы в DC, а не между DC, то это, скорее всего, сеть, и такие вещи, как MTU, даже если пинг и telnet и т. Д. Выглядят нормально.

Благодаря Джеффу и Стефану за ваш вклад - я куплю вам пиво, если вы когда-нибудь окажетесь в Брисбене!

источник

2015-09-04 05:59:17

 Смежные вопросы

  • Нет связанных вопросов^_^