Date: Thu, 28 Mar 2024 09:40:21 +0000 (UTC) Message-ID: <194898787.323.1711618821140@library.aws.roguewave.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_322_1975545316.1711618821139" ------=_Part_322_1975545316.1711618821139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Zend Server 6.x and later versions
Sometimes there is a reason to "move" the existing cluster to= a different database. The most common reasons are switching to a more perf= ormant MySQL server or separating the application databases from the Zend S= erver Cluster database.
The regular method of moving to a different database is this:=
1. Preparing the new database, for example, cloning it =
to another server.
2. Removing the nodes=
from Zend Server Cluster.
3. Adding the removed nodes to the new Zend Server Cluster <=
/span>with newly created database as backend.
However, this procedure may take significant time, depending = on the cluster's size. Same effect can be achieved with direct "hacking" of= Zend Server's configuration files. Although this procedure is not somethin= g we usually recommend, it works correctly and can be considered for implem= entation, if migration down time must be reduced to the absolute minimum.= p>
Here it is:
1. Prepare the new database, for example, by cloning it to an= other server.
Then, on each node do the following:
2. Stop Zend Server (sudo /usr/local/zend/bin/zendctl.s=
h stop
).
3. Modify the file /usr/local/zend/etc/= zend_database.ini to reflect the new database connec= tion information.
4. Modify the file /usr/local/zend/etc/= zsd.ini. The parameter "zend_server_daemon.cluster_node_id" must have = the same values as in the previous file (marked red in the example):
zend_server_daemon.cluster_node_id=3D1@server.=
mysql.intra.net@newDB@1435341786.381
Legend:
field 1 - Node ID - <=
strong>do not change
field =
2 - MySQL server's hostname or IP address
field 3 - Ne=
w database name
field 4 - Timestamp - changing not rec=
ommended
5. Start Zend Server (sudo /usr/local/zend/bin/zendctl.=
sh start
).
Obviously, the clone of the original database will not receiv= e the updates that have been done to the original database during the migra= tion. This may be especially important for clusters actively using Zend Job= Queue. In this case a small change to the order of actions is needed (this= also applies to the regular procedure):
1. Stop Zend Server on ALL the nodes (or remove all the=
nodes from Zend Server Cluster).
2. Prepare/clone the database.
3. Change the configuration files and start Zend Server on each node =
(or add all the nodes to Zend Server Cluster).