I did a fresh install of Maxscale, and I was trying to set up a Read-Write-Split service on a master-slave mariadb cluster.
When I was trying to connect with DataGrip or DBeaver, I got the following error message:
[HY000][1927] Capability mismatch (bdd-master)
But when I use the mysql command line client, it works well.
Do you have any idea of what could be wrong?
MaxScale sends a Capability mismatch error when it detects that the client application requests a protocol capability that one of the backend databases cannot support. In general, this should not happen as MaxScale tries to mimic the backend database and calculates the capabilities so that these sort of mismatches do not happen.
There are some known bugs that can cause this, both in MaxScale as well as old versions of MariaDB and MySQL. Upgrading to the latest possible version of MaxScale should help solve any problems you might see.
Additionally, you should disable the query cache in the database if you are using MySQL as there is a bug in MySQL (and old MariaDB versions as well) that causes these sort of problems to appear.
It seems that is related to the router used (readwritesplit).
Datagrip send this command when it initiate the connection:
set autocommit=1, session_track_schema=1, sql_mode = concat(##sql_mode,',STRICT_TRANS_TABLES')
It seems that some of theses parameters are not supported by readwritesplit.
Related
What is the Best Practice for managing the GremlinClient object in C#? Is it better to create a SingleInstance (via Dependency Injection) or using Dispose on the object after each call or with a using
using (var client = new GremlinClient(...))
{
var results = client.SubmitAsync(query);
}
Since its a Sockets connection to the server, I assumed that reusing the client was the best practice, but I've been getting this error and I haven't been able to determine the root cause.
Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host.
The recommendation is to use just one GremlinClient object and to reuse that across your application because the client uses a connection pool so the same connection can be used again for different requests instead of having to create and tear down one connection for each request. The driver also supports request pipelining since version 3.4.0 which means that the same connection can be used for different requests in parallel which reduces the number of required connections. That can of course also only work if you reuse the client.
The problem you describe however could be caused by a bug in the Gremlin.Net driver. If you are using version 3.4.0 of Gremlin.Net, then it could be this bug that can lead to a huge number of created connections. In that case, you can avoid it by downgrading to a 3.3.5 until we release a fix with version 3.4.1. If you also see the problem in version 3.3.5, then please create an issue in TinkerPop's issue tracker to describe the problem.
There could of course also be another reason for the server to close the connection. That would need to be investigated in more depth to understand the reason, e.g., with a tool like Wireshark by inspecting the network traffic between the driver and Cosmos DB.
My setup is as the following:
MaxScale 2.1.4 -> Master -> 2 slaves (both MariaDB 10.2). *CentOS 7
Most of my queries are prepared statements so the master basically handles 90% of the queries right now.
I've enabled the hintfilter and tried to add a hint to a query:
/* maxscale route to server server2 */
Unfortunately, it still ends up on the master.
I understood that MaxScale 2.2 should introduce some auto solution for prepared statements. However, I need some temp solution(I'll try to look into ProxySQL if none is found).
Any help would be highly appreciated.
If you used the mysql command line client to test it, remember to enable SQL comments by using the -c flag.
Since MaxScale 2.0.1, the hint mechanism will override any decisions taken by the router itself if the router supports hints. The readwritesplit and schemarouter routers are currently the only routers that support routing hints so make sure you are using one of these routers.
When I connect to Titan via the Gremlin console it says... titangraph[cassandra:127.0.0.1]
Rexster however says... titangraph[cassandra:null] even though I can browse the same set of vertices.
Why is this? Rexster makes it look as though it hasn't managed to connect.
This message indicates that Cassandra did not start correctly.
Try starting Titan with the following:
titan.sh -c cassandra-es start
Have a look at /conf for additional configuration files.
Unless you really have to, I strongly suggest installing Titan 0.5.0 which comes with many useful features.
If you're starting with graph databases and Titan, I suggest trying with a single machine cluster or Berkeley DB as a storage backend. You may not need Cassandra yet.
You can also have a look at Titan/Aurelius official mailing list, I know the issue you're experiencing has been discussed there before: https://groups.google.com/forum/#!forum/aureliusgraphs. You can search for resources there (see, for example, https://groups.google.com/d/msg/aureliusgraphs/bviB6E5TZ-A/TJxQv0U7WQEJ).
In the meanwhile, you can try Titan v0.5.0 in Node.js by connecting via HTTP with https://github.com/gulthor/grex (HTTP client). The recommended way of connecting to Rexster is via HTTP (TinkerPop 2.x) or WebSocket (in upcoming TinkerPop 3, which Titan will support in a future version).
I am facing problem with Oracle 11g Express hosted on Linux Centos 6.4. This server is relocated from one place to another, this relocation changes the IP of server.
We have changed the IP in tnsname.ora and listerner.ora files. After these changes when we are trying to connect to database instance from server we are getting error “Connected to idle instance”. If we are trying it to connect from client using SQL developer we are getting error “Status : Failure -Test failed: Listener refused the connection with the following error: ORA-12505, TNS: listener does not currently know of SID given in connect descriptor”.
We have restarted this server and database multiple time (through option Start and Stop database under Oracle menu) multiple time, but still we are getting the same error.
Request you to please help to resolve this issue.
The local connection via sqlplus user/passwd (as opposed to sqlplus user/passwd#TNSALIAS) is not impacted by IP address or by contents of tnsnames.ora. It also does not require a listener at all, the listener could be stopped or not defined at all in listener.ora. In other words, you did something wrong here.
My guess is that you are mislead into thinking that you've started the database, when in fact it is not started. Check if you have a process called ora_MYORACLE_pmon.
Also the file tnsname.ora is irrelevant; Oracle only checks tnsnames.ora.
we resolved this issue, actually we were missing server address in some files it was still referring old address.
initXE.ora missing local listener parameter, then we added this parameter to it and it start working.
May be this is not the generalise solution but it work in our case.
This behavior is expected if the listener was originally configured with an ALTER SYSTEM command like ALTER SYSTEM SET LOCAL_LISTENER=''; and that command specified the SCOPE=MEMORY option or if the SCOPE is left to default and the database was started with a pfile.
To fix it, reissue all ALTER SYSTEM commands from before the restart. Or at least one that identifies the LOCAL_LISTENER. And set SCOPE=BOTH.
i'd like to use the mysql odbc driver for connecting to my mysql database via my own app.
the problem is that it seems very unstable - i keep getting errors like:
[MySQL][ODBC 5.1 Driver][mysqld-5.5.8]MySQL server has gone away
it seems to be something like a session timeout.
so here's my questions:
- what is causing those errors?
- is there a way to fix it for getting stable connections?
- is it recommended at all using it for coding windows software?
thanks
My guess is you're opening the connection once and leaving it open. At some point, the connection either times out, or some network hiccup is causing the connection to be invalid/closed. The best way to do database access is to open the connection when you need to do work, then close it. Or, alternatively, change your code to support re-connecting when you encounter an error.
Based on discussion in the comments below, I would suggest dumping the access database to a csv file, then using something like PHPMySql to import the data into MySQL.
You can use the BigDump tool to import large databases dumps into MySQL. (via this site)
There are commercial alternatives out there -
OpenLink Single-tier ODBC Driver for MySQL