Salesforce

For Tridion Sites 9.1, how to rebuild the Discovery database?

« Go Back

Information

 
Article TypeSolution Article
Scope/EnvironmentSDL Tridion Sites 9.1
Symptoms/Context
- Customer has a corrupt Discovery database, and administrator has requirement to rebuild the Discovery database.  
- When the Discovery service is first installed and after running or stopping the service/the sync-ttmcdenvironment Powershell script is run/a hotfix is applied, there is a chance there is something in the database that can introduce GUI or presentation website errors. Refreshing data is the easiest and cleanest way to get the Discovery database restored.
Resolution
Administrative steps:
A. IF ROLES ARE SPECIFIED IN THE DISCOVERY CD_STORAGE_CONF.XML FILE
1. Stop all CD microservices, and remove or move existing logs.  Change log level to debug for the Discovery and Session/Content microservices.
2. As a precaution, take a backup of the Discovery database.
3. Purge (delete) all data in 3 tables: CONFIGURATION_VALUE, CONFIGURATION_ITEMS_LINKS, and CONFIGURATION_ITEM.
delete from CONFIGURATION_VALUE
delete from CONFIGURATION_ITEMS_LINKS
delete from CONFIGURATION_ITEM
Note if there are multiple environments, it is necessary to purge the data in the Discovery service database that those environments use.
4. Restart the Discovery service(s) and other microservices, and wait until the Discovery service is fully initialized and running.
5. Run a select statement on the three Discovery tables.  When running a select statement on these tables, new rows should be returned.
select count(*) from CONFIGURATION_VALUE
select count(*) from CONFIGURATION_ITEMS_LINKS
select count(*) from CONFIGURATION_ITEM
6. Drop out to the command prompt as administrator and navigate to the config folder of the Discovery service.  Run the below
java –jar discovery-registration.jar update
    Output should be something like
...
2021-08-17 11:01:33,882 INFO  [main] Main - Result of tool execution is:
Created or Updated Capabilities:
{
  "id" : "DefaultTokenService",
  "lastUpdateTime" : 1629223293023,
  "uri" : "http://localhost:8082/token.svc"
}
{
  "id" : "DefaultWeb",
  "lastUpdateTime" : 1629223293211
}
{
  "id" : "DefaultContextService",
  "lastUpdateTime" : 1629223293336,
  "uri" : "http://localhost:8087/context.svc"
}
{
  "id" : "DefaultContentService",
  "lastUpdateTime" : 1629223293460,
  "uri" : "http://localhost:8081/content.svc"
}
{
  "id" : "DefaultDeployer",
  "lastUpdateTime" : 1629223293570,
  "strategy" : "DEFAULT",
  "uri" : "http://localhost:8084/httpupload",
  "extensionProperties" : [ "java.util.ArrayList", [ {
    "key" : "encoding",
    "value" : "UTF-8"
  } ] ]
}
{
  "id" : "DefaultPreviewWebService",
  "lastUpdateTime" : 1629223293757,
  "uri" : "http://localhost:8083/ws/preview.svc"
}
{
  "id" : "DefaultContextualImageDelivery",
  "lastUpdateTime" : 1629223293835,
  "uri" : "http://localhost:8088/cid"
}
7. Verify that this step completes successfully and does not result in an error. Do the same steps on other environments if needed.
8. When running the select statement, administrator should then see there are more rows appearing in the Discovery database tables.
9. On Content Manager server, drop out to Powershell as an administrator and run the below.  The Timeout param may be needed if the execution time exceeds the default of 5 minutes.
Sync-TtmCdEnvironment -Id <Id of environment(s)> -Timeout 200000 -Verbose
10. Repeat the sync-ttmcdenvironment cmdlet for other environments if needed.
11. Ensure the previous step also completes and does not result in an error. If an error occurs, try to resolve it.
12. If no errors are encountered, the administrator has successfully refreshed the Discovery database.
13. Test publishing and GUI activities to confirm there are no error(s) related to the Discovery service.
14. To refresh the Topology Manager, restart these services:
- SDL Web Content Manager Service Host service
- Application Pool for SDL Web and SDL Topology Manager website

If the administrator sees error such as below, run "java -jar discovery-registration.jar update" again and retest publishing.
Transport service failed to transport. <Summary state="Failed" referenceId="tcm:0-1044-66560"><Error>
Unable to read transport instructions.Deployer capability not specified in: http://HOSTNAME:PORT_NUMBER/discovery.svc</Error><Processing>
<Context topic="Content Delivery"><IsRollbackOnFailure /></Context></Processing><Target /></Summary>
Component: Tridion.ContentManager.Publishing
Errorcode: 854
User: NT AUTHORITY\SYSTEM
StackTrace Information Details:
at Tridion.ContentManager.Publishing.Handling.DefaultPublishTransactionHandler.SendTransportPackage(TransportPackage package)
at Tridion.ContentManager.Publishing.Handling.DefaultPublishTransactionHandler.HandlePublishRequest(PublishTransaction publishTransaction)
at Tridion.ContentManager.Publishing.Handling.DefaultPublishTransactionHandler.ProcessPublishTransaction(PublishTransaction publishTransaction)
at Tridion.ContentManager.Publishing.Publisher.QueueMessageHandler.HandleMessage()
B. IF ROLES ARE NOT SPECIFIED IN THE DISCOVERY CD_STORAGE_CONF.XML FILE
In some environments, the microservice roles are not specified in the Discovery cd_storage_conf.xml file as in below example
<ConfigRepository CacheEnabled="${configcacheenabled:-true}" CacheExpirationDuration="600" ClientId="registration" 
ClientSecret="${registrationpassword:-encrypted:}" ConnectionTimeout="10000" ServiceMonitorPollDuration="${servicemonitorpollduration:-10}" 
ServiceUri="https://HOSTNAME:8082/discovery.svc" TokenServiceUrl="https://HOSTNAME:8082/token.svc">
<Roles />
</ConfigRepository>
In this case, it is not possible to update the Discovery database with the discovery-registration jar file and sync-ttmcdenvironment commands as described in prior section.  Using these utilities requires that the roles are specified in the Discovery cd_storage_conf.xml file.

Instead, the roles can be added to the Discovery database by using the "--auto-register" flag with the start.ps1 PS script for each of the missing roles.  If the missing roles are Deployer, Session Content, and Preview, then register each of these roles by:
1. Open a Powershell prompt with administrative privileges and navigate to the microservice bin folder (for example Deployer)
2. Stop the existing Deployer service from Service panel.
3. Verify the microservice port from .\installService.ps1
4. Run the start.ps1 script with syntax like
& .\start.ps1 --auto-register --server.port=8184
5. Even if the microservice has started successfully, the status may not display correctly in the Services panel.  Instead, verify the startup was successful from logs or browsing to the endpoint.
6. From the Discovery bin folder, run "java -jar discovery-registration.jar read" to verify that the role(s) have been added successfully to the Discovery database.
7. It may be necessary to restart the Service Host service before the roles appear in the Topology Management flyout of the CME as in below screenshot.
User-added image
 
Root Cause
Reference
See attached PDF for original document and screenshots (the PDF does not have section B of this article)
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by