Thanks for the link. To the best of my knowledge, that particular experiment never bore fruit and there is no current effort underway to implement replicated KahaDB.
Regarding NFS, I agree, I wouldn't run a single NFS server for exactly that reason. Running your own NFS cluster in clustered mode would be one option to ensure resiliency. Running a single NFS process in front of a storage array would be another, but you'd still have availability concerns even though you've resolved the durability concerns. Another would be a managed offering such as AWS EFS, which takes all the work off your plate. (I'd use EFS if it were me.) But yes, a single NFS server writing to local storage is not what I had in mind, for exactly the reasons you identified, but that doesn't mean that NFS as a whole isn't a viable option. Also note that if your organization already has a resilient NFS service, you could host your data there rather than build your own just to hold these KahaDB files. Tim On Thu, Jul 8, 2021, 12:08 AM ヤ艾枫o.-- <1169114...@qq.com.invalid> wrote: > Hello, you may have misunderstood me. First ,“Can you please provide the > link where you saw KahaDB replication discussed?”This is the website[1] > Second: > "In the KahaDB on NFS case, your statement that the data is unavailable > when > a broker fails is inaccurate. Because the data is written to an NFS share, > it is readable by many machines, and as soon as a new broker can acquire > the lock due to the active broker's failure, the machine that acquires the > lock will become the active broker" > I know what you mean ,when a broker fails ,a new broker can become a > master. > but wWhat worries me is that after the server where the NFS storage is > located goes down, the whole cluster will be paralyzed, > > > > > > > > > 1.https://activemq.apache.org/kahadb-replication-experimental > > > > > > > ------------------ 原始邮件 ------------------ > 发件人: > "users" > < > tb...@alumni.duke.edu>; > 发送时间: 2021年7月7日(星期三) 晚上8:08 > 收件人: "ActiveMQ Users"<users@activemq.apache.org>; > > 主题: Re: I have a question about levedb > > > > Can you please provide the link where you saw KahaDB replication discussed? > I suspect that the content is very out of date since I'm not aware of any > current development effort to implement replicated KahaDB. > > To the best of my knowledge, the out-of-the-box data store options > available to you are KahaDB on NFS and JDBC (with a number of database > engines supported). You can also use pluggable storage lockers[1] to > decouple the locking technology from the storage technology if necessary > (e.g. for NFSv3 whose locks are not supported). > > In the KahaDB on NFS case, your statement that the data is unavailable when > a broker fails is inaccurate. Because the data is written to an NFS share, > it is readable by many machines, and as soon as a new broker can acquire > the lock due to the active broker's failure, the machine that acquires the > lock will become the active broker, read the data file, and begin receiving > and delivering messages from/to clients. So I think your assessment that > replicated LevelDB is necessary to get resilience without having to use a > SQL database wasn't accurate and led you down the wrong path. You should > use KahaDB on NFSv4. > > 1. https://activemq.apache.org/pluggable-storage-lockers > > Tim > > On Wed, Jul 7, 2021, 12:13 AM ヤ艾枫o.-- <1169114...@qq.com.invalid> > wrote: > > > I learned from the official website that the master-slave modes > currently > > supported are "shared file system master slave" and "JDBC master > slave". > > > > > > "Shared file system master slave": the mode depends on shared files > and > > only exists on one node. If the host of the node is down, the > master-slave > > mode will be invalid > > > > > > "JDBC": the mode needs to rely on the database, which costs a lot. At > the > > same time, the database needs to have the master / slave mode, so > that the > > cluster can be robust. > > > > > > So I had to use activemq+zookeeeper to avoid shared file storage and > JDBC > > database storage > > > > We learned from the official website that masterslave &gt; kahadb > > replication (experimental) is in the experimental stage. Is this mode > > similar to the previous ActiveMQ + zookeeper + leveldb and > independent of > > shared files?At the same time, when can we go online to provide > services > > > > > > ------------------&nbsp;原始邮件&nbsp;------------------ > > 发件人: > > > "users" > > > < > > tb...@alumni.duke.edu&gt;; > > 发送时间:&nbsp;2021年7月5日(星期一) 晚上7:40 > > 收件人:&nbsp;"ActiveMQ Users"<users@activemq.apache.org&gt;; > > > > 主题:&nbsp;Re: I have a question about levedb > > > > > > > > Let me strengthen the statement made by Justin. > > > > The decision to deprecate and soon remove LevelDB was made because > there > > was no developer willing/able to maintain the code and no member of > the > > mailing list willing/able to answer questions, even basic ones, on > this > > mailing list. > > > > If you aren't prepared to answer your own questions by reading the > source > > code without any support from this mailing list, and to debug and fix > any > > bugs you encounter in the Scala code, don't use LevelDB. > > > > And even if you're willing to do those things, you'll be unable to > upgrade > > ActiveMQ to 5.17.0 or later, even if there are security > vulnerabilities or > > other compelling reasons to upgrade. I strongly encourage you to > switch to > > KahaDB immediately. > > > > Tim > > > > On Sun, Jul 4, 2021, 11:45 PM ヤ艾枫o.-- <1169114...@qq.com.invalid > &gt; > > wrote: > > > > &gt; I know the levedb was removed. > > &gt; but now I use zookeeper + ActiveMQ to build master-slave > mode。 > > &gt; > > &gt; > > &gt; > > &gt; > > &gt; > ------------------&amp;nbsp;原始邮件&amp;nbsp;------------------ > > &gt; 发件人: > > > &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > > "users" > > > &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > > < > > &gt; jbert...@apache.org&amp;gt;; > > &gt; 发送时间:&amp;nbsp;2021年7月5日(星期一) 中午11:22 > > &gt; 收件人:&amp;nbsp;"users"<users@activemq.apache.org > &amp;gt;; > > &gt; > > &gt; 主题:&amp;nbsp;Re: I have a question about levedb > > &gt; > > &gt; > > &gt; > > &gt; Support for LevelDB was revoked in ActiveMQ 5.14.2, although > the store > > &gt; implementation was still present in the code-base. The store > > implementation > > &gt; was removed in 5.17.0. > > &gt; > > &gt; > > &gt; Justin > > &gt; > > &gt; On Sun, Jul 4, 2021 at 9:48 PM ヤ艾枫o.-- > <1169114...@qq.com.invalid > > &amp;gt; > > &gt; wrote: > > &gt; > > &gt; &amp;gt; Hi&amp;amp;nbsp; > > &gt; &amp;gt; > > &gt; &amp;gt; > > &gt; > > > https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/MasterElector.scala#L120 > > > <https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/MasterElector.scala#L120>>; > &gt > > < > https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/MasterElector.scala#L120&gt> > ;; > > &amp;gt > > &gt; < > > > https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/MasterElector.scala#L120&amp;gt&gt > > > <https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/MasterElector.scala#L120&amp;gt&gt>>; > ;; > > &gt; what is means "members"？ > > &gt; &amp;gt; Refers to the number of brokers started in the > current > > cluster, or the > > &gt; &amp;gt; number of brokers registered in the zookeeper > service
