I can use XDCR from docker Couchbase to on-premise Couchbase.
But XDCR on-premise Couchbase to docker Couchbase gets the error:
“Execution timed out”
hi morgan, are you able to ping the docker from on-prem? If you could share logs, that would be very helpful.
yes i can ping the docker from on-prem.
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
i can also get to the ip:8091 from on-prem to docker
What logs would you like?
thanks
here is a log of replication
Replication from bucket “testing” to bucket “testing” on cluster “desktopCB” created.
Compression pre-requisite to cluster 0x80f0d0 check failed. Compression will be temporarily disabled for replication.
Good to know that the ping works. Could you share the UI logs and screenshot when you see the “Execution timed out” error please?
what version of couchbase are you using please?
CB Server 5.5
Docker is 6.6
This had the same issue when working with 6.6 to 6.6
interesting info,
My web app(pouchdb) syncs new docs bidirectional to the CB server.
But not existing docs in CB server
@morgan
Did you open all the ports when running docker?
docker run -d --name db -p 8091-8094:8091-8094 -p 11210-11211:11210-11211 couchbase
If you can attach the xdcr logs from the source cluster, that’d be helpful.
yes ports open on docker.
Docker XDCR to CB server works fine.
XDCR from CB server to docker not working
logs from source cluster above
The screenshot above is not considered a log. See:
https://docs.couchbase.com/server/current/manage/manage-logging/manage-logging.html
I’m interested in goxdcr.log.
Also, from the on-prem can you run:
curl -X GET -u <username>:<password> http://<targetIP>:8091/pools/default/buckets/<targetBucketName>
And post the output here?
Thanks.
{
“name”: “dvir”,
“bucketType”: “membase”,
“authType”: “sasl”,
“proxyPort”: 0,
“uri”: “/pools/default/buckets/dvir?bucket_uuid=f7ca15365469393a245d8eb8fc9a7343”,
“streamingUri”: “/pools/default/bucketsStreaming/dvir?bucket_uuid=f7ca15365469393a245d8eb8fc9a7343”,
“localRandomKeyUri”: “/pools/default/buckets/dvir/localRandomKey”,
“controllers”: {
“compactAll”: “/pools/default/buckets/dvir/controller/compactBucket”,
“compactDB”: “/pools/default/buckets/dvir/controller/compactDatabases”,
“purgeDeletes”: “/pools/default/buckets/dvir/controller/unsafePurgeBucket”,
“startRecovery”: “/pools/default/buckets/dvir/controller/startRecovery”
},
“nodes”: [
{
“couchApiBaseHTTPS”: “https://192.168.0.12:18092/dvir%2Bf7ca15365469393a245d8eb8fc9a7343”,
“couchApiBase”: “http://192.168.0.12:8092/dvir%2Bf7ca15365469393a245d8eb8fc9a7343”,
“systemStats”: {
“cpu_utilization_rate”: 56.27186406796601,
“swap_total”: 9935249408,
“swap_used”: 6440857600,
“mem_total”: 8593072128,
“mem_free”: 3544735744
},
“interestingStats”: {
“cmd_get”: 4,
“couch_docs_actual_disk_size”: 335241569,
“couch_docs_data_size”: 237717303,
“couch_spatial_data_size”: 0,
“couch_spatial_disk_size”: 0,
“couch_views_actual_disk_size”: 6285296,
“couch_views_data_size”: 6299323,
“curr_items”: 3031,
“curr_items_tot”: 3031,
“ep_bg_fetched”: 0,
“get_hits”: 4,
“mem_used”: 101125024,
“ops”: 4,
“vb_active_num_non_resident”: 261,
“vb_replica_curr_items”: 0
},
“uptime”: “81579”,
“memoryTotal”: 8593072128,
“memoryFree”: 3544735744,
“mcdMemoryReserved”: 6555,
“mcdMemoryAllocated”: 6555,
“replication”: 0,
“clusterMembership”: “active”,
“recoveryType”: “none”,
“status”: “healthy”,
“otpNode”: “ns_1@127.0.0.1”,
“thisNode”: true,
“hostname”: “192.168.0.12:8091”,
“clusterCompatibility”: 327685,
“version”: “5.5.6-4733-enterprise”,
“os”: “win64”,
“cpuCount”: 4,
“ports”: {
“httpsMgmt”: 18091,
“httpsCAPI”: 18092,
“proxy”: 11211,
“direct”: 11210
},
“services”: [
“eventing”,
“fts”,
“index”,
“kv”,
“n1ql”
]
}
],
“stats”: {
“uri”: “/pools/default/buckets/dvir/stats”,
“directoryURI”: “/pools/default/buckets/dvir/statsDirectory”,
“nodeStatsListURI”: “/pools/default/buckets/dvir/nodes”
},
“nodeLocator”: “vbucket”,
“saslPassword”: “b37943ebeeca4b7bf881946f7a02bd82”,
“ddocs”: {
“uri”: “/pools/default/buckets/dvir/ddocs”
},
“replicaIndex”: false,
“autoCompactionSettings”: false,
“uuid”: “f7ca15365469393a245d8eb8fc9a7343”,
“vBucketServerMap”: {
“hashAlgorithm”: “CRC”,
“numReplicas”: 1,
“serverList”: [
“192.168.0.12:11210”
],
“vBucketMap”: [
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1,[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],…
…[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],
[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1
],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1]]},
“maxTTL”: 0,
“compressionMode”: “passive”,
“replicaNumber”: 1,
“threadsNumber”: 3,
“quota”: {
“ram”: 104857600,
“rawRAM”: 104857600
},“basicStats”: {
“quotaPercentUsed”: 20.43660736083984,
“opsPerSec”: 1,
“diskFetches”: 0,
“itemCount”: 986,
“diskUsed”: 110756156,
“dataUsed”: 83105894,
“memUsed”: 21429336,
“vbActiveNumNonResident”: 261
},“evictionPolicy”: “valueOnly”,
“conflictResolutionType”: “seqno”,
“bucketCapabilitiesVer”: “”,
“bucketCapabilities”: [
“couchapi”,
“xattr”,“dcp”,“cbhello”,“touch”,“cccp”,
“xdcrCheckpointing”,
“nodesExt”]}
shows the problem here.
I believe when you set up the docker cluster, you set it up using a specific IP of 192.167.0.12 instead of keeping it as a loopback device (default).
As a result, it is using the private network IP and broadcasting it to the outside world.
Here is the page on how it should be named:
What you want to do is leave it as a loopback, or if you want to name it, it needs to be named to a public-facing ready FQDN or public IP.
Thus when your XDCR tries to connect to the remote cluster (docker) to talk to the memcached, it’s trying to connect to a “private IP” thinking it is the outside world and it’s timing out.
Just to clarify to you, The IP 192.167.0.12 is my CB server not my Docker
In my previous comment I asked you to run the command from your CB server (on-prem) with the target as your docker
And please upload the XDCR logs from your on prem CB server
Yes, i did just that . Using my on-prem ip and bucket name, i ran the cmd
http://<targetIP>:8091/pools/default/buckets/<targetBucketName>
output above
My understanding is that you’re having issues with going from on-prem to docker.
Does that mean you used the on-prem IP as the “targetIP”?
The curl command should be executed on your on-prem. the targetIP should be your docker IP, and targetbucketName should the target bucket sitting on the docker.