I have a 3 node innodb cluster setup. On each server I also have a mysql router. I bootstrapped 1 of the routers. Started all 3 routers using the same conf that was created during the bootstrap. I am seeing the following warning in the mysql router logs.
2111: decoding connection attributes failed [ignored]: (input too short)
My first thought was that I should have bootstrapped each mysql router and created their own config. Not sure if that is right way to do it? Also, has anyone else seen this warning before? Is it harmless or should I be worried?
running mysql server 8.0.29 and mysql router 8.0.29
UPDATE I was able to isolate the connection. The problem connection is coming from Grafana. I reviewed the connection string there, but everything looks correct.
TIA
I had similar problem, and I figured out that in version 8.0.23 there was added router<->client TLS endpoint support and also changed client_ssl_mode default behaviour.
The default behavior changed from client_ssl_mode = PASSTHROUGH to
client_ssl_mode = PREFERRED where PASSTHROUGH forwards everything to
the server and lets the client and server decide TLS settings, whereas
PREFERRED establishes TLS connections between the client and Router if
the client desires switching to TLS if the server supports TLS. This
also matches the existing behavior for client and server without the
Router in-between.
https://dev.mysql.com/doc/relnotes/mysql-router/en/news-8-0-23.html
Bootstrap process now adds these options to config file:
client_ssl_cert
client_ssl_key
client_ssl_mode
example: https://dev.mysql.com/doc/mysql-router/8.0/en/mysql-router-configuration-file-example.html
commenting them out should hotfix your problem.
Please review available configuration options and decide which TLS configuration suits best for your case.
https://dev.mysql.com/doc/mysql-router/8.0/en/mysql-router-configuration-tls.html
Related
This is the pymysql code I am using to connect to the database. I am testing with an AWS RDS Mysql instance with Mysql verison 5.7.22. I am getting the certificate from https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html
pymysql.connect(secret_dict['host'], user=secret_dict['username'],
passwd=secret_dict['password'], port=port, db=dbname,
connect_timeout=5, ssl={'ca': './rds-combined-ca-bundle.pem'})
This code works with my test database with the user with ssl enabled and the user wo ssl enabled. - (Via ALTER USER 'encrypted_user'#'%' REQUIRE SSL; )
My question is is this pymysql behavior that I am seeing true of any MySQL verison database or documented anywhere? The behavior I am referring to is that if you add the ssl option to the connect call, it should work (successful connection) regardless or not the actual user has SSL required on it. I prefer not to test with every Mysql version :)
From taking a look at the pymysql code, what it seems to do is check if there are any ssl parameters associated with the request, adds it to an ssl map, and then creates a ctx_object from that ssl map and uses that ctx_ object when initializing a socket with the database.
Just found this on the Mysql 7 documentation guide
"On the server side, the --ssl option specifies that the server permits but does not require encrypted connections. This option is enabled by default, so it need not be specified explicitly."
"By default, MySQL client programs attempt to establish an encrypted connection if the server supports encrypted connections, with further control available through the --ssl-mode option:"
"In the absence of an --ssl-mode option, clients attempt to connect using encryption, falling back to an unencrypted connection if an encrypted connection cannot be established. This is also the behavior with an explicit --ssl-mode=PREFERRED option."
"PREFERRED: Establish an encrypted connection if the server supports encrypted connections, falling back to an unencrypted connection if an encrypted connection cannot be established. This is the default if --ssl-mode is not specified."
So I believe what's happening is that pymysql doesn't specify the ssl-mode option so the ssl client side mode being used is PREFERRED which means that the client(pymysql) will try to establish an ssl connection(which I think fails because the user doesn't require it) and then fallback to the unencrypted connection which will be successful.
Right now I am connecting to a cluster endpoint that I have set up for an Aurora DB-MySQL compatible cluster, and after I do a "failover" from the AWS console, my web application is unable to properly connect to the DB that should be writable.
My setup is like this:
Java Web App (tomcat8) with HikariCP as the connection pool, with ConnecterJ as the driver for MySQL. I am evaluating Aurora-MySQL to see if it will satisfy some of the needs the application has. The web app sits in an EC2 instance that is in the same VPC and SG as the Aurora-MySQL cluster. I am connecting through the cluster endpoint to get to the database.
After a failover, I would expect HikariCP to break connections (it does), and then attempt to reconnect (it does), however, the application must be connecting to the wrong server, because anytime a write is hit to the database, a SQL Exception is thrown that says:
The MySQL server is running with the --read-only option so it cannot execute this statement
What is the solution here? Should I rework my code to flush DNS after all connections go down, or after I start receiving this error, and then try to re-initiate connections after that? That doesn't seem right...
I don't know why I keep asking questions if I just answer them (I should really be more patient), but here's an answer in case anyone stumbles upon this in a Google search:
RDS uses DNS changes when working with the cluster endpoint to make it looks "seamless". Since the IP behind the hostname can change, if there is any sort of caching going on, then you can see pretty quickly how a change won't be reflected. Here's a page from AWS' docs that go into it a bit more: https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html
To resolve my issue, I went into the jvm's security file and then changed it to be 0 just to verify if what was happening was correct. Seems correct. Now I just need to figure out how to do it properly...
I use WampServer (Apache, PHP, MySQL) and have no problems when some kind of network adapter(wireless or lan) is connected (i.e. Local Area Connection has status connected) even if i am not connected to the internet (for example when i am connected to the router but that is not connected to the internet).
When there is no network connection, I get a php error like MySQL could not connect to 127.0.0.1 on port 3306.
Interestingly, telnet 127.0.0.1 3306 says that it could not connect to the port, even when the server and MySQL are running fine (i.e. when some kind of local area connection is connected).
So I turned off all kinds of firewall (antivirus and Windows) but still no difference in anything. And that is why this issue is quite puzzling.
Things I have already tried (will update this list along the way):
The skip-networking directive in my.ini.
You could modify your MySQL server and client configuration to connect to one another using a named pipe instead of a TCP/IP loopback connection. That way, the current state of the network connection should have less impact.
To do so, start the server with --enable-named-pipe or the corresponding config file setting, and execute the client with --pipe or --protocol=PIPE. Similar configurations should be available for your PHP connector as well. It may depend on which library you use there, and whether or not it will take the mentioned configuration settings from the my.ini file (settings without leading -- there).
I have successfully setup my MySQL server to support SSL connections I'm just wondering if I need to copy client certs to each other server I want to connect to it OR if I can get away with just specifying:
[client]
ssl-cipher = DHE-RSA-AES256-SHA:AES128-SHA
All I need to do is encrypt the traffic between servers (sitting in EC2) and the MySQL server elsewhere, so I don't think I need to send certs out left, right and centre... Or am I wrong?
If I can get away with doing this, what are the implications of not going the whole hog and specifying the client certs too? Is there any reasonable real-world risk to NOT specifying a full set of client certs to the mysql client program?
It appears that specification of JUST the ssl-cipher option is enough to secure the connection between a client and an SSL enabled MySQL Server (If anyone else out there knows any different please let me know).
Tests using TCPdump to monitor traffic show clear text commands being sent as expected when a user not requiring SSL connects to the server, but once the server is setup to accept SSL connections, if you connect with a user that requires SSL specifiying only ssl-cipher these plain text commands are encrypted within the packets i.e. they can't be seen.
I've got a trio of Windows servers (data1, data2 and datawitness) that aren't part of any domain and don't use AD. I'm trying to set up mirroring based on the instructions at http://alan328.com/SQL2005_Database_Mirroring_Tutorial.aspx. I've had success right up until the final set of instructions where I tell data1 to use datawitness as the witness server. That step fails with the following message:
alter database MyDatabase set witness = 'TCP://datawitness.somedomain.com:7024'
The ALTER DATABASE command could not be sent to the remote server instance 'TCP://datawitness.somedomain.com:7024'. The database mirroring configuration was not changed. Verify that the server is connected, and try again.
I've tested both port 7024 as well as 1433 using telnet and both servers can indeed connect with each other. I'm also able to add a connection to the witness server from SQL Server Manager on the primary server. I've used the Configuration Manager on both servers to enabled Named Pipes and verify that IP traffic is enabled and using port 1433 by default.
What else could it be? Do I need any additional ports open for this to work? (The firewall rules are very restrictive, but I know traffic on the previously mentioned ports is explicitly allowed)
Caveats that are worth mentioning here:
Each server is in a different network segment
The servers don't use AD and aren't part of a domain
There is no DNS server configured for these servers, so I'm using the HOSTS file to map domain names to IP addresses (verified using telnet, ping, etc).
The firewall rules are very restrictive and I don't have direct access to tweak them, though I can call in a change if needed
Data1 and Data2 are using SQL Server 2008, Datawitness is using SQL Express 2005. All of them use the default instance (i.e. none of them are named instances)
After combing through blogs and KB articles and forum posts and reinstalling and reconfiguring and rebooting and profiling, etc, etc, etc, I finally found the key to the puzzle - an entry in the event log on the witness server reported this error:
Database mirroring connection error 2 'DNS lookup failed with error: '11001(No such host is known.)'.' for 'TCP://ABC-WEB01:7024'.
I had used a hosts file to map mock domain names for all three servers in the form of datax.mydomain.com. However, it is now apparent that the witness was trying to comunicate back using the name of the primary server, which I did not have a hosts entry for. Simply adding another entry for ABC-WEB01 pointing to the primary web server did the trick. No errors and the mirroring is finally complete.
Hope this saves someone else a billion hours.
I'd like to add one more sub answer to this specific question, as my comment on Chris' answer shows, my mirror was showing up as disconnected (to the witness) Apperently you need to reboot (or in my case i just restarded the service) the witness server.
As soon as i did this the mirror showed the Witness connection as Connected!
See: http://www.bigresource.com/Tracker/Track-ms_sql-cBsxsUSH/