# Database faulted after adding a secondary NIC

**URL:** <https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668>\
**Category:** Ignition\
**Created:** [November 8, 2023, 4:11pm UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668 "2023-11-08T16:11:05Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![ltoscano](https://avatars.discourse-cdn.com/v4/letter/l/3be4f8/32.png) [@ltoscano](https://forum.inductiveautomation.com/u/ltoscano)\
**Post date:** [November 8, 2023, 4:11pm UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668/1 "2023-11-08T16:11:05Z")

</div>

Greetings All,

I have Ignition 8.1.26 connected to a Postgresql database. All was working well. We added a second NIC to the system to allow for internet connection for alarming notification. Soon as we did that, database became faulted. I looked at the setup and thought well maybe localhost isn't localhost anymore and so I put in the IP address of the gateway (the original IP address) instead of localhost but that didn't' make a difference.

The Gateway IP is 192.168.1.50 / 255.255.255.0 (all was fine this way)  
The new NIC is 192.168.200.50 / 255.255.255.0 (causes the faulted connection)

The database connect URL is jdbc:postgresql://localhost:5432/postgres

I've tried replacing "localhost" with 192.168.1.50.

Anybody have any thoughts on this?

Many Thanks to you all

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [November 8, 2023, 5:58pm UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668/2 "2023-11-08T17:58:44Z")

</div>

What is the specific fault?

---

<div class="post-metadata">

**Author:** ![ltoscano](https://avatars.discourse-cdn.com/v4/letter/l/3be4f8/32.png) [@ltoscano](https://forum.inductiveautomation.com/u/ltoscano)\
**Post date:** [November 8, 2023, 6:37pm UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668/3 "2023-11-08T18:37:09Z")

</div>

"Cannot create poolable connection factory (connection to localhost:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections"

Again, all was fine till I added the second NIC so I'm thinking it's looking at the wrong binding or something along those lines?

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [November 8, 2023, 7:29pm UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668/4 "2023-11-08T19:29:27Z")

</div>

Is the DB service running?

---

<div class="post-metadata">

**Author:** ![ltoscano](https://avatars.discourse-cdn.com/v4/letter/l/3be4f8/32.png) [@ltoscano](https://forum.inductiveautomation.com/u/ltoscano)\
**Post date:** [November 9, 2023, 12:48am UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668/5 "2023-11-09T00:48:43Z")

</div>

Yes. If I disable the other NIC all is well again.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [November 9, 2023, 12:56am UTC](https://forum.inductiveautomation.com/t/database-faulted-after-adding-a-secondary-nic/81668/6 "2023-11-09T00:56:31Z")

</div>

I recommend you move the database to a separate server. That way you can isolate DB issues from gateway issues in a less-than-ideal networking environment. (Anything that breaks localhost's definition as 127.0.0.1 is suspicious.)
