This is a public Idea Center  publicRSS

Idea

    2 liked this

    [Delivered] Know when the replication database is behind
    Idea posted August 12, 2014 by Ineke ClewerSpecialist, last edited June 9, 2016 by KeriInnovator, tagged Outreach/Marketing Campaigns, System Admin and Configuration 
    135 Views, 3 Comments
    Title:
    [Delivered] Know when the replication database is behind
    User Story / Description:

    A few weeks ago we had a problem where we couldn't send mailings because the replication database was behind.

    We wanted to send our emails out over lunchtime, but because of the system delay the email went around 3 or 4pm, which was not when we wanted it to go, and we had no control to wait and send it out in the evening, once we hit send it just waited for the delay to be over and sent.

    Therefore it would be really helpful if it was possible to look up whether or not the replication database was out of sync so that we could choose to wait to send a mailing and not have it go out when we don't want it to.

    Answer  542 was quoted in reference in the RN support incident we raised, http://cx.rightnow.com/app/answers/detail/a_id/542  

    RN Support suggested that I raise this in the idea lab, so here's me doing that!

    Comment

     

    • Ineke Clewer

      (Also, is this the same as the reporting/operational database?)

    • Keri

      Hello Ineke,
      Wanted to provide you with an update on this Idea. We have been working on a plan to completely eliminate the reliance on the replication server for the audience calculation. So when we do end up delivering this, you won't need to consider whether replication is behind - rather we will use a smarter, load-sensitive method of pulling together the audience in a more scalable way, direct from the production site.

      Will keep you apprised of our changes!
      All the best,
      Keri

    • Keri

      Hello all!
      I'm happy to provide a status of Delivered on this Idea. In the May 2016 release, we have officially changed the way Outreach and Feedback calculate the audience, most notably on the broadcast mailings from these product areas.

      As most of you know, in previous versions, the audience calculation (the first part that occurs when you hit 'send' on any broadcast mailing) would use the replication server to query and create the list for the mailing. Looking at the history of mailing calculations, using replication was the recommended solution years ago for this type of query. However, when replication was behind, we just sat and waited.

      As Ineke kindly pointed out - there was no way for you, the customers, to understand if your site replication was "behind" in any way. And moreover, if replication was behind at all (even by a millisecond!), we stopped the query and waited for replication to catch up. We also understood that, even though using replication was the recommendation, these mailings were also the ONLY part of the product that COMPLETELY halted when replication was behind. Depending on the source of your replication server slowdown, this halt in our query meant that your mailing wouldn't send for minutes, hours, or even several days! Ultimately, your time-sensitive messages were not sent in a timely manner, and most likely it wasn't anything you could really control from your admin point-of-view.

      So.....Fast-forward (and get upgraded) to the May 2016 release!

      Without requiring any changes on your side (except upgrade cutover), we have changed how the audience generation is done from the server side of things. In the new release, we will be creating the audience in batches from your production environment - completely removing the replication database connection, and making your lives easier. 

      Now, I just heard several of you say out loud "but this will impact my production database and slow my agents down!" Not true! The new algorithm will actually divide the total audience query into smaller sub-queries, and run through each sub-query until the full audience list is generated. This means we are requesting smaller bites from the server, but aggregating each bite into the whole of the audience. Same way you'd eat a very large dinner! One bite at a time! (Except I always wish that it didn't contain calories!!) 

      You also gain efficiency with this new algorithm. While testing this new capability for performance and scalability, a very large query actually ran faster using the new algorithm (with smaller, multiple queries), than it did to return the same size single query from replication as per prior releases.

      This smarter, load-sensitive, production-direct algorithm applies when sending any broadcast or recurring broadcast mailing, as well as running the count option in the mailing (not yet sending), and when counting individual segments or contact lists. To ensure there is no major disruption to your agents or impact to other site performance, we added a limit to run five of these queries (counts or mailing sends) simultaneously, and will queue additional counts or send requests until a free space is available. 

      Have I convinced you to upgrade yet? #OSvCforTheWin #IdeasRock #KeepEmComin #Winning! wink

      Please reply if you have any questions on this update!
      Keri