Thanks, starting the nodes in order helped! I first need to start master,
wait until it's started, then start slave1 etc.

Adam

On Sat, Oct 7, 2017 at 11:53 AM, 杨开元 <mark....@alibaba-inc.com> wrote:

> 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 <a...@warski.org>
> 发送时间:2017年10月2日(星期一) 22:09
> 收件人:users <users@rocketmq.apache.org>
> 主 题: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=10911
> brokerName=mybroker
> brokerClusterName=mybrokercluster
> brokerId=0
> deleteWhen=04
> fileReservedTime=48
> brokerRole=SYNC_MASTER
> flushDiskType=ASYNC_FLUSH
>
> And for slaves:
>
> listenPort=10911
> brokerName=mybroker
> brokerClusterName=mybrokercluster
> brokerId=1
> deleteWhen=04
> fileReservedTime=48
> brokerRole=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_MASTER
> 2017-10-02 20:31:35 INFO main - flushDiskType=ASYNC_FLUSH
> (...)
> 2017-10-02 20:31:35 INFO main - Replace, key: brokerId, value: 0 -> 1
> 2017-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:9876
> 2017-10-02 20:31:37 INFO ShutdownHook - Shutdown hook was invoked, 1
> 2017-10-02 20:31:37 INFO ShutdownHook - shutdown thread
> PullRequestHoldService interrupt false
> 2017-10-02 20:31:37 INFO ShutdownHook - join thread PullRequestHoldService
> eclipse time(ms) 0 90000
> 2017-10-02 20:31:37 WARN ShutdownHook - unregisterBroker Exception,
> 172.22.1.38:9876
> org.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): 25
> 2017-10-02 20:31:45 INFO BrokerControllerScheduledThread1 - dispatch
> behind commit log 0 bytes
> 2017-10-02 20:31:45 INFO BrokerControllerScheduledThread1 - Slave fall
> behind master: 0 bytes
> 2017-10-02 20:31:45 INFO BrokerControllerScheduledThread1 - register
> broker to name server 172.22.1.38:9876 OK
> 2017-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
> #SPACE
> mqperfcluster     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
>
>
>
>
>

Reply via email to