Details
Description
This is how a couchbase cloud target ns_server set up looks like:
"nodes": [
|
{
|
"alternateAddresses": {
|
"external": {
|
"hostname": "cb-0000.ead75783-adbe-42ac-8937-e187da9abf80.dp.cloud.couchbase.com",
|
"ports": {
|
"kv": 11210,
|
"mgmt": 8091
|
}
|
}
|
},
|
"couchApiBase": "http://cb-0000.cb.ead75783-adbe-42ac-8937-e187da9abf80.svc:8092/couchbasecloudbucket%2Bd63abb01677215a93003366564a5a87a",
|
"hostname": "cb-0000.cb.ead75783-adbe-42ac-8937-e187da9abf80.svc:8091",
|
"ports": {
|
"direct": 11210
|
}
|
},
|
{
|
"alternateAddresses": {
|
"external": {
|
"hostname": "cb-0001.ead75783-adbe-42ac-8937-e187da9abf80.dp.cloud.couchbase.com",
|
"ports": {
|
"kv": 11210,
|
"mgmt": 8091
|
}
|
}
|
},
|
From this we can tell that we technically should be using the alternate address, since the traditional "hostname" field is not valid as a remote cluster FQDN.
People can create cloud references directly from local machine using the cloud SRV, and the XDCR working off of the user intent isn't clear.
Because of this, XDCR cannot replicate successfully to the cloud.