Is XDR to multicast conversion possible?


#1

I have an XDR setup across regions. Now, due to some reason, when I deploy my application some where else, I need to convert my setup from XDR to multicast. Can this be achieved? Please guide.


#2

I’m not sure what you mean by

XDR is a service for replicating new writes from one datacenter to another. To do this it uses TCP connections.

Are you wanting XDR to send data using multicast instead of TCP? The answer to this question is no, XDR doesn’t support any transport layer protocol other than TCP.


#3

Hi, I am sorry if I wasn’t clear earlier. What I actually want is to convert my setup which is currently across 2 zones(i.e having 2 clusters) to become a single node cluster as a normal multicast setup is, i.e single node in a single zone. Hope this helps :smile:


#4

Are these Amazon availability zones? If so, there isn’t a simple way use multicast in AWS. As an alternative to our multicast heartbeat protocol, our mesh heartbeat protocol is commonly used where multicast cannot.

Also since the cross AZ latencies can be unpredictable, I would recommend increasing the heartbeat.timeout and/or heartbeat.interval to compensate for not having a tightly coupled cluster. Please read an understand how the interval and timeout work as the parameters will affect how long a portion data may be unavailable after an event that affects the cluster health.


#5

Hi Kevin, thanks for your time to shed some light on the topic. I still think I wasn’t clear about my question :smile:

I am running aerospike XDR across 2 zones and each cluster has only one node each. Now, to replicate the same on my integrated testing environment(everything on a single instance), I do not want to setup XDR; instead I want that the aerospike should be accomodated on the same new development instance (via unicast / mesh) . Please let us know if I can setup aerospike in unicast/mesh mode here with the same data as that of XDR one in production.

Thank You in advance :smile:


#6

Can someone please update. I want to clarify this so that I can proceed with the setup :smile:


#7

So mesh/unicast doesn’t serve the same purpose as XDR and if you want to simulate your production environment I would recommend using XDR to sync the two nodes.

asd --help                                                                                                                                                                100%

Aerospike server installation installs the script /etc/init.d/aerospike which
is normally used to start and stop the server. The script is also found as
as/etc/init-script in the source tree.

asd informative command-line options:

--help
Print this message and exit.

--version
Print edition and build version information and exit.

asd runtime command-line options:

--config-file <file>
Specify the location of the Aerospike server config file. If this option is not
specified, the default location /etc/aerospike/aerospike.conf is used.

--foreground
Specify that Aerospike not be daemonized. This is useful for running Aerospike
in gdb. Alternatively, add 'run-as-daemon false' in the service context of the
Aerospike config file.

--cold-start
(Enterprise edition only.) At startup, force the Aerospike server to read all
records from storage devices to rebuild the index.

--instance <0-15>
(Enterprise edition only.) If running multiple instances of Aerospike on one
machine (not recommended), each instance must be uniquely designated via this
option.

The options you should be interested here are –config-file and instance if you are running enterprise edition.

So if I wanted to start two Aerospike servers on the same instance I would run:

asd --instance 0 --config-file /path/to/aerospike_0.conf
asd --instance 1 --config-file /path/to/aerospike_1.conf

Similarly with XDR:

asxdr --help
asxdr: unrecognized option '--help'
Invalid option
Usage: xdr --resume|--noresume [--config-file <filepath>] [--err <errlog>]

    --resume
         Resume log record shipping
    --noresume
         Do not resume log record shipping
    --nofailover
         Resume but do not do failover of nodes
    --config-file
         xdr config file path
    --err 
        xdr client error log 

--resume or --noresume or --nofailover needs to be passed

You could start XDR this way:

asxdr --resume --config-file /path/to/aerospike_0.conf

The aerospike.conf files need to have different files names define for logging, etc. And they need to be operating on different ports for service, fabric, heartbeat, and info.

Hope this helps.