• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 3 replies
  • Subscribers 9 subscribers
  • Views 105 views
  • Users 0 members are here
Options
Related

Autoreplicaton on tier-2 and methods to quickly populate tier-2 with tier-1 data

Trond Ruud
Offline

Autoreplicaton is automatically done on tags on tier-1. But is it also done on tags on tier-2 when they are replicated with "simple replication"? The implication being that retrieval on tier-2 for trending (BestFit) will be as fast as on tier-1?

Another question regarding setting up tier-2 for the first time; If a customer has a tier-1 Historian connected to System Platform and would like that data to be available in a new tier-2 Historian, would this install path be feasible:

1. Install tier-2 with runtime database and history blocks from tier-1. (TagName = TagA)

2. Set up replication from tier-1 to tier-2 (TagName = prefix.TagA)

3. Shut down tier-2 Historian

4. Tag rename (TagA -> prefix.TagA)

5. Start tier-2 Historian

This install would make the install and data available within hours instead of doing costly backfill operations that could take a while to complete. In theory, we should also have auto replication data available. I don't think that would be available with backfill at all.

Parents
  • +1

    Yes, auto-summary is also applied in the "tier 2" for replicated tags. However, to make it retroactive, you would have to use the backfill utility. 

    The general idea in your workflow above is valid, but the order is a little off. It would need to be:

    1. Install tier-2 with runtime database and history blocks from tier-1. (TagName = TagA)
    2. Shut down tier-2 Historian
    3. Tag rename (TagA -> prefix.TagA)
    4. Start tier-2 Historian
    5. Set up replication from tier-1 to tier-2 (TagName = prefix.TagA)

    The reason is that all the historical data is stored based on a TagId. When a source system (in this case, the "tier 1", but can also apply for a AppEngine, SDK app, etc.) first tries to create the destination tag , if it finds a matching (name, type, description, etc.) tag that already exists, it keeps it's existing TagId and uses that rather than creating a new TagId.

    One other note: the reason Replication has a "prefix" is to avoid name collisions when consolidating tags from multiple source systems. If the "tier 2" will only have replicated tags from a single source, you don't need to use the prefix and can skip a lot of the steps above.  

  • 0 Offline in reply to Elliott Middleton

    Thanks for the detailed reply.

    The order you described makes a lot of sense, and it is the order that we initially tried to use when renaming tags from System Platform. But some years ago we tried that order and it gave us trouble, so we ended up creating the new tags before renaming and we just stuck with this order because it worked out. I will have to try the new order.

    I guess the follow-up regarding the renaming is, if we rename TagA -> prefix.TagA, will this also take care of autoreplicated tags, or would we need to perform additional steps to get this working?

    The end result is that we want the same sub-second trend retrival on tier-2 that we already have on tier-1.

  • 0 in reply to Trond Ruud

    Yes, auto-summary "source tags" will be updated as part of the rename. 

Reply Children
No Data
© 2024 AVEVA Group plc and its subsidiaries. All Rights Reserved.