Is it possible to script clustering a fresh pair of running CQ author instances without having to stop and start them in the process? | Community
Skip to main content
LinearGradient
Level 6
October 16, 2015
Solved

Is it possible to script clustering a fresh pair of running CQ author instances without having to stop and start them in the process?

  • October 16, 2015
  • 3 replies
  • 773 views

Hi,

According to CRX Clustering, for Manual Slave Join, in order to create a cluster of CQ instances manually, the following steps should be taken:

  • Copy the files crx-quickstart-*.jar and and license.properties to the desired directory.
  • Start the instance: java -Xmx512m -jar *.jar
  • Verify that the instance is up and running, then stop the instance.
  • In the file crx-quickstart/repositorycluster.properties, add the IP address of the slave instance you are adding below (if that slave is on a different machine, otherwise this step is not needed).
  • Stop the instance.
  • If a shared data store is to be be used: 
    • Change crx-quickstart/repository/repository.xml, as described in Shared Data Store and Data Store, above.
    • Assuming you have configured <shared>/datastore/ as the shared location, copy the contents of the crx-quickstart/repository/repository/datastore to the directory <shared>/datastore.
  • Start the instance, and verify that it still works.

For Manual Slave Cloning, similarly the master instance has to be stopped and started during clustering.

Is there a way to avoid the stop/start steps when we have two fresh and running CQ instances that are installed on two different hosts. When in an AWS EC2 environment, the repository is stored on EBS volumes, stopping and starting an instance can take a considerable amount of time, and I am looking for a way to avoid it.

Thanks in advance.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Sham_HC
        If you are using existing repository manual clone make sense & can avoid restart using online backup. For fresh instance why gui joining not meeting your case

3 replies

Sham_HC
Sham_HCAccepted solution
Level 10
October 16, 2015
        If you are using existing repository manual clone make sense & can avoid restart using online backup. For fresh instance why gui joining not meeting your case
LinearGradient
Level 6
October 16, 2015

Sham HC wrote...

If you are using existing repository manual clone make sense & can avoid restart using online backup. For fresh instance why gui joining not meeting your case

 

DevOps! As you know, lots of time and money can be saved by automating deployment and provisioning using tools like Puppet, Chef, Ansible, etc.

Right now we have a bunch of Ansible playbooks (aka scipts) that setup a CQ cluster. However at the moment, when creating a new stack, by following the docs, the scripts stop/start the instances. I am looking for a way to avoid that.

Thanks.

Sham_HC
Level 10
October 16, 2015

LinearGradient wrote...

Sham HC wrote...

If you are using existing repository manual clone make sense & can avoid restart using online backup. For fresh instance why gui joining not meeting your case

 

DevOps! As you know, lots of time and money can be saved by automating deployment and provisioning using tools like Puppet, Chef, Ansible, etc.

Right now we have a bunch of Ansible playbooks (aka scipts) that setup a CQ cluster. However at the moment, when creating a new stack, by following the docs, the scripts stop/start the instances. I am looking for a way to avoid that.

Thanks.

 

http://www.slideshare.net/francoisledroff/master-chef-class-learn-how-to-quickly-cook-delightful-cqaem-infrastructures