service pack on cluster

  • We have a sharepoint farm that uses a cluster for database server.

    The cluster has two nodes, one active the other is passive.

    The database server now is SQL 2008 SP1, and sharepoint is Sharepoint 2007(MOSS 2007) SP2.

    Now I would like to apply SQL server 2008 SP3 on the cluster - two nodes.

    I have experiences to apply Service pack, but this one has some complications. First it is a cluster, second it is a sharepoint cluster that we don't have much control of their databases.

    I never did this before, and we donot have a test environment.

    I did find a knowlegebase article 958734 in microsoft talking about failover cluster rolling patch but it sounds very complicated.

    We only have two nodes, so I don't feel comfortable with following the article:

    I asked the original person who installed the cluster, he mentioned the SQL instances are installed first on Node1, then add to Node2.

    here is what I plan to do after some research online:

    1. Apply the hotfix on pasive node N2

    2. Reboot the passive node N2

    3. Failover on SQL resource : the passive node become the active node

    4. Apply the hotfix on the passive node N1

    5. Reboot the passive node N1

    6. Actually I want to use N1 as active node, so failover to N1 again to make N1 active node.

    My question is :

    Is that all I need to do?

    For N2, what is exactly do on the internal update, will it only do SP for client since it is an added node?

    Anyone has similar setup for sharepoint database, can you share some experience of apply sp on the the nodes? What I need to pay attention to?

    Actually we don't care too much about down time, so any way that can help do the SP safely should work for us.

    Thanks,

  • It looks like the steps you mentioned are correct. From my point of view only one thing is missing:

    Before applying the servicepacks I would shut down the Sharepoint sites and stop the services. And start it again when de process is completed. If the business can't stand a longer downtime, you could also stop the sites/services during the failovers of the SQL instance. This is extra ensurance for data consistency en prevents possible data corruption.

    ** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **
  • sqlfriends (6/18/2013)For N2, what is exactly do on the internal update, will it only do SP for client since it is an added node?

    It does a full installation of the hotfix/service pack.

    After an installaltion of SQL server there is no difference between the initial (first node) installation and adding additional nodes. The first installation process is different because during the initial install you have to select more options (collation, cluster group, disk, ip-address, etc.). These options will be automaticly passed on to an "add node" install.

    ** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **
  • HanShi (6/19/2013)


    It looks like the steps you mentioned are correct. From my point of view only one thing is missing:

    Before applying the servicepacks I would shut down the Sharepoint sites and stop the services. And start it again when de process is completed. If the business can't stand a longer downtime, you could also stop the sites/services during the failovers of the SQL instance. This is extra ensurance for data consistency en prevents possible data corruption.

    How can I shut down sharepoint service, I actally don't have access to sharepoint server.

    Does it matter if I leave it on, and do the service pack on the passive mode, then failover, do service pack on another node.

  • HanShi (6/19/2013)


    sqlfriends (6/18/2013)For N2, what is exactly do on the internal update, will it only do SP for client since it is an added node?

    It does a full installation of the hotfix/service pack.

    After an installaltion of SQL server there is no difference between the initial (first node) installation and adding additional nodes. The first installation process is different because during the initial install you have to select more options (collation, cluster group, disk, ip-address, etc.). These options will be automaticly passed on to an "add node" install.

    Thanks,

    Does this mean when I add the second node , the process will physically install the SQL instance on Node2?

    SO I actually have 2 physical SQL instances, but one logical instance.

    Is that correct?

    I have a discussion on another thread now I am a little confused.

    The other thread I told our real server configuration we have two SQL instances installed on each node, but this thread I only says one on each node to make it simpler.

    But by revisiting the earlier thread, I am a little confused,

    how many physical instances or logical instances we have? I didn't do the install so not sure how it was setup. Thanks

    http://www.sqlservercentral.com/Forums/Topic1455284-1550-1.aspx#bm1456759

  • You have two installs of the binaries for SQL, one on each node, the databases are available to only a single node at a time. So no you don't have two instances of SQL you only have one and that one can only be active on a single node at a time. As the example, the shared disks are assigned only one node and only that node may use them.

    Any clearer?

    CEWII

  • Elliott Whitlow (6/19/2013)


    You have two installs of the binaries for SQL, one on each node, the databases are available to only a single node at a time. So no you don't have two instances of SQL you only have one and that one can only be active on a single node at a time. As the example, the shared disks are assigned only one node and only that node may use them.

    Any clearer?

    CEWII

    Thanks, now I understand the databases can only be on one node each time because they are using the same shared disk, only one node or instance can be active.

    But the installation of SQL server software are two complete instances, correct? because I have to do the service pack on each instance on each node.

    And when you say binories for SQL, what is exactly that, SQL server software/program?

    Thanks

    Thanks,

  • I would consider it 2 complete SQL installs, except that the point to a single set of system and user databases. So in that regard yes there are two. When I refer to binaries I am referring to the application and support code for SQL.

    You have to do the service pack for each node because each node contains the application and support code for that instance of SQL.

    I would clarify one point, and it may be semantic on my part.. An instance may be active on only one node at a time. In an active/passive arrangement this does essentially mean that one node is inactive. The phrase "only one node or instance can be active" is accurate for your installation but not for others. I might be being pedantic, sorry.

    CEWII

  • Elliott Whitlow (6/19/2013)


    I would consider it 2 complete SQL installs, except that the point to a single set of system and user databases. So in that regard yes there are two. When I refer to binaries I am referring to the application and support code for SQL.

    You have to do the service pack for each node because each node contains the application and support code for that instance of SQL.

    I would clarify one point, and it may be semantic on my part.. An instance may be active on only one node at a time. In an active/passive arrangement this does essentially mean that one node is inactive. The phrase "only one node or instance can be active" is accurate for your installation but not for others. I might be being pedantic, sorry.

    CEWII

    Thanks, that makes more sense to me now.

    Only one thing I know service pack will make changes to application files or code, but may also do some changes on system database, correct?

    But since they share the same system databases, if I apply service pack to node2 that is in passive mode, has the system databases got upgraded, but how can it be, it is on active node 1?

    Thanks,

  • It is my understanding that the system databases get upgraded when SQL starts for the first time with the new (updated) binaries. It can tell internally that the system version of the objects is different. Also in some cases the system objects are unchanged in the database.

    Clearer?

    CEWII

  • Thanks much,

  • Elliott Whitlow (6/19/2013)


    It is my understanding that the system databases get upgraded when SQL starts for the first time with the new (updated) binaries. It can tell internally that the system version of the objects is different. Also in some cases the system objects are unchanged in the database.

    Clearer?

    CEWII

    In fact, a copy of the MSSQLSystemResource database is now located on each node instead of the shared drive and holds the current version of the installed binaries. This is how SQL Server knows whether to perform a rolling upgrade\downgrade on the instance when it starts.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply