Please enable JavaScript.
Coggle requires JavaScript to display documents.
2798478 - SyncStream Inquiry - Coggle Diagram
2798478 - SyncStream Inquiry
Issue
Satellite server processed inbound message from Master BUT satellite outbound message was not processed by Master
Essentially, the Master is at fault here... but they do not know why.
Sync Users
pvtsat_mgf
Affected Nodes
Satellite System
in France = MGF-SE-PVTSAT1
Master System
Frequency
1-2 times a week
Preliminary Customer Investigation
They found sync messages on the Master's webstore folder.
These messages are supposed to be replies to a resubmit request coming from the Master to the replica.
In the Satellite's SyncStream Database
They found a record on table resource with XptRecoveryState with StoModificationTime continuously updated. ~ every 10 secs
The timestamp of the StoModificationTime was always equal to the time where 512KB snyc messages when created.
At the same time as (2) above, a new entry was generated in the Satellite's pvttrace log file.
Customer waited for 36hours to confirm whether the resubmit request from Master was successfully processed by the Satellite as would be indicated by the Outbound Messages sent to the Master
Customer Configurations/Modifications
They tried to "unlock" the Sync queue. By manually updating the status of the ResourceRecord to "RecoveryDone" in the Satellite's SyncStream Database.
Then they saw that some records of the table resource automatically changed the status. First moving to RecoveryInProgress to RecoveryDone
They hinted that almost all messages of the "chunk".
"Chunk" here will mean that there is a larger message that was broken down to 512KB sync files. Hence, all split parts were most likely update (Going by the customer's narrative).
Thereafter, they performed Repair local sync on the Master's PAC via the Satellite's user.
This is for SyncStream to skip unrecoverable messages by a resubmit sent by satellite.
Inquiry
When a syncstream resource record has the XptRecoveryState field equal to RecoveryInProgress what does it means?
what could be the cause of a case of continously resubmit request that seem to never end?
Is it possible to understand which is the content of the syncstream resource record that was manually set to RecoveryDone?
Is this a correct way to unlock situation like this or are you aware of other procedure?