Removing a Perfectly Good Cluster, Part Two

SQL Server Best Practices
SQL Server Best Practices
Yesterday I started a new project to downgrade our two new SQL Server 2008 R2 clusters down to SQL Server 2008 clusters. The uninstall went off without a hitch as we removed both nodes and then removed the support tools. I find it interesting that when we went to install the 2008 server, there was still tempDB data files which prevented the new install from moving forward until we deleted them. I am not sure if the other system databases were there as the installer did not complain about those. In hindsight, I probably should have removed all of the directories and files before installing as a general best practice but I did reboot the server prior to the new install and thought it would be fine.

Because I do not spin up new clusters everyday (that would be a great job), I took screen shots during the initial 2008 R2 install to serve as a guide because I knew that I had a total of three clusters to build by the end of the year. In this scenario, documentation is an amazing thing (well it is amazing in most areas but most DBAs become complacent about doing it myself included). Originally I built the first two clusters back in January and since they were the first clusters that I had ever built I wanted to document it as I am responsible for many systems and quite honestly I would not have remembered the settings chosen on each screen. Having worked with SQL Server for sometime, I could have configured a stand-alone server in my sleep, but I was not as confident with clusters.  My confidence is building at this point.

Continue reading on SQLGator.com.

54321
(0 votes. Average 0 of 5)