Best Practices



  • My problem is we have several critical DB servers gathering data 24/7. I have to be vague, but bear with me. So we have a server and we will call it History1. There are tons of small apps, spreadsheets, web pages all over the company that look at the data on History1. It has a single IP, and is added into Active Directory with the name History1. Now with all this traffic eventually we have to upgrade our old History1. So what is the best practice here?

    1. We make a History2, then track down every item that pointed to History1, and update it to point to History2. However user apps, and spreadsheets become overwhelming.

    2. We make History2, then wile trying to have 0 downtime, rename it to History1, and hope that active directory propagates the name change right.

    I have tried it both ways, and both ways suck. Is there a better way?



  • @s.hackleman said in Best Practices:

    My problem is we have several critical DB servers gathering data 24/7. I have to be vague, but bear with me. So we have a server and we will call it History1. There are tons of small apps, spreadsheets, web pages all over the company that look at the data on History1. It has a single IP, and is added into Active Directory with the name History1. Now with all this traffic eventually we have to upgrade our old History1. So what is the best practice here?

    1. We make a History2, then track down every item that pointed to History1, and update it to point to History2. However user apps, and spreadsheets become overwhelming.

    2. We make History2, then wile trying to have 0 downtime, rename it to History1, and hope that active directory propagates the name change right.

    I have tried it both ways, and both ways suck. Is there a better way?

    Make History2, then when you offline History1, add a DNS entry for History1 as a CNAME that points to History2



  • I think, beyond that, you are getting into near HA needs.



  • Could you set it up with a DFS namespace? Or is this not file share data and only database data?



  • @coliver said in Best Practices:

    Could you set it up with a DFS namespace? Or is this not file share data and only database data?

    He said DB



  • @JaredBusch said in Best Practices:

    @coliver said in Best Practices:

    Could you set it up with a DFS namespace? Or is this not file share data and only database data?

    He said DB

    Right, critical data is DB



  • @JaredBusch said in Best Practices:

    @coliver said in Best Practices:

    Could you set it up with a DFS namespace? Or is this not file share data and only database data?

    He said DB

    If that's the case then doing @JaredBusch original suggestion would make the most sense.



  • I'm with @JaredBusch this is what DNS aliases are for.



  • Prior to the changes, update your DNS TTL to be extremely short.

    That way there will truly be little downtime for any properly configured system.



  • Could I make a DNS alias called HistoryServer Then point it to both History1? Then point all apps to HistoryServer. When ever an upgrade comes due, I can just update the DNS alias in one place?



  • @s.hackleman said in Best Practices:

    Could I make a DNS alias called HistoryServer Then point it to both History1? Then point all apps to HistoryServer. When ever an upgrade comes due, I can just update the DNS alias in one place?

    That wold be the better thing, yes.



  • @s.hackleman said in Best Practices:

    Could I make a DNS alias called HistoryServer Then point it to both History1? Then point all apps to HistoryServer. When ever an upgrade comes due, I can just update the DNS alias in one place?

    Yes, but if you can do that, you could just rename, too. This is the better way to go, and ideally should be done from the start.