On Friday, May 15, 2020 at 12:36:42 PM UTC-7, Michael Scrivo wrote:
>
> Forgive me if this is the wrong place to ask, but was hoping to get some
> help on properly identifying queries going to our primary/replica DB in
> datadog's sequel integration.
> The reason I'm asking here first, rather than datadog is because I think
> it can be done and I have something working, but not sure if it's the
> correct or most efficient way of doing it.
>
> First off, to configure a database for tracking in DD, you call it like
> this:
>
> postgres_database =
> Sequel.connect('postgres://user:password@host:port/database_name')
>
> Datadog.configure(postgres_database, service_name: 'my-postgres-db')
>
>
> The problem is, we don't have separate database objects for our
> primary/replica. We have a single DB object specifying:
>
> servers[:replica] = {host: replica_host}
>
> to setup our replica and we use server(:replica) whenever we want to run a
> query against the replica.
>
> My rudimentary approach to getting this to work properly was to override
> synchronize like this:
>
> def synchronize(server=nil)
> # Setup databases in datadog so we know which one queries are being run on.
> if server == :replica
> Datadog.configure(DB, service_name: 'postgres/replica')
> else
> Datadog.configure(DB, service_name: 'postgres/primary')
> end
>
> begin
> @pool.hold(server || :default) do |conn|
> # some extra tracing ...
> yield conn
> end
> rescue => e
> # log error
> end
>
> raise e
> end
> end
>
>
> which seems like it does the right thing, but I have a suspicion that some
> queries which explicitly use server(:replica) are getting tracked against
> the primary, perhaps because of how the
> connection pool works and threading?
>
> Is there a more robust approach to what I'm doing above?
>
Not sure, but this seems to be a Datadog issue. It should be using an
approach that supports primary/replicas/sharding if it wants to correctly
account for connections to the different shards. Reconfiguring Datadog
everytime you check out a connection seems like it wouldn't be thread-safe
and even if it is it would be quite inefficient.
Unfortunately, having never used Datadog, having no idea what it does, and
having no idea how it is implemented, I can only guess at possible
approaches. Possibly it could be implemented as an extension that
overrides synchronize and calls super? That may allow it to determine the
shard, and synchronize allows it to get timing information. Alternatively,
it could hook into logging and log connection info, and that should work as
long as it maintains a map of connections to shards.
Thanks,
Jeremy
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sequel-talk/b75b3c32-838c-4387-bcd0-8bed24c8e4e3%40googlegroups.com.
