Fusion Server Deployment

​

Ports

​

Unix installation

1. Verify that the node on which you plan to install Fusion meets hardware and software requirements.
2. Download the Fusion tar/zip file for the latest version of Fusion and move it to where you would like it to reside in your filesystem (if you would like to use Upstart for process management, you must install Fusion in /opt/lucidworks).
3. Become the user that will run Fusion.
   Do not run Fusion as the root user.
4. Change your working directory to the directory in which you placed the fusion-version.x.tar.gz file, for example: $ cd /opt/lucidworks
   Failures in the Fusion install or startup may occur if the Fusion installation directory name contains a space.
5. Unpack the archive with tar -xf (or tar -xvf), for example: $ tar -xf fusion-version.x.tar.gz The resulting directory is named https://FUSION_HOST:FUSION_PORT. You can rename this if you wish. This directory is considered your Fusion home directory. See Directories, Files, and Ports for the contents of the https://FUSION_HOST:FUSION_PORT directory.

​

Starting Fusion

​

Running Fusion In The Foreground

​

Stopping Fusion

​

Using systemd to manage processes

​

Using Ubuntu Upstart to manage processes

​

Windows installation

1. Verify that the node on which you plan to install Fusion meets hardware and software requirements.
2. Download the zip file for the latest version of Fusion and move it to where you would like Fusion to reside in your filesystem. It will appear as a compressed folder.
3. Unpack the archive. In most cases, you need only right-click and choose “Extract all…”. If you do not see this option, check that you have permissions to extract folders on your system.
   The resulting directory is named fusion\latest.x. This directory is considered your Fusion home directory. See Directories, Files, and Ports for the contents of the fusion\latest.x directory.

1. Run bin\install-services.cmd.
2. Enter the name of the windows user that is used to launch this service.
   Remember the username is COMPUTERNAME\username or DOMAIN\username (if your computer is part of a Windows domain).
3. Enter the user’s password.
4. Enter the path to the directory containing the JDK to use for running the services.

​

Starting Fusion

fusion.cmd start

start-services.cmd

​

Stopping Fusion

​

Installation with an existing Solr instance or cluster

​

Troubleshooting

​

Install Fusion Server with Bundled Solr and ZooKeeper

​

Supported Cluster Arrangements

​

Hardware and software requirements

​

Next steps

• Install a Fusion Cluster (Unix)
• Install a Fusion Cluster (Windows)

​

Preliminary steps

1. Prepare your firewall so that the Fusion nodes can communicate with each other. The default ports list contains a list of all ports used by Fusion. From this list, it is important that the ZooKeeper ports, Apache Ignite ports, and the Spark ports (if you are using Spark) are open between the different nodes for cross-cluster communication.
2. Fusion for Unix is distributed as a compressed archive file (.tar.gz). Move this file to each node that will run Fusion.
   To leverage the copies of Solr and/or ZooKeeper that are distributed with Fusion on nodes that will not run Fusion (as a simple means of obtaining compatible versions of the other software), also download the Fusion compressed archive file to each of those nodes. Below, you will edit configuration files so that Fusion does not run on those nodes.
3. On each node, change your working directory to the directory in which you placed the Fusion tar/zip file and unpack the archive, for example:
   Copy

   $ cd /opt/lucidworks
   $ tar -xf fusion-version.x.tar.gz
   

   Failures in the Fusion install or startup may occur if the Fusion installation directory name contains a space.
   The resulting directory is named https://FUSION_HOST:FUSION_PORT. You can rename this if you wish. This directory is considered your Fusion home directory. See Directories, files, and ports for the contents of the https://FUSION_HOST:FUSION_PORT directory.

​

Nodes running core Fusion services and Solr also run ZooKeeper

1. Assign a number to each Fusion node, starting at 1. We refer to the number we assign to each node as the ZooKeeper myid.
2. On each Fusion node, create a https://FUSION_HOST:FUSION_PORT/data/zookeeper directory, and a file called myid in that directory. Edit the file and save the ZooKeeper myid assigned for this node as the only contents.
3. On each Fusion node, open the https://FUSION_HOST:FUSION_PORT/conf/zookeeper/zoo.cfg file in a text editor and add the following after the clientPort line (change the hostnames or IP addresses to the correct ones for your servers):
   Copy

   server.1=[Hostname or IP for ZooKeeper with myid 1]:2888:3888
   server.2=[Hostname or IP for ZooKeeper with myid 2]:2888:3888
   server.3=[Hostname or IP for ZooKeeper with myid 3]:2888:3888
   

   For example:
   Copy

   server.1=10.10.31.130:2888:3888
   server.2=10.10.31.178:2888:3888
   server.3=10.10.31.166:2888:3888
   

   Do not use localhost or 127.0.0.1 as the hostname/IP. Specify the hostname/IP that other nodes will use when communicating with the current node.
4. On each Fusion node, edit default.zk.connect in https://FUSION_HOST:FUSION_PORT/conf/fusion.cors (fusion.properties in Fusion 4.x) to point to the ZooKeeper hosts:
   Copy

   default.zk.connect=[ZK host 1]:9983,[ZK host 2]:9983,[ZK host 3]:9983
   

5. On each node, start ZooKeeper with bin/zookeeper start. Zookeeper should start without errors. If a ZooKeeper instance fails to start, check the log at https://FUSION_HOST:FUSION_PORT/var/log/zookeeper/zookeeper.log.
6. On each node, start the rest of Fusion using bin/fusion start.
7. Create an admin password and log in to Fusion at http://FIRST_NODE_IP:8764, where FIRST_NODE_IP is the IP address of your first Fusion node.
8. Verify the Solr cluster is healthy by looking at http://ANY_NODE_IP:8983/solr/#/~cloud, where ANY_NODE_IP is the IP address of a Solr node. All of the nodes should appear green.
9. If necessary, prepare high availability by setting up a load balancer in front of Fusion so that it load balances between the Fusion UI URL’s at http://NODE_IP:8764.
   Consult your load balancer’s documentation for instructions.

​

Nodes running ZooKeeper are not running core Fusion services or Solr

1. Assign a number to each Fusion node, starting at 1. We refer to the number we assign to each node as the ZooKeeper myid.
2. On each Fusion node, create a fusion\latest.x\data\zookeeper directory, and a file called myid in that directory. Edit the file and save the ZooKeeper myid assigned for this node as the only contents.
3. On each Fusion node, open the fusion\latest.x\conf\zookeeper\zoo.cfg file in a text editor and add the following after the clientPort line (change the hostnames or IP addresses to the correct ones for your servers):
   Copy

   server.1=[Hostname or IP for ZooKeeper with myid 1]:2888:3888
   server.2=[Hostname or IP for ZooKeeper with myid 2]:2888:3888
   server.3=[Hostname or IP for ZooKeeper with myid 3]:2888:3888
   

   For example:
   Copy

   server.1=10.10.31.130:2888:3888
   server.2=10.10.31.178:2888:3888
   server.3=10.10.31.166:2888:3888
   

4. Edit conf/fusion.cors (fusion.properties in Fusion 4.x) and remove zookeeper from the group.default list. This will make it so that ZooKeeper does not start when you start Fusion.
5. On each Fusion node, edit default.zk.connect in https://FUSION_HOST:FUSION_PORT/conf/fusion.cors (fusion.properties in Fusion 4.x) to point to the ZooKeeper hosts:
   Copy

   default.zk.connect=[ZK host 1]:2181,[ZK host 2]:2181,[ZK host 3]:2181
   

6. On each node, start ZooKeeper with bin/zookeeper start. Zookeeper should start without errors. If a ZooKeeper instance fails to start, check the log at https://FUSION_HOST:FUSION_PORT/var/log/zookeeper/zookeeper.log.
7. On each node, start the rest of Fusion using bin/fusion start.
8. Create an admin password and log in to Fusion at http://FIRST_NODE_IP:8764, where FIRST_NODE_IP is the IP address of your first Fusion node.
9. Verify the Solr cluster is healthy by looking at http://ANY_NODE_IP:8983/solr/#/~cloud, where ANY_NODE_IP is the IP address of a Solr node. All of the nodes should appear green.
10. If necessary, prepare high availability by setting up a load balancer in front of Fusion so that it load balances between the Fusion UI URL’s at http://NODE_IP:8764. Consult your load balancer’s documentation for instructions.

​

Known issues

​

Metrics collection failure

• To attach a debugger
• By the agent to connect to the service that collects Java Management Extension (JMX) metrics

• Sends a -QUIT message to the JVM
• Triggers a thread dump to be printed to standard out

• Is logged to the agent log
• Generates the “No metrics can be gathered” exception
• Prints a complete thread dump
• Sends the thread dump to system logs

• Exclude the agent.log from the logstash configuration. The logshipping is turned off for the file. The disadvantage to this option is that the metrics are missing.
• Change the cron job in the Linux distribution that deletes the /tmp files older than “x” days to exclude deleting the /tmp/.java_pid<pid> files. If your system is running the Linux Systemd software suite on EC2, the setting is typically located in the usr/lib/tmpfiles.d/tmp.conf file. For Dial On Demand (DOD), remove the call that configures the JMX Metrics requirement for the debugger attachment to the Java service.

​

Preliminary steps

1. Prepare your firewall so that the Fusion nodes can communicate with each other. The default ports list contains a list of all ports used by Fusion. From this list, it is important that the ZooKeeper ports, Apache Ignite ports, and the Spark ports (if you are using Spark) are open between the different nodes for cross-cluster communication.
2. Fusion for Windows is distributed as a compressed archive file (.zip). Download the Fusion zip file for the latest version of Fusion to each node that will run Fusion, and move the file to where you would like Fusion to reside in your filesystem. It will appear as a compressed folder.
   To leverage the copies of Solr and/or ZooKeeper that are distributed with Fusion on nodes that will not run Fusion (as a simple means of obtaining compatible versions of the other software), also download the Fusion zip file to each of those nodes. Below, you will edit configuration files so that Fusion does not run on those nodes.
3. Unpack the archive. In most cases, you need only right-click and choose “Extract all…”. If you do not see this option, check that you have permissions to extract folders on your system.
   The resulting directory is named fusion\latest.x. This directory is considered your Fusion home directory. You can rename it if you wish. See Directories, Files, and Ports for the contents of the Fusion home directory.

​

Nodes running core Fusion services and Solr also run ZooKeeper

1. Assign a number to each Fusion node, starting at 1. We refer to the number we assign to each node as the ZooKeeper myid.
2. On each Fusion node, create a fusion\latest.x\data\zookeeper directory, and a file called myid in that directory. Edit the file and save the ZooKeeper myid assigned for this node as the only contents.
3. On each Fusion node, open the fusion\latest.x\conf\zookeeper\zoo.cfg file in a text editor and add the following after the clientPort line (change the hostnames or IP addresses to the correct ones for your servers):
   Copy

   server.1=[Hostname or IP for ZooKeeper with myid 1]:2888:3888
   server.2=[Hostname or IP for ZooKeeper with myid 2]:2888:3888
   server.3=[Hostname or IP for ZooKeeper with myid 3]:2888:3888
   

   For example:
   Copy

   server.1=10.10.31.130:2888:3888
   server.2=10.10.31.178:2888:3888
   server.3=10.10.31.166:2888:3888
   

default.zk.connect=[ZK host 1]:9983,[ZK host 2]:9983,[ZK host 3]:9983

5. On each node, start ZooKeeper with bin\zookeeper start. Zookeeper should start without errors. If a ZooKeeper instance fails to start, check the log at fusion\latest.x\var\log\zookeeper\zookeeper.log.
6. On each node, start the rest of Fusion using bin\fusion start.
7. Create an admin password and log in to Fusion at http://FIRST_NODE_IP:8764, where FIRST_NODE_IP is the IP address of your first Fusion node.
8. Verify the Solr cluster is healthy by looking at http://ANY_NODE_IP:8983/solr/#/~cloud, where ANY_NODE_IP is the IP address of a Solr node. All of the nodes should appear green.
9. If necessary, prepare high availability by setting up a load balancer in front of Fusion so that it load balances between the Fusion UI URL’s at http://NODE_IP:8764.
   Consult your load balancer’s documentation for instructions.

​

Nodes running ZooKeeper are not running core Fusion services or Solr

1. Assign a number to each Fusion node, starting at 1. We refer to the number we assign to each node as the ZooKeeper myid.
2. On each Fusion node, create a fusion\latest.x\data\zookeeper directory, and a file called myid in that directory. Edit the file and save the ZooKeeper myid assigned for this node as the only contents.
3. On each Fusion node, open the fusion\latest.x\conf\zookeeper\zoo.cfg file in a text editor and add the following after the clientPort line (change the hostnames or IP addresses to the correct ones for your servers):
   Copy

   server.1=[Hostname or IP for ZooKeeper with myid 1]:2888:3888
   server.2=[Hostname or IP for ZooKeeper with myid 2]:2888:3888
   server.3=[Hostname or IP for ZooKeeper with myid 3]:2888:3888
   

   For example:
   Copy

   server.1=10.10.31.130:2888:3888
   server.2=10.10.31.178:2888:3888
   server.3=10.10.31.166:2888:3888
   

4. Edit conf\fusion.cors (fusion.properties in Fusion 4.x) and remove zookeeper from the group.default list. This will make it so that ZooKeeper does not start when you start Fusion.
5. On each Fusion node, edit default.zk.connect in fusion\latest.x\conf\fusion.cors (fusion.properties in Fusion 4.x) to point to the ZooKeeper hosts:
   Copy

   default.zk.connect=[ZK host 1]:2181,[ZK host 2]:2181,[ZK host 3]:2181
   

6. On each node, start ZooKeeper with bin\zookeeper start. Zookeeper should start without errors. If a ZooKeeper instance fails to start, check the log at fusion\latest.x\var\log\zookeeper\zookeeper.log.
7. On each node, start the rest of Fusion using bin\fusion start.
8. Create an admin password and log in to Fusion at http://FIRST_NODE_IP:8764, where FIRST_NODE_IP is the IP address of your first Fusion node.
9. Verify the Solr cluster is healthy by looking at http://ANY_NODE_IP:8983/solr/#/~cloud, where ANY_NODE_IP is the IP address of a Solr node. All of the nodes should appear green.
10. If necessary, prepare high availability by setting up a load balancer in front of Fusion so that it load balances between the Fusion UI URL’s at http://NODE_IP:8764. Consult your load balancer’s documentation for instructions.

• If your existing Solr instance is running in SolrCloud mode, you can use Fusion’s UI to modify configuration files (such as schema.xml or solrconfig.xml) and create Solr collections.
• If your existing Solr instance is running in standalone mode, you can still connect it to Fusion. Fusion can send documents to a standalone Solr instance and query the instance. But you will not be able to use Fusion’s UI to create Solr collections (Solr cores) or to modify Solr configuration files.

​

Prerequisites

• You have already installed Fusion.
• You have already installed Solr, which must meet these Solr requirements.
• You have already installed ZooKeeper, which must meet these ZooKeeper requirements.
  We recommend that you create an external ZooKeeper cluster (external to both Fusion and SolrCloud).
• Your Solr deployment must contain one or more collections (cores).
• In SolrCloud mode, Solr must be configured to use ZooKeeper.

​

Configure Fusion to use an existing Solr deployment

​

Use the Fusion UI

1. Create a Fusion search cluster:
   1. In the Fusion UI, navigate to System > Solr Clusters and click New Solr Cluster.
   2. Enter this information:
   • A cluster ID of your choice
   • Whether SolrCloud is enabled
   • The connect string (to tell Fusion how to connect to the SolrCloud cluster or Solr instance)
     • For SolrCloud, this is the ZooKeeper connect string.
     • For a standalone Solr instance, this is the URL of the Solr instance.
   3. Verify that the connection is working by clicking Cores in the new cluster and inspecting the contents.
2. Create a Fusion collection that points to your Solr cluster and collection:
   1. In the UI, navigate to Collections and click Add a Collection.
   2. Enter a name for the new collection.
   3. Click Advanced.
   4. Select your SolrCloud cluster or Solr instance from the dropdown.
   5. Enter the name of the Solr collection to import.

​

Sending Documents to Solr through Fusion

1. Follow the steps above to create and configure a search cluster and a collection that points to Solr.
2. Define an index pipeline that ends with a Solr Indexer stage that sends the documents to Solr.
3. Use one of these methods to ingest your data:
   • In the collection that points to your Solr collection, define a datasource using the connector of choice.
   • Send prepared documents directly to the index pipeline for processing. See Importing Data with the REST API.
   • It is also possible to use a different indexing process besides a connector, such as a script that sends documents through the index pipeline.

​

Querying Solr via Fusion requests

​

Fusion run script failures

• Wrong Java version.
• Spaces in Windows install path.
• Users have insufficient privileges for the installation directory.
• Java bin directory not in the PATH environment variable.
• Some Fusion services may already be running, or registered as running.
• Roaming IP address; try uncommenting this line in https://FUSION_HOST:FUSION_PORT/conf/fusion.cors (fusion.properties in Fusion 4.x):

  default.address = 127.0.0.1

​

Check the Java version

echo $JAVA_HOME

echo %JAVA_HOME%

java -version
javac -version

​

Clear browser cache

​

Stop/Clean up/Start

$ cd {path_to}https://FUSION_HOST:FUSION_PORT
$ ./bin/fusion stop
Successfully stopped ui (process ID 41524)
Successfully stopped connectors (process ID 41328)
Successfully stopped api (process ID 41159)
Successfully stopped solr (process ID 41153)
Successfully stopped zookeeper (process ID 41151)

>  find {path_to}https://FUSION_HOST:FUSION_PORT/var -name "*.pid" -print

fusion/var/api/api.pid
fusion/var/connectors/connectors.pid
fusion/var/solr/solr.pid
fusion/var/spark-master/spark-master.pid
fusion/var/spark-worker/spark-worker.pid
fusion/var/ui/ui.pid
fusion/var/zookeeper/zookeeper.pid

​

Inspect the log files

​

Troubleshoot a Windows Install

• Is the account trying run the install script a poweruser/administrator of the server?
• Is the DOMAIN\USERNAME correctly specified? Is the Domain correct?
• Is java installed on the %PATH%? To use a different Java, specify it in bin/windows-service-wrapper.xml.
• Are there any obvious issues in var/log/windows-service-wrapper.log ?
• Does Fusion start from the normal bin\fusion start?
• Are there any other errors in the normal logs?

​

Increase memory

connectors-classic.jvmOptions = -Xmx1g -Xss256k -Dcom.lucidworks.connectors.pipelines.embedded=false

​

More Help and Support

• Lucidworks Fusion Knowledge Base
• Contact Lucidworks

​

Key points

• Migration involves down time. The upgrade process involves multiple starts and stops of Fusion services. Please plan accordingly, especially in terms of disabling external load balancers or monitors that might react adversely to the starts and stops.
• Current deployment is preserved. Upgrades preserve the current Fusion deployment, copying information over from the current deployment to the new one. This provides a rapid roll-back option if you encounter problems during the upgrade process.
• If the upgrade fails. If an upgrade fails, there is a procedure for dealing with that.

​

Supported upgrade sequences

​

Upgrades to the current version

• 3.1.x to 4.2.y. From any 3.1.x version to 4.2.6 SP1 (one step, using the migrator)
• 4.0.x to 4.2.y. From any 4.0.x version to 4.2.6 SP1 (one step, using the migrator)
• 4.1.x to 4.2.y. From any 4.1.x version to 4.2.6 SP1 (one step, using the migrator)

​

Upgrades to prior versions

• 3.1.x to 4.0.y. From 3.1.5 directly to 4.0.2 (one step) For more information, see Upgrade Fusion 3.1.x to 4.0.y.
• 4.0.x to 4.0.y. From 4.0.0 or 4.0.1 to 4.0.2 (one step) For more information, see Upgrade Fusion Server 4.0.x to 4.0.y.
• 3.1.x to 4.1.y. From any 3.1.x version to 4.1.3 (one step, using the migrator) For more information, see Upgrade Fusion Server 3.1.x to 4.1.y.
• 4.0.x to 4.1.y. From 4.0.2 to 4.1.3 (one step, using the migrator) For more information, see Upgrade Fusion Server 4.0.x to 4.1.y.
• 4.1.x to 4.1.y. From 4.1.0 to 4.1.3 (one step, using the migrator) For more information, see Upgrade Fusion Server 4.1.x to 4.1.y.

​

Example

1. Upgrade from Fusion 3.0.1 to Fusion 3.1.5
2. Upgrade from Fusion 3.1.5 to Fusion Server 4.2.5

​

Per-version instruction sets

• When migrating data from development environments into testing and production environments
• To back up data, so you can restore it after an incident of data loss
• When the migrator script was not able to migrate an object automatically

​

Migration approaches

​

Export an app with the Fusion UI

1. Navigate to the launcher.
2. Hover over the app you want to export and click the Configure icon:
3. In the app config window, click Export app to zip: See import for information to import the downloaded zip file into other instances of Fusion 4.x Server.

​

Import an app with the Fusion UI

1. Navigate to the launcher.
2. Click Import app.
3. Under Data File, click Choose File and select the zip file containing the app you want to import.
4. If your app has usernames and passwords in a separate file, select it under Variables File.
   If the Variables File is needed, it must be a separate file that is not in a .zip file. It is a .json map of variables to values. The following is an example:

{
 "secret.dataSources.Inventory_BR_S3_DS.password":"SOMETHING",
 "secret.dataSources.LLM_A_BR_S3_DS.password":"FmJSaDE9Tj5REDACTED",
 "secret.dataSources.LLM_BR_Inventory_S3_DS.password":"FmJSaDE9Tj5GzIVvethAC4Huh",
 "secret.dataSources.LLM_BR_Load_S3_DS.password":"FmJSaDE9Tj5GzIVvethAC4"
}

1. In Fusion 4.1 and later, you can sometimes edit parameter values to use the new values in the imported app. If this is the case, Fusion displays a dialog box that lets you edit the parameter values. Make desired changes, and then click Import.

​

Copy an app

​

Import objects into an app

1. In the Fusion launcher, click the app into which you want to import objects.
   The Fusion workspace appears.
2. In the upper left, click System > Import Fusion Objects. The Import Fusion Objects window opens.
3. Select the data file from your local filesystem.
   If you are importing usernames and passwords in a separate file, select it under Variables File.
4. Click Import.
   If there are conflicts, Fusion prompts you to specify an import policy:
   • Click Overwrite to overwrite the objects on the target system with the ones in the import file.
   • Click Merge to skip all conflicting objects and import only the non-conflicting objects.
   • Click Start Over to abort the import.
     Fusion confirms that the import was successful:
   
5. Click Close to close the Import Fusion Objects window.

​

Add an object to an app

• Add an object to an app – While in the Fusion workspace for the app to which you want to add an object, open Object Explorer and click In Any App. Search for or browse to the object you want to add. Hover over the object, click the App icon, and then click Add to this app.
• Add an object to an app directly – In cases when an object is linked to an app, but is not linked directly to the app (it is linked via some dependency), you can add the object to an app directly. While in the Fusion workspace for the app to which you want to add an object directly, open Object Explorer and click In Any App. Search for or browse to the object you want to add. Hover over the object, click the App icon, and then click Add to this app directly.

​

Adding a new Fusion node to an existing cluster

1. Stop Fusion on all nodes in the cluster. This ensures that there is no data inconsistency between the instances when the new node comes up.
2. Decompress the new copy of Fusion and place it in the desired directory.
3. Configure the fusion.cors (fusion.properties in Fusion 4.x) file to match your requirements. If you will also run the embedded ZooKeeper, add the new node’s IP/hostname and port to the default.zk.connect string and copy this change to all other instances in your cluster. Configure the memory and other JVM options for the Fusion modules, then save the file.
4. If embedded ZooKeepers are used in your cluster and you intend to start ZooKeeper on this node, then follow the additional steps below. If not, then you are ready to start all nodes in the cluster.
   1. Copy the $FUSION_HOME/conf/zookeeper/zoo.cfg file from one of the existing nodes to the new node, overwriting the default file.
   2. Add the entry for the new ZooKeeper to the server list in the zoo.cfg file.
      The entry format is server.x=IP:port:port. For example, if this is the 5th node, then the new entry in zoo.cfg is server.5=IP:port:port.
   3. Create a zookeeper folder under $FUSION_HOME/data.
   4. Create a new myid file in $FUSION_HOME/data/zookeeper.
      The contents of this file must be an integer equal to the number of the new ZooKeeper node in the ensemble. For example, if the new node will be the 5th node in your ZooKeeper ensemble, then the myid file should contain the value “5”.
   5. Copy the $FUSION_HOME/data/zookeeper/version-2 directory from one of the existing nodes to the new node, overwriting the default directory.
   6. Modify the connect string for the default search cluster:
      1. Start ZooKeeper on all nodes. Next, you will need the zkcli script, located in $FUSION_HOME/apps/solr-dist/server/scripts/cloud-scripts. Use zkcli.sh for Unix or zkcli.bat for Windows. The examples below use the Unix script.
      2. Download the default search cluster file:
         Copy

         ./zkcli.sh -z <zk1>:<port1>,<zk2>:<port2>,... -cmd getfile <path_to_default_cluster> <path_to_dump_file>.json
         

         The path will differ depending on your Fusion version:
         • 2.4.x: /lucid/search-clusters/default
         • 3.x: /lwfusion/<fusion_version>/core/search-clusters/default
         For example:
         Copy

         ./zkcli.sh -z localhost:9983 -cmd getfile /lwfusion/3.1.2/core/search-clusters/default default_search_cluster.json
         

      3. In the downloaded JSON file, find the connectString key and replace the old IP value with the IP of the new Fusion node.
         Be sure to specify the chroot if your cluster is configured to use it.
         For example:
         Copy

         {
           "id" : "default",
           "connectString" : "localhost:9983/lwfusion/3.1.2/solr",
           "zkClientTimeout" : 30000,
           "zkConnectTimeout" : 60000,
           "cloud" : true,
           "bufferFlushInterval" : 1000,
           "bufferSize" : 100,
           "concurrency" : 10,
           "authConfig" : {
         	"authType" : "none"
           },
           "validateCluster" : true
         }
         

      4. Upload the modified search cluster file:
         Copy

         ./zkcli.sh -z <zk1>:<port1>,<zk2>:<port2>,... -cmd putfile <path_to_default_cluster> <path_to_dump_file>.json
         

         For example:
         Copy

         ./zkcli.sh -z localhost:9983 -cmd putfile /lwfusion/3.1.2/core/search-clusters/default default_search_cluster.json
         

5. Start Fusion on all nodes in the cluster.

​

Adding an indexing node to a Fusion cluster

1. Install the Fusion package on the new node.
2. Edit fusion.cors (fusion.properties in Fusion 4.x) as follows:
   1. Edit group.default to include only the Solr service.
      For example, change
      Copy

      group.default = zookeeper, solr, api, connectors-rpc, connectors-classic, admin-ui, proxy, webapps
      

      to
      Copy

      group.default = solr
      

   2. Uncomment default.zk.connect and point it to the cluster’s ZooKeeper instances.
      For example, change
      Copy

      # default.zk.connect = localhost:9983
      

      to
      Copy

      default.zk.connect = 172.23.1.1:9983,172.23.1.2:9983,172.23.1.3:9983/solr
      

   3. Save the file.
3. Start Fusion on the new node:
   Copy

   bin/fusion start
   

   At this point, the new node is added to the cluster. No indexing takes place on the new node yet.
4. Allocate one or more collection replicas to this node:
   1. Open the Solr UI at http://<new-node-hostname>:8983/solr/.
   2. Click Collections
   3. Select a collection to replicate on the new indexing node.
   4. Click Shard: shard1 (or another shard if you have more than one for this collection).
   5. Click add replica.
   6. From the Node drop-down list, select the new node.
   7. Click Create Replica.
      To verify that the collection is being replicated, you can click Cloud and view the replicas.

​

Moving Fusion from one node to another

1. Stop Fusion on all nodes in the cluster. This ensures that there is no data inconsistency between the instances when the new node comes up.
2. Compress the Fusion node you wish to move.
3. Copy the compressed file to the destination.
4. Starting with step 2, follow the instructions above for adding a new node.