cluster with garbd node shows blank IP for wrsep

I am trying to create a garbd node to manage my two geographically separate clusters. When adding the garbd node to one of the cluster, I get a good output on the garbd server;



Shifting JOINER -> JOINED (TO: 22096)
2016-11-11 18:16:32.524 INFO: 0.0 (devvm2): State transfer to 2.0 (garb) complete.
2016-11-11 18:16:32.524 INFO: Member 2.0 (garb) synced with group.
2016-11-11 18:16:32.524 INFO: Shifting JOINED -> SYNCED (TO: 22096)
2016-11-11 18:16:32.524 INFO: Member 0.0 (devvm2) synced with group.
2016-11-11 18:16:35.000 INFO: (8e778b14, 'tcp://0.0.0.0:4567') turning message relay requesting off

The problem is the cluster itself only shows the primary 3 nodes, with a gap/empty spare where the garbd node is supposed to appear.

Any ideas on what I can do? Is this a non issue?

mysql> show status like 'wsrep%';
+------------------------------+-----------------------------------------------------+
| Variable_name | Value |
+------------------------------+-----------------------------------------------------+
| wsrep_local_state_uuid | 38bbd160-3d6e-11e6-873d-1235a6748826 |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 22096 |
| wsrep_replicated | 0 |
| wsrep_replicated_bytes | 0 |
| wsrep_repl_keys | 0 |
| wsrep_repl_keys_bytes | 0 |
| wsrep_repl_data_bytes | 0 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 18 |
| wsrep_received_bytes | 4625 |
| wsrep_local_commits | 0 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 2 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.055556 |
| wsrep_local_cached_downto | 0 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 0.000000 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 0.000000 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 0.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 0 |
| wsrep_cert_bucket_count | 22 |
| wsrep_gcache_pool_size | 1370 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.000000 |
| wsrep_incoming_addresses | 10.10.7.246:3306,10.10.7.245:3306,,10.10.7.247:3306 |
| wsrep_desync_count | 0 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0/0/0/0/0 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | 33323034-85bc-11e6-95cb-22fd8bfd1b9f |
| wsrep_cluster_conf_id | 14 |
| wsrep_cluster_size | 4 |
| wsrep_cluster_state_uuid | 38bbd160-3d6e-11e6-873d-1235a6748826 |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 1 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info&#64;codership.com> |
| wsrep_provider_version | 3.16(r5c765eb) |
| wsrep_ready | ON |
+------------------------------+-----------------------------------------------------+
59 rows in set (0.00 sec)


Percona 5.6 XtraDB Cluster on CentOS 6 64-bit machines

This is expected behavior. Field wsrep_incoming_address is often used to track active node IP addresses that can be used for workload.
garbd is doesn’t belong to this category.

Here is old lp bug that was raised too for the same issue.
[url]https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1531846[/url]

oh damn! thanks! i will move forward with the garbd node now