yugabyte cluster has 2 regions, 3 AZs, 6 node architecture.
4 nodes in central region,
2 nodes in east region
Node1 (Master, TServer) US-east
Node2 (Master, TServer) US-central-1
Node3 (TServer) US-central-1
Node4 (TServer) US-east
Node5 (Master, TServer) US-central-2 (Leader)
Node6 (TServer) US-central-2
Application is running in central region.
Application is using YCQL driver(yugabyte gocql client) that is currently configured to send SQL queries to Node2(only)
As mentioned here:
In many cases, this forwarding will be purely local, because both CQL and Redis Cluster clients are capable of sending requests to the right server and avoiding an additional network hop.
Is the above statement about CQL client referring to yugabyte gocql client? here it mentions: "The driver can route queries to nodes that hold data replicas based on partition key (preferring local DC)."
How can a client driver know, which tablet server to send the request?
if yes, does connection configuration of YCQL driver having connections with all 4 nodes(in central region), makes the client driver capable of knowing the correct tablet server, to send query? improving the query response time
if yes, Hoes YCQL driver know, which is the right tablet server to send query request(INSERT/UPDATE/SELECT)?
How can a client driver know, which tablet server to send the request?
The driver periodically queries this table:
ycqlsh:system> select * from system.partitions;
Where it finds how tables are split, and where the tablets are located.
When you send a query, you pass the partition-keys in a way the driver understands them and hashes them and knows where to send them.
if yes, does connection configuration of YCQL driver having connections with all 4 nodes(in central region), makes the client driver capable of knowing the correct tablet server, to send query? improving the query response time
Yes. This should be combined with DC Aware query routing: https://pkg.go.dev/github.com/gocql/gocql#hdr-Data_center_awareness_and_query_routing
if yes, Hoes YCQL driver know, which is the right tablet server to send query request(INSERT/UPDATE/SELECT)?
Using the same logic as above. Knowing the tablet locations on all the cluster.
Related
The "Real Time Metrics" panel of my MongoDB Atlas cluster, shows 36 connections, even though I terminated all server apps that were supposed to be connected to it. Currently nothing should be connected to it, but I still see those 36 connections. I tried pausing the cluster and then resuming it - the connections came back. Is there any way for me to find out where are they coming from? OR, terminating all connections.
Each connection is supposed to provide with it what is called "app metadata". This is supposed to always include:
The driver identifier (e.g. pymongo 1.2.3)
The platform of the client (e.g. linux amd64)
Additionally, you can provide your own information to be sent as part of client metadata which you can use to identify your application. See e.g. https://docs.mongodb.com/ruby-driver/master/tutorials/ruby-driver-create-client/ :app_name option.
Atlas has internal processes that connect to cluster nodes and cluster nodes communicate with each other also. All of these add to connection count seen on each node.
To figure out where connections are coming from:
Read the server logs (which you have to download first) to obtain the client metadata sent with each connection.
Hopefully this will provide enough clues to identify cluster to cluster connections. You should also be able to tell those by source IPs which you should be able to dig out of cluster configuration.
Atlas connections should be using either Go or Java drivers, if you don't use those in your own applications this would be an easy way of telling those apart.
Add app name to all of your application connections to eliminate those from the unknown ones.
There is no facility provided by MongoDB server to terminate connections from clients. You can kill operations and sessions but connections used for those operations would remain until the clients close them. When clients close connections depends on the particular driver used and connection pool settings, see e.g. https://docs.mongodb.com/ruby-driver/master/tutorials/ruby-driver-create-client/#connection-pooling.
Does anyone know of software that can redirect a TDS client request to an appropriate instance of Sql Server based on the database catalog that the client is attempting to connect to?
In other words, say I have 3 database catalogs (dbcat1, dbcat2, dbcat3) and they're all hosted on the same server (sqlServer). The client code would have connection strings like "server=sqlServer;database=dbcat1" and "server=sqlServer;database=dbcat2", for example.
I would like some sort of (reverse) proxy software that would allow me to move one or more database catalogs to different server instances, but allow the client configuration to remain unchanged. For example, I could put dbcat1 and dbcat3 on sqlA, and put dbcat2 on sqlB, and sqlServer would be the new proxy software. It would pass the connection through to the appropriate SqlServer instance based on its configuration, and the client would have no idea it wasn't talking directly to a SqlServer instance.
Does such a thing exist, or do I get the "joy" of having to write something if I really, really want it? And, yes, I know this is not HA (High Availability) or DR (Disaster Recovery).
SqlServer Failover Clustering does not do this; it's for HA. It redirects at the server instance level (guest clustering)
SqlServer Availability Groups does not do this; it's for DR. You still need to know the AG that hosts the database you want (if you move the dbcat to another AG, you have to update your client config).
Microsoft Proxy Server was replaced by ISA and likely didn't do it anyhow.
Microsoft ISA (Forefront) is just a "dumb" proxy as far as I could tell.
Trying with VoltDB cluster, created a cluster of 2 nodes with k=1
Cluster initialization was successful, both the nodes are up.
Now, how do i connect to this cluster, i could not find any documentation to setup single IP for cluster.
Will the client connect to particular node IP or cluster IP ?
I am using VoltDB community edition.
In general, you can connect to one node, or to multiple nodes. For simple usage, one node is fine. For a client application where you want lower latency and higher throughput, you should connect to all of the nodes in the cluster. See Connecting to the VoltDB Database for the java client, and in particular section 6.1.2 on using the auto-connecting client which enables you to connect to only one node and the client will automatically connect to all of the other nodes.
For command-line access, see the sqlcmd reference:
--servers=server-id[,...]
Specifies the network address of one or more nodes in the database cluster. By default, sqlcmd attempts to connect to a database on localhost.
Disclosure: I work at VoltDB.
If you wish to connect to a single node try
jdbc:voltdb://192.168.1.5:<port>
as the connection URL or if you wish to connect to cluster try
jdbc:voltdb://192.168.1.5:<port>,192.168.1.6:<port>,<any additional nodes you might have in your cluster>
as the connection url.
I have symmetricDS configured so that there is one master node in the cloud, and then two "store" (client) nodes in remote locations.
If I insert data in the cloud, it is syncd to both clients. If I insert data in a client, it is syncd to the cloud.
However, data added on client1 never makes it to client2 and data added on client2 never makes it to client1...
Any ideas on this?
Thanks
Yes you would want a second set of triggers (maybe prefix each with the name cloud_*) that has an additional flag turned on sym_trigger.sync_on_incoming_batch=1. This will cause changes coming in as part of replication from client 1..n to be captured and resent to all other clients.
This can be more efficient that a client to client group link solution because usually the clients do not all have access over a network to sync to each other. So the change would sync to the cloud and then be redistributed to the other clients.
I am trying to connect from my client (Win7-64 bit) to the DB2 server that runs also on a win7-64 bit machine.
I have 3 questions:
Does the DRDA protocol supports only SQL databases?
When connecting from my client to the server is it possible to connect to a different database at the same time with different streams(connections)?
When connecting to a server using the DRDA protocol, is it true that the first Client-To-Server command MUST be EXCSAT chained with ACCSEC?
When I searched with Google for this (I could only find information for Q3) I found that the EXCSAT must be the first command in a DDM connection, but what about other types of connection? and what this types of connection?
Yes; DRDA is only used for communicating with SQL databases.
If you're using ODBC or JDBC, you can have separate connections to separate databases with separate handles to identify which database you're talking to.
You should be able to find the specification for DRDA at The Open Group web site. I have 3 tome-sized PDF files (volume 1, the overview, is only 772 pages long; volume 2 FD:OCA is 114 pages; volume 3 DDM is 1168 pages).
The overview indicates (p51) that the client will send an EXCSAT to initiate a connection; it does not mention ACCSEC.
On p123, the diagram shows the EXCSAT message followed by an EXCSATRD from the AR, then the ACCSEC from the client, and an ACCSECRD response.
From this, I conclude that no, the ACCSEC does not have to be chained to an EXCSAT. I'm not even clear it has to be like that for a DDM connection.