0

I am setting up an AlwaysOn Availability Group with 3 nodes. 1 Primary, 1 Secondary Read-only node and 1 secondary non-readable node. I want to offload my maintenance jobs to my secondary read-only node which is fine. I can do this by adding a step to all my maintenance jobs to check the node. If it's the Primary node, the job will stop before moving on to the next step.

I also have a maintenance database where I record all my maintenance job information such as failures, start times, end time, durations, index/statistic names etc etc. I want to keep this database within my AG group rather than have a different maintenance DB on each node. So my question is..

IF my maintenance jobs are running on my secondary read-only node and I need this to record audit information in a maintenance database within the AG Group, will this automatically write the data to the Primary Node DB or will it try and write this to the Secondary Node database. If it tries to write to the secondary node will it fail? If it does, is there a good workaround that doesn't involve having a separate maintenanceDB on each node or keeping my maintenanceDB within it's own separate Availability Group?

  • What kind of maintenance are you looking to perform on a secondary, read-only node? – LowlyDBA - John McCall Nov 14 '17 at 15:00
  • You would have to use a linked server, or some other method to write back to the database on the primary replica, you cannot write to databases that are part of an AG on secondary replicas as they are in a recovering state. – Nic Nov 14 '17 at 15:03
  • Backups, DBCC CheckDBs, Index/Statistic Maintenance. I want to offload this from the Primary Node. – GPep Nov 14 '17 at 15:07
  • You can only do t-log backups on secondary, can't do index/stat maintenance, and I would recommend still doing DBCC checks on your primary node. There might be a lot less to record than you think - but you could also using a sqlcmd step using ApplicationIntent and read only routing to make sure you get the primary. – LowlyDBA - John McCall Nov 14 '17 at 15:12
  • Ah yes.. You are quite right.. I assumed I could move my index maintenance over too. The problem with my DBCC checks are that my database is huge and very messy.. It currently only runs once per week but having a secondary node might allow me to run it more often... But thanks both Nic and LowlyDBA - I will do some testing and get back to you. I may just go back to running all maintenance on my Primary.. – GPep Nov 14 '17 at 15:34
0

No, it won't automatically write to the primary database instance. You need to connect to the primary instance and perform your data inserts on that instance (linked servers is one option to do this).

You also need to make sure you're running your jobs in the right location. For example, Transaction Log Backups can be offloaded to a secondary, but even a synchronous secondary can run behind the primary (sometimes by a lot of time). If that happens, are you going to be able to meet your RPO goals?

Index maintenance is going to have to run on the primary as it needs a writable database - you can't offload this task.

CHECKDB can be run on the secondary, but I think it should be run on all instances if at all possible. When replication happens it only transfers the log data, not data pages. If you have a disk subsystem corruption on one of your replicas that you don't run CHECKDB on then you may not find corruption until you failover.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.