feat: add label master_replid to metricinstance_info

[wilkice]

metrics output

redis_instance_info{master_replid="08d93f3f012d5c31fc135f81eebe34056a16718b",maxmemory_policy="noeviction",os="Linux 6.8.11-300.fc40.aarch64 aarch64",process_id="1",redis_build_id="f52510608ef57ee1",redis_mode="standalone",redis_version="6.2.6",role="master",run_id="5df26f6efeab16c5eed4f8198f431559f510ccfc",tcp_port="6379"} 1

related issue: #919

only add label master_replid to metricinstance_info, replication metrics hasn't add this label. Will add later

[coveralls]

Pull Request Test Coverage Report for Build 382

Details

• 5 of 5 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 83.968%

---

Totals
Change from base Build 379:	0.02%
Covered Lines:	1985
Relevant Lines:	2364

---

💛 - Coveralls

[oliver006]

Change looks good - thanks for the PR!

[oliver006]

👍

[wilkice]

I missed one thing, for KeyDB, there maybe multiple master. So will be multiple master_replid. will do some research how to do this.

[wilkice]

after do some research, I think we may not add the master_replid label to replication metrics. Only add master_replid label to instance_info is ok.

I have three KeyDB server with docker-compose(server3 is slave of server1 and server2)

services:
  server1:
    container_name: server1
    image: eqalpha/keydb
    networks:
      - keydb
  server2:
    container_name: server2
    image: eqalpha/keydb
    networks:
      - keydb
  server3:
    container_name: server3
    image: eqalpha/keydb
    networks:
      - keydb
    command: keydb-server --multi-master yes --active-replica yes --replicaof  server1 6379 --replicaof server2 6379

networks:
  keydb:

the info replication command result from server3 is

# Replication
role:active-replica
master_global_link_status:up
connected_masters:2
master_host:server1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_read_repl_offset:155
slave_repl_offset:155
master_1_host:server2
master_1_port:6379
master_1_link_status:up
master_1_last_io_seconds_ago:10
master_1_sync_in_progress:0
slave_read_repl_offset:155
slave_repl_offset:155
slave_priority:100
slave_read_only:0
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:21003fb414c556027d43524e4c8ce8660a318eb2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:268
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:268

and info replication command result from server1

# Replication
role:master
connected_slaves:1
slave0:ip=10.89.0.4,port=6379,state=online,offset=295,lag=1
master_failover_state:no-failover
master_replid:02a5eb9523b6046a67b9866a12140cbc5fab7da7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:295
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:295

and info replication command result from server2

# Replication
role:master
connected_slaves:1
slave0:ip=10.89.0.4,port=6379,state=online,offset=337,lag=0
master_failover_state:no-failover
master_replid:72e3c5eeca05a48de05dd000394d6675c0ab2b83
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:337
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:337

My thought

although server3 has 2 master, but it only has one totally unique master_replid, which is fine, since the data in server3 is merged data from server1 and server2.
So if we add master_replid to any of replication metrics, it may leave confusion about the master-slave role when trying to aggregate by master_replid. Since server3's master_replid is not the same with server1 or server2.