Have a question about CouchBase and XDCR

Couchbase Server
1

I’m seeing these entries in the babysitter.log and not sure if I should worry.

I have a couchbase cluster (couchbase 5.1.1 community) in AWS and in Azure. They are using XDCR one way replication from AWS to Azue.

I’m seeing these log entries on some nodes in both clusters.

========================CRASH REPORT=========================
crasher:
initial call: ale_disk_sink:init/1
pid: <0.5059.196>
registered_name: 'sink-goxdcr'
exception exit: {worker_died,<0.5058.196>,{badmatch,{error,eacces}}}
  in function  gen_server:terminate/6 (gen_server.erl, line 744)
ancestors: [<0.5055.196>,ale_dynamic_sup,ale_sup,<0.38.0>]
messages: []
links: [<0.5055.196>]
dictionary: []
trap_exit: true
status: running
heap_size: 4185
stack_size: 27
reductions: 11745
neighbours:

[error_logger:error,2018-12-  11T17:53:36.407Z,babysitter_of_ns_1@127.0.0.1:error_logger<0.6.0>:ale_error_logger_handler:do_log:203]
=========================CRASH REPORT=========================
crasher:
initial call: ale_dynamic_sup:delay_death_init/3
pid: <0.5055.196>
registered_name: []
exception exit: {worker_died,<0.5058.196>,{badmatch,{error,eacces}}}
  in function  ale_dynamic_sup:handle_child_exit/4 (src/ale_dynamic_sup.erl, line 118)
ancestors: [ale_dynamic_sup,ale_sup,<0.38.0>]
messages: []
links: [<0.40.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 376
stack_size: 27
reductions: 134
neighbours:

[error_logger:error,2018-12-11T17:53:36.408Z,babysitter_of_ns_1@127.0.0.1:error_logger<0.6.0>:ale_error_logger_handler:do_log:203]

I’m seeing this on nodes that are not reporting the crash report

memcached<0.78.0>: 2018-12-11T17:58:12.667954Z WARNING 367 Closing   connection (0x7fb9e34a7698) [ 127.0.0.1:50734 - 127.0.0.1:11210 (not authenticated) ] due to read error: Connection reset by peer

Please let me know… I tried to google search with no luck.

2

The “Closing connection” error on the nodes without the crash report is not critical.

I have never seen the “sink-goxdcr” crash message before. A better way to check goxdcr health is through ns_server.goxdcr.log. If there are “panic” messages, or there are more than one “GOMAXPROCS” messages in the log, goxdcr process may have crashed before. Even if this has happened, goxdcr process should be able to recover automatically since couchbase server should bring up goxdcr process immediately. As long as the “changes_left” stats in goxdcr log, and the corresponding “Mutations left” stats on bucket UI stay low, you should be fine.