点燃无法加入群集的节点，无限期地等待协调器响应。

Question

我正在使用TcpDiscoveryJdbcIpFinder运行ApacheIgnite2.7.0的两个服务器节点(A和B)以进行发现。

当我将B作为第一个节点启动，然后启动一个节点时，一切都很好。

但是，当我启动A作为第一个节点，然后启动B，B节点无限期地停留，试图加入集群。

当我检查日志时，我发现节点B加入了集群，分区交换开始了.

  2019-09-05 10:59:51,850 | disco-event-worker-#39         | INFO  | org.apache.ignite.internal.managers.discovery.GridDiscoveryManager               | 
Added new node to topology: TcpDiscoveryNode [id=686bdf14-201c-43f3-8617-05c7e51224ea, addrs=[10.49.95.44], sockAddrs=[some2.domain/10.49.95.44:47500], discPort=47500, order=2, intOrder=2, lastExchangeTime=1567673970663, loc=false, ver=2.7.0#20181130-sha1:256ae401, isClient=false] |  
2019-09-05 10:59:51,850 | disco-event-worker-#39         | DEBUG | org.apache.ignite.internal.managers.discovery.GridDiscoveryManager               | /
//
/>>> +----------------+/
/>>> Topology snapshot./
/>>> +----------------+/
/>>> Ignite instance name: default/
/>>> <b>Number of server nodes: 2</b>/
/>>> Number of client nodes: 0/
/>>> Topology version: 2/
/>>> Local: F5DBEC80-D22F-4977-A534-A0E9425A77BB, [some.domain/10.49.94.205], 1, Windows Server 2012 R2 amd64 6.3, admBruegel, Java(TM) SE Runtime Environment 1.8.0_202-b08/
/>>> Remote: 686BDF14-201C-43F3-8617-05C7E51224EA, [some2.domain/10.49.95.44], 2, Windows Server 2016 amd64 10.0, admBruegel, Java(TM) SE Runtime Environment 1.8.0_202-b08/
/>>> Total number of CPUs: 4/
/>>> Total heap size: 32.0GB/
/>>> Total offheap size: 4.9GB/

一段时间后，节点A接收节点B的NODE_FAILED事件，尽管它正在运行并等待节点A完成连接过程。

2019-09-05 10:59:51,881 | disco-event-worker-#39         | WARN  | org.apache.ignite.internal.managers.discovery.GridDiscoveryManager               | 
Node FAILED: TcpDiscoveryNode [id=686bdf14-201c-43f3-8617-05c7e51224ea, addrs=[10.49.95.44], sockAddrs=[some2.domain/10.49.95.44:47500], discPort=47500, order=2, intOrder=2, lastExchangeTime=1567673970663, loc=false, ver=2.7.0#20181130-sha1:256ae401, isClient=false] |  
2019-09-05 10:59:51,881 | disco-event-worker-#39         | DEBUG | org.apache.ignite.internal.managers.discovery.GridDiscoveryManager               | /
//
/>>> +----------------+/
/>>> Topology snapshot./
/>>> +----------------+/
/>>> Ignite instance name: default/
/>>> Number of server nodes: 1/
/>>> Number of client nodes: 0/
/>>> Topology version: 3/
/>>> Local: F5DBEC80-D22F-4977-A534-A0E9425A77BB, [some.domain/10.49.94.205], 1, Windows Server 2012 R2 amd64 6.3, admBruegel, Java(TM) SE Runtime Environment 1.8.0_202-b08/
/>>> Total number of CPUs: 2/
/>>> Total heap size: 16.0GB/
/>>> Total offheap size: 2.5GB/
/ |  
2019-09-05 10:59:51,881 | disco-net-seg-chk-worker-#38   | DEBUG | org.apache.ignite.internal.managers.discovery.GridDiscoveryManager               
| Segment has been checked [requested=true, valid=true] |  
2019-09-05 10:59:51,881 | disco-event-worker-#39         | DEBUG | org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore     
| Processing node departure event: DiscoveryEvent [evtNode=TcpDiscoveryNode [id=686bdf14-201c-43f3-8617-05c7e51224ea, addrs=[10.49.95.44], sockAddrs=[some2.domain/10.49.95.44:47500], discPort=47500, order=2, intOrder=2, lastExchangeTime=1567673970663, loc=false, ver=2.7.0#20181130-sha1:256ae401, isClient=false], topVer=3, nodeId8=f5dbec80, msg=Node failed: TcpDiscoveryNode [id=686bdf14-201c-43f3-8617-05c7e51224ea, addrs=[10.49.95.44], sockAddrs=[some2.domain/10.49.95.44:47500], discPort=47500, order=2, intOrder=2, lastExchangeTime=1567673970663, loc=false, ver=2.7.0#20181130-sha1:256ae401, isClient=false], type=NODE_FAILED, tstamp=1567673991881] |  
2019-09-05 10:59:51,881 | disco-event-worker-#39         | DEBUG | org.apache.ignite.internal.processors.cache.GridCacheMvccManager                 
| Processing node left [nodeId=686bdf14-201c-43f3-8617-05c7e51224ea] |  
2019-09-05 10:59:51,897 | disco-event-worker-#39         | DEBUG | org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager           
| Processing node departure: 686bdf14-201c-43f3-8617-05c7e51224ea |  
2019-09-05 10:59:51,897 | disco-event-worker-#39         | DEBUG | org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore          
| Deployment meta for local deployment: GridDeploymentMetadata [depMode=SHARED, alias=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager$$Lambda$153/1190953783, clsName=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager, userVer=null, sndNodeId=f5dbec80-d22f-4977-a534-a0e9425a77bb, clsLdrId=null, clsLdr=null, participants=null, parentLdr=null, record=true, nodeFilter=null, seqNum=n/a] |  
2019-09-05 10:59:51,897 | disco-event-worker-#39         | DEBUG | org.apache.ignite.spi.deployment.local.LocalDeploymentSpi                        
| Registering [ldrRsrcs={ParallelWebappClassLoader

节点B一直在获取Join request message has been sent (waiting for coordinator response)，并将永远等待。

我把networkTimeout和failureDetectionTimeout of IgniteConfiguration提高到

 <property name="failureDetectionTimeout" value="120000"/>
 <property name="networkTimeout" value="120000"/> 

以及networkTimeout和joinTimeout of discoverySpi

 <property name="networkTimeout" value="120000"/>
  <property name="joinTimeout" value="90000"/>

尽管如此，这个问题仍然存在。

两个节点都可以互相切换，并且这些节点之间没有防火墙，因此没有端口被阻塞。这些是两个节点的日志。

我搞不懂为什么会发生这种事。此设置在其他服务器上运行良好。

Answer 1

节点A可以通过发现端口(47500)与节点B对话，但不能通过通信端口(47100)与节点B通话。

在任何一个节点上都有可能减缓初始交换的速度。例如，如果节点B无法解析节点A的某个地址，这可能导致初始交换停止(检查DNS设置等)。