Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing

AlwaysOn + Log shipping related blogs
Below blog post are all related to AlwaysOn and log shipping configured together,
-> Configuring Log Shipping with AlwaysOn
-> Removing Log shipping on a database with AlwaysOn configured

Environment

-> JBSAG1, JBSAG2 and JBSAG3 are part of a failover cluster without shared storage. Alwayson Availability group is configured between JBSAG1, JBSAG2 and JBSAG3. JBSAG1 is the current primary, JBSAG2 is the synchronous secondary and JBSAG3 is Asynchronous secondary. The database(s) that is part of Always on Availability group has log shipping configured and its secondary is on JBSAG4.

-> LSCopy and LSRestore jobs were failing.

-> LSCopy job Error,

Date 1/8/2021 1:04:00 PM
Log Job History (LSCopy_JBSAG1_JBDB)
Step ID 1
Server JBSAG4
Job Name LSCopy_JBSAG1_JBDB
Step Name Log shipping copy job step.
Duration 00:00:00
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
2021-01-08 13:04:00.30 *** Error: Could not retrieve copy settings for secondary ID ‘1d58dd23-142c-498f-83ab-5077791b5781’.(Microsoft.SqlServer.Management.LogShipping) ***
2021-01-08 13:04:00.30 *** Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***
2021-01-08 13:04:00.30 *** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) ***
2021-01-08 13:04:00.30 *** Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***
2021-01-08 13:04:00.30 *** Error: Could not cleanup history.(Microsoft.SqlServer.Management.LogShipping) ***
2021-01-08 13:04:00.30 *** Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***

2021-01-08 13:04:00.30 —– END OF TRANSACTION LOG COPY —–
Exit Status: 1 (Error)

-> LSRestore job error,

Date 1/8/2021 1:10:00 PM
Log Job History (LSRestore_JBSAG1_JBDB)
Step ID 1
Server JBSAG4
Job Name LSRestore_JBSAG1_JBDB
Step Name Log shipping restore log job step.
Duration 00:00:00
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
2021-01-08 13:10:00.28 *** Error: Could not retrieve restore settings.(Microsoft.SqlServer.Management.LogShipping) ***
2021-01-08 13:10:00.28 *** Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 2 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***
2021-01-08 13:10:00.30 *** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) ***
2021-01-08 13:10:00.30 *** Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 2 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***
2021-01-08 13:10:00.30 *** Error: Could not cleanup history.(Microsoft.SqlServer.Management.LogShipping) ***
2021-01-08 13:10:00.30 *** Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 2 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***

2021-01-08 13:10:00.30 —– END OF TRANSACTION LOG RESTORE —–
Exit Status: 1 (Error)

-> I searched through the internet and found same/similar errors in LSCopy and LSRestore jobs, if the server mentioned on these jobs are not the log shipping secondary server. Let us look what I have in my database server.

-> LSCopy job step contains below command,

“C:\Program Files\Microsoft SQL Server\150\Tools\Binn\sqllogship.exe” -Copy 1D58DD23-142C-498F-83AB-5077791B5781 -server JBSAG4

-> LSRestore job step contains below command,

“C:\Program Files\Microsoft SQL Server\150\Tools\Binn\sqllogship.exe” -Restore 1D58DD23-142C-498F-83AB-5077791B5781 -server JBSAG4

-> In our setup, LSCopy and LSRestore jobs contains the correct log shipping secondary server as above marked in green. You need to ensure that LSCopy and LSRestore jobs should contain the log shipping secondary servers only.

-> I started a profiler trace on Log shipping secondary server and started LSCopy job and found below,

-> From the above screenshot, function sys.fn_MSvalidatelogshipagentidreturns value 1 or 0 depending on below query,

return case
when ((@agent_type = 0) and
exists (select * from msdb.dbo.log_shipping_monitor_primary
where primary_id = @agent_id)
) then 1
when ((@agent_type in (1,2)) and
exists (select * from msdb.dbo.log_shipping_monitor_secondary
where secondary_id = @agent_id)
) then 1
else 0 end

-> Lets execute the below query on Log shipping secondary JBSAG4 and verify the output,

select secondary_id, primary_server, primary_database from msdb.[dbo].[log_shipping_monitor_secondary]
where secondary_id = '1D58DD23-142C-498F-83AB-5077791B5781'

-> We dont see any data in object msdb.dbo.log_shipping_monitor_secondary for agent_id specified in LSCopy job, so this means it is going to return always 0 and you will see below error,

Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider)

-> Lets execute below query and see what valid id we have in object log_shipping_monitor_secondary,

select secondary_id, primary_server, primary_database from msdb.[dbo].[log_shipping_monitor_secondary]
where primary_database = ‘JBDB’

-> Secondary_id is 1A0BAD73-8C71-4445-96AC-61BC5AC2FD23. Lets try replacing the LSCopy and LSRestore job as below,

LSCopy job,

“C:\Program Files\Microsoft SQL Server\150\Tools\Binn\sqllogship.exe” -Copy 1A0BAD73-8C71-4445-96AC-61BC5AC2FD23 -server JBSAG4

LSRestore job,

“C:\Program Files\Microsoft SQL Server\150\Tools\Binn\sqllogship.exe” -Restore 1A0BAD73-8C71-4445-96AC-61BC5AC2FD23 -server JBSAG4

-> Once I have replaced the jobs using above query. The job completed fine.

-> It seems Always On failover happened from JBSAG1 to JBSAG2, once after the failover someone have opened the log shipping settings and configured secondary server on JBSAG2 as below,

-> Above action created 1 more LSCopy and LSRestore job on secondary server JBSAG4. It seems like the job created as part of JBSAG2 configuration was later removed and this left the other job with wrong secondary_id value. This is the reason for failure.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Removing Log shipping on a database with AlwaysOn configured

AlwaysOn + Log shipping related blogs
Below blog post are all related to AlwaysOn and log shipping configured together,
-> Configuring Log Shipping with AlwaysOn
-> Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing

Environment

-> JBSAG1, JBSAG2 and JBSAG3 are part of a failover cluster without shared storage. Alwayson Availability group is configured between JBSAG1, JBSAG2 and JBSAG3. JBSAG1 is the current primary, JBSAG2 is the synchronous secondary and JBSAG3 is Asynchronous secondary. The database(s) that is part of Always on Availability group has log shipping configured and its secondary is on JBSAG4.

-> The requirement is to remove log shipping from this setup.

-> On Asynchronous secondary JBSAG3. Right click on the log shipped database JBDB and click properties. Click on “Transaction Log Shipping” Tab.

-> Uncheck “Enable this as a primary database in a log shipping configuration” and click OK.

-> On Synchronous secondary JBSAG2. Follow the same steps as above and disable Log shipping,

-> On primary JBSAG1. Follow the same steps as above and disable Log shipping,

-> Once above actions are completed. Check SQL Server agent on JBSAG1, JBSAG2, JBSAG3, JBSAG4 and ensure log shipping related jobs are absent to make sure we have removed log shipping completely.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Configuring Log Shipping with AlwaysOn

AlwaysOn + Log shipping related blogs
Below blog post are all related to AlwaysOn and log shipping configured together,
-> Error: The specified agent_id 1D58DD23-142C-498F-83AB-5077791B5781 or agent_type 1 do not form a valid pair for log shipping monitoring processing
-> Removing Log shipping on a database with AlwaysOn configured

Environment

-> JBSAG1, JBSAG2 and JBSAG3 are part of a failover cluster without shared storage. Alwayson Availability group is configured between JBSAG1, JBSAG2 and JBSAG3. JBSAG1 is the current primary, JBSAG2 is the synchronous secondary and JBSAG3 is Asynchronous secondary. The database(s) that is part of Always on Availability group will have log shipping configured and its secondary will be JBSAG4.

-> AlwaysOn availability group is already configured. Below is the Availability group properties,

-> Transaction log backups will happen on AlwaysOn secondary as per the settings below.

-> This article will discuss how to configure log shipping. Please note that below steps for setting up Log shipping can be followed for both “AlwaysOn Backup preferences” “Secondary only” or “Primary”.

-> On AlwaysOn primary JBSAG1, right click JBDB database and click on properties. Click on “Transaction Log Shipping”,

-> Check “Enable this as a primary database in a log shipping configuration” and click OK.

-> Click “Backup Settings…”. Provide appropriate location where the backup should be placed,

-> Click on Schedule and set appropriate schedule for backup and click OK,

-> Click OK for “Transaction Log Backup Settings”. Click on “Add..” under “Secondary server instances and databases:”. In “Secondary Database Settings” connect to Log shipping secondary server instance.

-> Under “Initialize Secondary Database”, select appropriate option that suits better. In my case I will select first option, since my database is not that big.

-> Click on “Copy Files” and provide appropriate location where the files should be copied over. Select “Schedule” and change the schedule of copy job appropriately,

-> Click OK on the copy job. Click OK on “Secondary Database Settings” and then Click “OK” for “Transaction Log Shipping” on database properties.

-> On AlwaysOn synchronous secondary JBSAG2, right click JBDB database and click on properties. Click on “Transaction Log Shipping”, provide same settings for “Network path to backup folder” and Change the backup job schedule same as what was provided for log shipping settings in AlwaysOn primary JBSAG1.

-> Make sure it is blank for “Secondary server instances and databases:”. Click OK.

-> On AlwaysOn asynchronous secondary JBSAG3, right click JBDB database and click on properties. Click on “Transaction Log Shipping”, provide same settings for “Network path to backup folder” and Change the backup job schedule same as what was provided for log shipping settings in AlwaysOn primary JBSAG1.

-> Make sure it is blank for “Secondary server instances and databases:”. Click OK.

-> With this log shipping setup is complete. Below are the jobs that are created after the Log shipping setup,

-> You can try failover and failback to see if everything works fine. All these jobs can run on respective SQL Server instances irrespective of which SQL Server instance JBSAG1, JBSAG2 or JBSAG3 is Alwayson primary. There is no requirement to change any of these jobs to run on AlwaysOn primary only.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.