none
Can I remove some unused replica information from column scope_sync_knowledge in table scope_info RRS feed

  • Question

  • Dear,

    I do the test as below steps:

    1. Server side (sql version is sqlserver2008r2) : Create a scope named "scope1" and provide a WCF service for client to sync
    2. Client side(sql version is SqlExpress2005): Create new database
    3. Client: Get the scope description of "scope1" from server side to initialize the scope on client
    4. Client: sync data

    when I repeat the steps 2-4 many times, the scope_sync_knowledge field in table scope_info on server side  becomes huge, I know this is because the new client has new replica id and the knowledge is fresh to server, so the server stores the new knowledge in scope_sync_knowledge field. But actually the old  replicas will never be used any more, so can I have some way to remove them to reduce the size of scope_sync_knowledge field on server?

    Thanks.

    Monday, May 27, 2013 4:58 AM

Answers

  • afaik, there's nothing exposed in the API that would allow you to remove entries for a specific replica.

    for multiple clients synching against a server, i normally keep separate scopes in the server side for each client (assuming you dont do peer to peer syncs between clients). for one, it keeps the sync knowledge smaller and less fragmented, second, if you remove a client, it's easy to remove its corresponding scope. 

    i has similar scenario as yours before and this is how i did the scopes:

    Prod Server

    Scope_Template1

    ProdServer_Client1Scope (based on the template above)

    ProdServer_Client2Scope (based on the template above)

    etc...

    QA Server

    QAServer_Client1Scope (based on the template above or you can have a new scope template in QA)

    QAServer_Client2Scope (based on the template above)

    etc...

    Client

    ProdServer_Client1Scope (based on the corresponding template above)

    QAServer_Client1Scope (based on the corresponding template above)

    seems to be a lot of work, but worth the isolation of each client from one another. just have to watch out for sync loops. if you know your way hacking around the scope definition, you can even alter a scope definition for a specific client and upgrade them one at a time...

    • Marked as answer by bao_bao Monday, May 27, 2013 10:55 AM
    Monday, May 27, 2013 9:43 AM
    Moderator

All replies

  • can you expound on "old replicas will never be used anymore"?

    so you're only synching one time?

    then why not just create one scope on the server for every client and then deprovision it?

    Monday, May 27, 2013 5:24 AM
    Moderator
  • Hi JuneT,

    Thanks for your reply first.

    The real case in my project is:

    1. we have 2 server machines, the first one is used for QA to test, the second one is used for production
    2. we defined 1 scopetemplete which sync only one table on each server.
    3. we have 10 users to run the client application, each user has his own scope populated from the scopetemplate. (the scope is identified by userId not clientMachineId)

    Many times, I use a new DB to sync data to the first server(QA) to test other functionalities of our App, and the sync process is automatically executed when we run our app. In this way the replica information accumulated on server side  knowledge.

    Recently, I found all the other users can sync successfully except me.

    So I compared the difference with  other users. to found:

    1. my scope's scope_sync_knowledge field is much bigger than others.(that's why I asked to reduce the size of this field)
    2. sometimes, I sync with QA server, then sync with Prod server immediately only by changing the URL to  the Prod server directly(the scopetemplates on both servers have the same setting, same name, same table schema,...).
    Monday, May 27, 2013 8:10 AM
  • afaik, there's nothing exposed in the API that would allow you to remove entries for a specific replica.

    for multiple clients synching against a server, i normally keep separate scopes in the server side for each client (assuming you dont do peer to peer syncs between clients). for one, it keeps the sync knowledge smaller and less fragmented, second, if you remove a client, it's easy to remove its corresponding scope. 

    i has similar scenario as yours before and this is how i did the scopes:

    Prod Server

    Scope_Template1

    ProdServer_Client1Scope (based on the template above)

    ProdServer_Client2Scope (based on the template above)

    etc...

    QA Server

    QAServer_Client1Scope (based on the template above or you can have a new scope template in QA)

    QAServer_Client2Scope (based on the template above)

    etc...

    Client

    ProdServer_Client1Scope (based on the corresponding template above)

    QAServer_Client1Scope (based on the corresponding template above)

    seems to be a lot of work, but worth the isolation of each client from one another. just have to watch out for sync loops. if you know your way hacking around the scope definition, you can even alter a scope definition for a specific client and upgrade them one at a time...

    • Marked as answer by bao_bao Monday, May 27, 2013 10:55 AM
    Monday, May 27, 2013 9:43 AM
    Moderator
  • Thank you JuneT for your solution.

    I am not very clear about how to get the ReplicaId and where to store it for a peer. In database sync scope, the replicaId is the scope_id in scope_info table, is it right?

    Also the "metadata" in database sync means the data in table XXX_tracking?

    Tuesday, May 28, 2013 1:51 AM
  • yes, it's the scope_id. but inside the scope_sync_knowledge and scope_tombstone_cleanup_knowledge columns, there is replica key map that maps the GUID scope_id to an integer rather than using the GUID repeatedly.

    yes, metadata refers to the sync tables...

    Tuesday, May 28, 2013 2:56 AM
    Moderator
  • Very happy to get it. :)

    So as you mentioned, the integer mapped to GUID scope_id is the peer_key, like the scope_update_peer_key in table scope_info?

    Tuesday, May 28, 2013 5:20 AM