Shell command to disable replication?

[Schwabix]

Hello,

Thank you a lot for a great product and good support!
I seem to have a problem that wasn't discussed here before - at least not with the keywords I can think of ...

Is there a way to disable replication via shell/console commands - not via GUI?

Background:
We have two FreeNAS servers, with a primary replicating to a secondary in relatively short intervals (depending on data set: daily ... hourly). This is used as a life backup.
Now primary lost it's GUI, everything else is working well. As suggested in thread no-gui-an-error-occurred I wanted to boot back into a previous version and apply updates once more.
To do so I would fail over to secondary (by changing the DNS cname entry), then disable replication on primary ASAP. Otherwise replication would continue and reset write operations of clients to the last state of primary.

BUT, how can I do this without GUI?
Is there a better approach?

In case versions do matter: primary runs 9.10, secondary was updated to 11 recently.

Regards, Markus

 

[Johnny Fartpants]

Sometimes you can get the UI back by running the two commands below from the CLI:

service nginx restart
service django restart

Failing that you could always just disable SSH on your secondary server until you have your primary sorted.

 

[Johnny Fartpants]

PS: Be careful when failing over to the secondary if you are going to allow write operations as you will find it hard/impossible to get the two servers back in-sync without starting again on the original primary. By default your secondary will be ready-only and if you can I would keep it that way during the time you are fixing your primary. Only if I have decided the primary is completely lost would I enable write operations on my secondary system as at that stage I don't have a backup until I have fixed my old primary and replicated back to it. Hope that makes sense.

 

[Schwabix]

Thank you.
Already tried to restart nginx. It is happy about it's config files, but still shows error page to http clients.
django is not running - should it?

I made my secondary read-write. If somebody writes to secondary the next replication will reset files to the state on primary. Whether this is walking the edge of a cliff I don't know.

I did such failover before, but disabled replication via GUI right after the failover; later reverted the replication direction to get primary back in sync.

Is there a better way to do a failover with no (or almost no) down time? We have a test lab with almost 300 automated systems accessing the NAS 24/7. The bulk are reads.

 

[Schwabix]

... ah, I had to read your hint to disable SSH several times until I understood it.
This means no SSH would block replication completely? Sounds easy enough. And the console of secondary would still be available for whatever I would use SSH under normal circumstances.

 

[Johnny Fartpants]

... ah, I had to read your hint to disable SSH several times until I understood it.
This means no SSH would block replication completely? Sounds easy enough. And the console of secondary would still be available for whatever I would use SSH under normal circumstances.

Either way would work either disable ssh from the command line of the primary or disable ssh from the UI on the secondary. I doubt you will miss ssh on the secondary for the length of time it will take you to roll-back the OS on the primary.

 

[Johnny Fartpants]

Thank you.
Already tried to restart nginx. It is happy about it's config files, but still shows error page to http clients.
django is not running - should it?

I made my secondary read-write. If somebody writes to secondary the next replication will reset files to the state on primary. Whether this is walking the edge of a cliff I don't know.

I did such failover before, but disabled replication via GUI right after the failover; later reverted the replication direction to get primary back in sync.

Is there a better way to do a failover with no (or almost no) down time? We have a test lab with almost 300 automated systems accessing the NAS 24/7. The bulk are reads.

I too have done the failover and fail back but only on dev systems. I would be very nervous about doing it on a live production system unless I had no other option as there are a lot of things that could go wrong. Personally if the primary system goes down or is planned to go down for no more than 24/48 hours giving users read-only access to their data is preferred for me however if things look much more serious and we look like we are going to pass the 48 hour window I would then consider making the secondary system read/write and in-tern become the new primary. Once the old primary was up and running I would trash the pool and it would become my new secondary and I would start a new replication.

 

[Schwabix]

Solved. The restart of django fixed my problem, no need to boot into the older installation, thus no failover (this time :)).

I added this hint to the other thread just for completeness.

Thank you!!

 

[Johnny Fartpants]

Is there a better way to do a failover with no (or almost no) down time?

No, I don't think there is with FreeNAS. Async replication is the best it gets. Naturally you can consider HA systems offered by iX in their TrueNAS range but that doesn't give you two synchronised pools but instead two server heads in an active/passive setup with a heartbeat link between the two. I think what you are doing sounds fine I would just tread carefully when failing between the two boxes.

 

[Johnny Fartpants]

Solved. The restart of django fixed my problem, no need to boot into the older installation, thus no failover (this time :)).

I added this hint to the other thread just for completeness.

Thank you!!

Cool, nice work.