• State Not Answered
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 3322 views
  • Users 0 members are here
Options
Related

Update ARS 7.3.1 => 7.4.3 with Publisher / Subscriber mode

Gégé
over 3 years ago

Hello all !

I hope you are well ;)

I'm trying to update Active Roles 7.3.1 to 7.4.3 on two servers with a Publisher / Subscriber replication database configuration.

I understood that it was necessary to go back to Standalone mode on each server.

But when I'm in the Service administration, Configuration Database, and I do a right click on a a database, I don't have Standalone ....

What did I not understand in this SQL operating mode?

Thank you in advance for your help ;)

Gégé

Parents
  • 0 over 3 years ago

    When you right click on the database, do you see the option for Demote? This would be how you can place the databases back to Standalone mode.

    However, breaking the replication model is not really necessary when performing an upgrade. The upgrade process involves the importing of the data from 7.3.1 into a new 7.4.3 database. You can import from a database that is a Publisher and the new 7.4.3 database will become a Standalone database after the import. The replication model will then need to be recreated once the other subscriber(s) are upgraded to 7.4.3 and their new, empty databases created. You can Promote the original Publisher back to being a 7.4.3 Publisher and then add the remaining, newly upgraded servers by adding them as Replication Partners.

  • 0 over 3 years ago in reply to Richard.Lambert

    Just a note here - we're going through the same process now - and to test - I did not break replication for this in-place upgrade as advised above. Wanted that to work!  We use a custom SQL port + alias for the sister SQL's to talk to one another.   ARS wasn't happy.  I had to remove custom port and alias,reconnect ARS the standard port via powershell, restart the service - and then proceed.

    After removing the subscriber from the publisher attached ARS service, and demoting to stand alone - the upgrade proceeded without a hitch in DEV.  Upgraded the standalone former-sub using a new blank DB and had the publisher attached service converted it to a sub again.  Replication ensued - and all went a smooth as a slice of caramel bundt cake.

Reply
  • 0 over 3 years ago in reply to Richard.Lambert

    Just a note here - we're going through the same process now - and to test - I did not break replication for this in-place upgrade as advised above. Wanted that to work!  We use a custom SQL port + alias for the sister SQL's to talk to one another.   ARS wasn't happy.  I had to remove custom port and alias,reconnect ARS the standard port via powershell, restart the service - and then proceed.

    After removing the subscriber from the publisher attached ARS service, and demoting to stand alone - the upgrade proceeded without a hitch in DEV.  Upgraded the standalone former-sub using a new blank DB and had the publisher attached service converted it to a sub again.  Replication ensued - and all went a smooth as a slice of caramel bundt cake.

Children