Transferring the platform to a new server

Step 1. Install the necessary components for the platform to work on the new server in accordance with the instructions: Manual installation

Step 2. Switch RabbitMQ by correcting the connection string in main.json to the new host.

Step 3. Make a backup according to the instructions:

For a full backup, the following data is required:

• AKD control module;
• MongoDB databases (account and control can be separated or combined into one database);
• бSSDB databases (actions, hardbounces, nofitications and stats).

note

All of the backup methods create an archive in a user's current directory. Before executing the command, you must make sure that there is enough free space in the current directory to save the archive.

Control module

Backup​

The recommended way to create a backup is to place the directory with the control module in an archive, excluding logs, sockets and PID files:

tar -czvf akd-backup.tar.gz /opt/akd --exclude=*.log --exclude=*.sock --exclude=*.pid

Recovery

Unpack the archive and move its contents:

tar -xzvf akd-backup.tar.gz
mkdir -p /opt/akd
cp -R akd/* /opt/akd/

note

To restore the control module from a backup copy on a new server, you must first configure the environment necessary for the module to operate (see the page [Preparation, database configuration, launching the platform])(/admin-guide/platform-installation/9406483).

MongoDB

All backup methods are described in more detail in the official documentation::

https://docs.mongodb.com/manual/core/backups

tip

We recommend backing up using snapshots ([Back Up and Restore with Filesystem Snapshots]) (https://docs.mongodb.com/manual/tutorial/backup-with-filesystem-snapshots/#back-up-and-restore-with-filesystem-snapshots). МThe method using snapshots allows you to save a lot of time when restoring large collections with a large number of indexes.

Backup​

For small instances, you can use the utilitymongodump https://docs.mongodb.com/database-tools/mongodump:

mongodump --host 127.0.0.1 --port 27017 --gzip --archive=mongodb-backup.tar.gz

Recovery

Restore a backup using the utility mongorestore (https://docs.mongodb.com/database-tools/mongorestore):

mongorestore --host 127.0.0.1 --port 27017 --gzip --archive=mongodb-backup.tar.gz

ClickHouse

Backup methods are described in the official documentation:

https://clickhouse.com/docs/ru/operations/backup/

Using the utility as an example clickhouse-backup

Minimum configuration file

clickhouse:
  username: default
  password: "abcdefghijklmnopqrstuvwxyzABCDEF"
  host: localhost
  port: 9000
data_path: "/var/lib/clickhouse"
general:
  remote_storage: none
  backups_to_keep_local: 7
  backups_to_keep_remote: 31

Backup

clickhouse-backup create $BACKUP_NAME >> /var/log/clickhouse-backup.log

Recovery

clickhouse-backup restore $BACKUP_NAME >> /var/log/clickhouse-restore.log

SSDB

All backup methods are described in more detail in the official documentation:

https://ideawu.github.io/ssdb-docs/backup.html

tip

We recommend backing up using snapshots and then moving all data from the snapshot to an archive. Importing and exporting keys in large SSDB databases can take up to several days.

Backup

For small instances you can use utility ssdb-dump (см. https://ideawu.github.io/ssdb-docs/backup.html):

/usr/local/ssdb/tools/ssdb-dump -h 127.0.0.1 -p 4420 -a abcdefghijklmnopqrstuvwxyzABCDEF ./ssdb-hardbounces-dump
/usr/local/ssdb/tools/ssdb-dump -h 127.0.0.1 -p 4430 -a abcdefghijklmnopqrstuvwxyzABCDEF ./ssdb-notifications-dump

Recovery

Clear data from previous instances and move backup contents:

rm -rf /var/lib/ssdb/hardbounces
mv ssdb-hardbounces-dump /var/lib/ssdb/hardbounces

rm -rf /var/lib/ssdb/notifications
mv ssdb-notifications-dump /var/lib/ssdb/notifications

Step 4. Check that the platform is working correctly.

• Check that processes are running:

AK:api
AK:proctask
AK:procrpc
AK:procactions
AK:procresume
AK:procsenderev
AK:procsmsev
AK:proctrigger
AK:procworkflow
AK:prochook
AK:procnotify
AK:procpixel
AK:procwebver
AK:proctrkweb
AK:procpush
AK:procpiper
AK:stataggregator
AK:tariffcontroller
AK:webcontrol
AK:procleadsaver
AK:procevent
AK:proceventgen
AK:procintegras
AK:procplmt
AK:trkaction
AK:trkimage
AK:trkread
AK:trksms
AK:trkwebctrl
AK:trkpush
AK:cookie_saver
AK:trkcustom
AK:trklisten
AK:procsmslisten
AK:trk_amazon_sns
AK:health
AK:webadmin

• Check the logs of these processes for errors:

note

Default path: /opt/akd/logs

Step 5. Start tracking on the new host manually:

/opt/akd/ak/bin/proctrkweb --config /opt/akd/config/main.json
/opt/akd/ak/bin/trkaction --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trkimage --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trkread --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trksms --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trkwebctrl --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trkpush --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trkcustom --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trklisten --rpcAddrs <old_host_ip>:8972
/opt/akd/ak/bin/trk_amazon_sns --rpcAddrs <old_host_ip>:8972

Step 6. Stop the platform on the current host:

/opt/akd/akd stop

Step 7. Launch the platform on the new host.

note

restart used to ensure that tracking switches to the current host.

/opt/akd/akd restart