Hi Adam The startup sequence should be NameServer -> Master -> Slave1 ->
Slave2, you could check the cluster's status ofter each step and figure out
where is the problem.
is your 1master, 2 slaves deployed on three machines ? if not there is commit
log store position conflict.
Mark.------------------------------------------------------------------发件人：Adam
Warski <[email protected]>发送时间：2017年10月2日(星期一) 22:09收件人：users
<[email protected]>主 题：Trying to set up a RocketMQ cluster
Hello,
I'm trying to set up a RocketMQ cluster, with a single name server, 1 slave and
2 masters. But, I'm running into some problems.
The version I'm running is downloaded from
https://github.com/apache/incubator-rocketmq/archive/rocketmq-all-4.1.0-incubating.zip.The
brokers are run using mqbroker -c broker.conf, where broker.conf differs for
master and slave. For the master I have:
listenPort=10911brokerName=mybrokerbrokerClusterName=mybrokerclusterbrokerId=0deleteWhen=04fileReservedTime=48brokerRole=SYNC_MASTERflushDiskType=ASYNC_FLUSH
And for slaves:
listenPort=10911brokerName=mybrokerbrokerClusterName=mybrokerclusterbrokerId=1
deleteWhen=04fileReservedTime=48brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
The second slave has brokerId=2.Brokers start up fine, some parts of the logs
for a slave:
2017-10-02 20:31:35 INFO main - brokerRole=ASYNC_MASTER2017-10-02 20:31:35 INFO
main - flushDiskType=ASYNC_FLUSH(...)2017-10-02 20:31:35 INFO main - Replace,
key: brokerId, value: 0 -> 12017-10-02 20:31:35 INFO main - Replace, key:
brokerRole, value: ASYNC_MASTER -> SLAVE(...)2017-10-02 20:31:37 INFO main -
Set user specified name server address: 172.22.1.38:98762017-10-02 20:31:37
INFO ShutdownHook - Shutdown hook was invoked, 12017-10-02 20:31:37 INFO
ShutdownHook - shutdown thread PullRequestHoldService interrupt false2017-10-02
20:31:37 INFO ShutdownHook - join thread PullRequestHoldService eclipse
time(ms) 0 900002017-10-02 20:31:37 WARN ShutdownHook - unregisterBroker
Exception,
172.22.1.38:9876org.apache.rocketmq.remoting.exception.RemotingConnectException:
connect to <172.22.1.38:9876> failed at
org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:359)
~[rocketmq-remoting-4.1.0-incubating.jar:4.1.0-incubating] at
org.apache.rocketmq.broker.out.BrokerOuterAPI.unregisterBroker(BrokerOuterAPI.java:221)
~[rocketmq-broker-4.1.0-incubating.jar:4.1.0-incubating] at
org.apache.rocketmq.broker.out.BrokerOuterAPI.unregisterBrokerAll(BrokerOuterAPI.java:198)
~[rocketmq-broker-4.1.0-incubating.jar:4.1.0-incubating] at
org.apache.rocketmq.broker.BrokerController.unregisterBrokerAll(BrokerController.java:623)
[rocketmq-broker-4.1.0-incubating.jar:4.1.0-incubating] at
org.apache.rocketmq.broker.BrokerController.shutdown(BrokerController.java:589)
[rocketmq-broker-4.1.0-incubating.jar:4.1.0-incubating] at
org.apache.rocketmq.broker.BrokerStartup$1.run(BrokerStartup.java:218)
[rocketmq-broker-4.1.0-incubating.jar:4.1.0-incubating] at
java.lang.Thread.run(Thread.java:748) [na:1.8.0_141]2017-10-02 20:31:37 INFO
ShutdownHook - Shutdown hook over, consuming total time(ms): 252017-10-02
20:31:45 INFO BrokerControllerScheduledThread1 - dispatch behind commit log 0
bytes2017-10-02 20:31:45 INFO BrokerControllerScheduledThread1 - Slave fall
behind master: 0 bytes2017-10-02 20:31:45 INFO BrokerControllerScheduledThread1
- register broker to name server 172.22.1.38:9876 OK2017-10-02 20:32:15 INFO
BrokerControllerScheduledThread1 - register broker to name server
172.22.1.38:9876 OK
As I suspect the broker is trying to connect to the name server, which isn't
running initially, so it retries and eventually succeeds?
However, later when trying clusterList I only see one broker listed, which
happens to be a slave (172.22.1.17) and has brokerId=2 in the configuration
(although here it's listed as 0):
$ ./mqadmin clusterList -n 172.22.1.38:9876#Cluster Name #Broker Name
#BID #Addr #Version #InTPS(LOAD)
#OutTPS(LOAD) #PCWait(ms) #Hour #SPACEmqperfcluster mqperf
0 172.22.1.17:10911 V4_1_0_SNAPSHOT 0.00(0,0ms)
0.00(0,0ms) 0 418597.80 -1.0000
Moreover, when sending messages to the master, I get SLAVE_NOT_AVAILABLE.
Why is that? Are the brokers configured properly? If so, wy does clusterList
report them incorrectly?
Thanks!Adam
