From users-return-51471-archive-asf-public=cust-asf.ponee.io@activemq.apache.org Thu Jun 6 18:31:09 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id BDAE018062B for ; Thu, 6 Jun 2019 20:31:08 +0200 (CEST) Received: (qmail 6268 invoked by uid 500); 6 Jun 2019 18:31:07 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 6257 invoked by uid 99); 6 Jun 2019 18:31:07 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jun 2019 18:31:07 +0000 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 5B6768AA7 for ; Thu, 6 Jun 2019 18:31:07 +0000 (UTC) Received: by mail-ot1-f49.google.com with SMTP id i8so2884775oth.10 for ; Thu, 06 Jun 2019 11:31:07 -0700 (PDT) X-Gm-Message-State: APjAAAWKX9xlUyk0KeIgMlTVL9Z44+TduslYnLNsyv/Okp/820qgaby1 sB/h/eE1CSqrvAdObnBlMfCCbgSt9ZAJXTlUzn6U0A== X-Google-Smtp-Source: APXvYqyF6ts954TgzbUKiQTiJSH24Z4BAURh7PRCLwgMlvmdkxpFjvPPDHrmz1Xwx7TubGsiAaRLkc4BGKD6HDn9iXs= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr14817212oth.254.1559845866612; Thu, 06 Jun 2019 11:31:06 -0700 (PDT) MIME-Version: 1.0 References: <1559124144757-0.post@n4.nabble.com> <1559212884915-0.post@n4.nabble.com> In-Reply-To: <1559212884915-0.post@n4.nabble.com> From: Justin Bertram Date: Thu, 6 Jun 2019 13:30:40 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Artemis: Recommended topology for reliability? To: users@activemq.apache.org Content-Type: multipart/alternative; boundary="000000000000c8ca59058aabea6f" --000000000000c8ca59058aabea6f Content-Type: text/plain; charset="UTF-8" In a non-automated use-case I'd recommend an administrator take a look at each of the brokers' log files to see which one had been active most recently and then restart that broker first (and if that server happened to be a slave its configuration would need to be changed to be a master so it would fully start rather than just wait for its corresponding master). If your environment is automated then you'll have to develop some kind of process to approximate what an administrator would do. That said, in a fully automated environment a master/slave pair may not make much sense. Presumably the automation could simply restart the master broker when it dies and clients can simply reconnect. Combined with a redundant, robust file store this is a viable solution for high availability. Justin On Thu, May 30, 2019 at 5:41 AM Bummer wrote: > /One issue to be aware of is: in case of a successful fail-over, the > backup's > data will be newer than the one at the live's storage. If you configure > your > live server to perform a failback to live server when restarted, it will > synchronize its data with the backup's. If both servers are shutdown, the > administrator will have to determine which one has the latest data./ > Source > < > https://activemq.apache.org/components/artemis/documentation/latest/ha.html> > > > How do I overcome this in an automated environment without having a full > control over server restarts? > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html > --000000000000c8ca59058aabea6f--