Description: In 9.6 Rollup technology changed to SQL Replication. There are many questions about this change as well as information about how it works and is utilized by LANDesk. This guide is designed to explain in detail how it works and to assist with troubleshooting and installation. This guide will reference other articles to keep from duplicating information.
Installation: It is recommended to follow this guide specifically. As of 9.6 SP2 domain users should now be available for use in SQL Cluster environments.
Troubleshooting and Common Issues: Below is a list of guides and other articles that will assist with problems.
- Great guide for troubleshooting SQL Replication
- Finding scripts used in replication
- Known Issues and Errors:
- A specific user (ldms_distribution, ldms_logreader, etc) reports as incorrect even though the correct password is entered.
- Ensure users are configured according to documentation. However, in some cases the credentials may not be set or match correctly. In SQL Server Management Studio under the root Security there is a Credentials folder. In the folder you will see all of the users configured in replication. Right-click the affected user and select properties to manually update the credentials in SQL. Note: Credentials are stored for each server involved in replication so be sure to set the correct user.
- General Note: Upgrading a core that is also a publisher will stop the replication process and require it to be restarted with the landesk.database.replication.exe application.
- How SQL Replication Works:
- SQL Server Replication Step-by-step (Note: this is a 3rd party website)
- Transactional Replication
- How Transactional Replication Works (Microsoft website)
- General Error: When viewing the job history for a subscriber the following message is displayed: "The subscription(s) have been marked inactive and must be reinitialized. NoSync subscriptions will need to be dropped and recreated"
- Cause: This message happens when an error occurs. The error is retried for a period of time before SQL Server marks the connection as inactive. The underlying error needs to be corrected but to see the error you may need to reinitialize the affected subscriber.
- Resolution: To reinitialize the subscriber right-click on the affected database/core under the Publisher folder on the Publisher server and select "Reinitialize All Subscriptions". Then click the button "Mark for Reinitialization". After that it may be necessary to right-click "View Snapshot Agent Status" and click the Start button. A lot of these actions can take some time as well so an immediate change may not show up.
- Note: A failure message may appear that talks about how a process may already be running. Ignore this message and wait. The process should eventually start replicating.
Common Questions:
- What type of SQL Replication is used in 9.6 and onward?
- Answer: Both Snapshot and Transactional. Snapshot replication is used initially when setting up replication to copy over the large amount of data. After the initial bulk copy snapshot replication is then switched to transactional where the logs are watched every 30 seconds which is the default. Changes on child cores should then reflect on the rollup within 30 seconds (performance issues aside)
- Is SQL Server Express supported?
- No. Also all servers must be using the same database type.
- Is the entire database replicated or only specific tables?
- The entire database is replicated including Unmodeled or Custom Data. This is different from the previous rollup configuration.
- Can you rollup a 9.5 core/database?
- Yes. However, replication will drop the schema to the lowest child core (publisher) in the configuration. This may lead to some data loss.
- Is the solution validated from LANDesk with gathering information from geographically disperse locations?
- Yes. However, slow connections etc. may require some changes to replication. See the troubleshooting information above.
- How often is replication from the publisher to subscriber happening?
- The subscriber checks the distributor every 30 seconds. Example: If a machine is added to a child core (publisher) they should show up on the rollup within 30 seconds. (Excluding performance issues)
- Are unique tables being created for each publisher in the subscriber (rollup) database?
- Yes. Some unique tables are created however overall each core has a GUID which is then added to entries in the subscriber and distinguishes them from other publishers (child cores). As noted below in the design section MAP tables are also created that keep track of the source and destination keys for each table.
- What type of network latency is required and what is acceptable?
- This technology belongs to Microsoft's so acceptable levels of latency is restricted to SQL Server. Several adjustments can be made to databases with latency issues. See troubleshooting guides above.
- What is the recommended frequency of replication? The default settings (30 seconds) is the recommended configuration. If transactions start to fall behind then the setting can be increased according to Microsoft recommendations.
- Can SQL Servers reside on the same server?
- Yes.
In-Depth Overview of the Design: This section will provide a general overview of the technology to better understand the process and help with troubleshooting. Customizations of any of this is not supported. Note: This is not a completed detailed outline of the process.
Definitions:
- Publisher - Client core/database
- Distributor - An intermediary database used in the caching of transactions between publisher and subscriber.
- The actual database is located in System Databases and called "ldmsdistribution"
- Subscriber - Rollup core/database
- CoreGUID - The unique ID associated with a core. You can find this in the MetaSystems Table in the publisher (client database) and subscriber (rollup database) under the SystemGUID. This ID is tied to records throughout the database to map data for a specific core.
General Flow: After OK is clicked in the Replication Utility (LANDesk.Database.Replication.exe located in C:\Program Files\LANDesk\ManagementSuite on the Rollup) Note: These are just some of the steps executed and not a detailed list of actions.
Database views and scripts are created in each client database: Example screen shot below
Script and core information is stored in "sysarticles" (Example: SELECT * FROM sysarticles)
Data and scripts are stored in the configured replication folder (usually called repldata and configured during installation). This is done during the initial snapshot phase of the process.
Note: These files and path should be created automatically for each publisher. If they fail to appear then usually permission issues on the share is to blame.
- Snapshot Agent establishes a connection from distributor to publisher and generates a fresh snapshot into the snapshot folder by placing locks
- Snapshot Agent writes a copy of the table schema for each article to .sch file
- Data is copied from the published table and written to the snapshot folder in the form of a .bcp file.
After the initial snapshot the log reader agent takes over and transactional replication begins
Additional Information about tables in the Subscriber (rollup)
Depending on the table in question some additional tables may be created on the rollup (subscriber). The purpose of these tables is to correctly route duplicates and correct data as needed. An example is below. In the example below data is inserted into the ProductSnapShot table. A trigger on the table then inserts data into both the Product and replProductMap tables. The replProductMap table (like other map tables) contains the source ID (the view idn from the subscriber (child core) and the destination ID (the rollup core table idn).
