# Unable to determine master addresses

**URL:** <https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747>\
**Category:** General\
**Created:** [June 26, 2024, 11:20pm UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747 "2024-06-26T23:20:17Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![thesmith](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/thesmith/32/822_2.png) [@thesmith](https://forum.yugabyte.com/u/thesmith)\
**Post date:** [June 26, 2024, 11:20pm UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747/1 "2024-06-26T23:20:17Z")

</div>

I have a 2 cluster database setup… I changed the “–advertise\_address” flag to another IP and restarted YB, and it failed to start with the error “Could not locate the leader master: Unable to determine master addresses”. I then changed the IP back to the original address, but I still received the same error. The logs show:  
Master address list updated, new list:  
cmd: [‘/yugabyte-2.20.2.0/bin/yb-admin’, ‘–master\_addresses’, ‘’, ‘get\_universe\_config’]

Can anyone offer some insight?  
Thanks

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [June 27, 2024, 7:25am UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747/2 "2024-06-27T07:25:04Z")

</div>

Hi @thesmith

> [@thesmith](#):
>
> I have a 2 cluster database setup

Can you explain what you mean by this? What’s your RF and how many servers do you have?

Did you change the `–advertise_address` of yb-master ot yb-tserver?

---

<div class="post-metadata">

**Author:** ![thesmith](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/thesmith/32/822_2.png) [@thesmith](https://forum.yugabyte.com/u/thesmith)\
**Post date:** [June 27, 2024, 7:58am UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747/3 "2024-06-27T07:58:30Z")

</div>

Hi @dorian_yugabyte… thanks for your response.  
I’m using the yugabyted process. Regarding the number of DB servers, this is 2 (sorry, I said 2 clusters, misspoke). I changed the -–advertise\_address that is passed into the yugabyted command. I changed to a second IP on the server… however, this seems to have broken things, and I don’t understand why. Even changing it back to the original IP, no joy.

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [June 27, 2024, 8:27am UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747/4 "2024-06-27T08:27:14Z")

</div>

Note that generally 2 nodes setups aren’t supported (assuming you meant RF2?) [Deployment checklist for YugabyteDB clusters | YugabyteDB Docs](https://docs.yugabyte.com/preview/deploy/checklist/#replication)

Also, please paste the full log lines?

---

<div class="post-metadata">

**Author:** ![HeCorr](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/hecorr/32/904_2.png) [@HeCorr](https://forum.yugabyte.com/u/HeCorr)\
**Post date:** [February 4, 2025, 7:11pm UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747/5 "2025-02-04T19:11:51Z")

</div>

**Edit: solved. read the very bottom.**

I’m facing a similar situation. I had a Docker-Compose file with just Yugabyte in it, and that worked fine, but then I added a pgAdmin service and that made the Yugabyte container start with a different IP and ysqlsh started freezing when attempting to connect, then timing out with `Timed out waiting kResponseSent, state: kProcessingRequest`.

I checked the config and saw that it had both the old (now pgAdmin’s) and new IPs in “current\_masters”, but no matter what I do I can’t get it to work again… I emptied that config field and added `--master_flags "master_addresses=127.0.0.1:7100"` to the `yugabyted start` command and I’m still seeing the following errors in `/root/var/logs/yugabyted.log`:

```auto
OUT >>

<< ERR >>
Illegal state (yb/client/client-internal.cc:2787): Unable to establish connection to leader master at []. Please verify the addresses and check if server is up, or if you're missing --certs_dir_name.

: Could not locate the leader master: Unable to determine master addresses

<<
[yugabyted start] 2025-02-04 18:56:51,721 INFO: | 2.3s | thread-uml: current masters ['']
[yugabyted start] 2025-02-04 18:56:51,721 INFO: | 2.3s | thread-uml: Unable to query for all masters list, keeping masters list: ['']
[yugabyted start] 2025-02-04 18:57:51,755 INFO: | 62.4s | thread-uml: current masters ['']
[yugabyted start] 2025-02-04 18:57:51,756 INFO: | 62.4s | thread-uml: Unable to query for all masters list, keeping masters list: ['']
[yugabyted start] 2025-02-04 18:58:51,816 INFO: | 122.4s | thread-uml: current masters ['']
[yugabyted start] 2025-02-04 18:58:51,817 INFO: | 122.4s | thread-uml: Unable to query for all masters list, keeping masters list: ['']

```

And now the config has `"current_masters": ",172.19.0.2:7100"` (the container’s IP) which seems like it should work, yet it doesn’t.

At this point I could totally nuke it all and start from scratch since I have no important data in the database, but what if I did? I need to know how to solve this problem.

* * *

- Edit 1: I temporarily fixed it by removing the pgAdmin service from the compose file, reverting the `yugabyted start` command to what it was before and starting it up, then re-adding the pgAdmin service. It works for now but I’m sure if the IP changes again the same problem will happen. Should I **really** not be persisting `/root/var/conf/yugabyted.conf` in a Docker volume??

- Edit 2: yep… just as a test I downed both services and up’ped them again and it immediately broke. Here’s the logs now:

```auto
[yugabyted start] 2025-02-04 19:28:49,327 INFO: | 2.2s | run_process: cmd: ['/home/yugabyte/bin/yb-admin', '--master_addresses', '', 'get_universe_config']
[yugabyted start] 2025-02-04 19:28:49,392 INFO: | 2.2s | run_process returned 1: 
OUT >>

<< ERR >>
Illegal state (yb/client/client-internal.cc:2787): Unable to establish connection to leader master at []. Please verify the addresses and check if server is up, or if you're missing --certs_dir_name.

: Could not locate the leader master: Unable to determine master addresses

<<
[yugabyted start] 2025-02-04 19:28:49,479 INFO: | 2.3s | thread-uml: current masters ['']
[yugabyted start] 2025-02-04 19:28:49,480 INFO: | 2.3s | thread-uml: Unable to query for all masters list, keeping masters list: ['']
[yugabyted start] 2025-02-04 19:29:49,533 INFO: | 62.4s | thread-uml: current masters ['']
[yugabyted start] 2025-02-04 19:29:49,534 DEBUG: | 62.4s | Tserver 172.19.0.3 returned the following set of the current masters 172.19.0.2:7100,172.19.0.3:7100.
[yugabyted start] 2025-02-04 19:29:49,534 INFO: | 62.4s | thread-uml: master list updated, old list: [''] new list: ['172.19.0.2:7100', '172.19.0.3:7100']
[yugabyted start] 2025-02-04 19:29:49,534 INFO: | 62.4s | run_process: cmd: ['/home/yugabyte/bin/yb-ts-cli', '--server_address=172.19.0.3:9100', 'set_flag', 'tserver_master_addrs', '172.19.0.2:7100,172.19.0.3:7100', '--force']

```

`172.19.0.2` is the old IP, now belonging to the pgAdmin service, yet it is still being used as a master address.

- Edit 3: solved it by setting a static hostname for the container, using it in the config file (`current_masters`) and enabling DNS (`dns_enabled`), which is turned off by default for whatever reason.

---

<div class="post-metadata">

**Author:** ![nmalladi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/nmalladi/32/236_2.png) [@nmalladi](https://forum.yugabyte.com/u/nmalladi)\
**Post date:** [February 5, 2025, 12:58am UTC](https://forum.yugabyte.com/t/unable-to-determine-master-addresses/2747/6 "2025-02-05T00:58:31Z")

</div>

Changing the ip-address of an existing server is not supported by YugabyteDB. To avoid this situation, one has to bring up a new node and retire the previous node. however, the docker environment is inherently susceptible to changing container ip-address. We have changed the docker behavior to bind to the DNS name by default.

This change is available in 2024.2 release. You can follow this GH issue - [[yugabyted] Error binding socket after docker host restart · Issue #18572 · yugabyte/yugabyte-db · GitHub](https://github.com/yugabyte/yugabyte-db/issues/18572).