I am able to connect normal AWS RDS MySQL instance (5.7.16). But, as I have to use MySQL as document store, I have configured MySQL instance by installing mysqlx plugin, Which is required for document store.
After this, I am trying to connect MySQL document store on port 33060 on same instance but unable to connect. I am using lambda for connection which imports xdevapi (#mysql/xdevapi) package and tries to connect with MySQL RDS instance on port 33060.
But, there is no error which I can see for, therefore I am just wondering does AWS RDS has support for MySQL document store.
Code:
xdevapi.getSession({
host: process.env.HOSTNAME,
port: process.env.PORT,
dbUser: process.env.DB_USER,
dbPassword: process.env.DB_PASSWORD
}).then(function (session) {
console.log("Connected");
session.close();
return callback(null, {'responsne':'connected', statusCode: 200});
}).catch(function (err) {
console.log(err.stack);
return callback(null, {'responsne':err.stack, statusCode: 400});
});
Kindly, help me out to find this.
Since MySQL 8.0.11 is now generally available on AWS, we've been looking at the Document Store functionality via x-plugin.
Following through the sample DB (https://dev.mysql.com/doc/refman/8.0/en/mysql-shell-tutorial-javascript-download.html) it creates the schema and imports it OK, but doesn't seem to expose the db object to mysqlsh.
For example, when I run
\use world_x
connected to a local host instance it outputs
Default schema set to `world_x`.
Fetching table and column names from `world_x` for auto-completion... Press ^C to stop.
whereas when connected to an RDS instance I only get
Default schema set to `world_x`.
Additionally, according to https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.VersionMgmt the X Plugin isn't supported which, as I understand it, means Document Store functionality isn't supported.
Pretty late answer, but hopefully it might help to clarify similar questions in the future. Since apparently RDS is running MySQL 5.7.16, it should not load the X Plugin (which enables the Document Store) by default.
Unless you are able to provide mysqld startup options (in this case --plugin-load=mysqlx=mysql.so) or have client access, in which case you can follow the steps described here to enable the plugin, you are out of luck.
There's also the possibility that RDS is running some kind of fork, which does not even bundle the X Plugin.
Also, the X DevAPI connector for Node.js only guarantees support for MySQL 8.0, so, although you should be able to use it with later MySQL 5.7 versions, there are a few limitations.
Related
A development version of a react/node app is in a gcp project. This project was created by someone else who left so I have limited understanding. I need to get this app ready for production.
I took the code and copied this app over to a new project which will be used for production. Inside the server.js file I changed the host, password, and database to match the database in the new project I created.
When the do npm run build inside client and do gcloud app deploy api/app.yaml and client/app.yaml the deployed app still references the original database from the development app despite specifying new host,password, and database.
I'm guessing the problem is I originally deployed it using the dev database options, and when I switch to the prod database options, it fails to connect and reverts to the previous connection.
If this is true, how can I see what is causing this connection failure? Is there other settings I need to set in the database to make it connection ready. All I did was create a database of the same name in a new project.
var connection = mysql.createConnection({
host: 'xx.xxx.xxx.xxx',
user: 'root',
password: 'xxx',
database: 'xxx',
multipleStatements: true
});
connection.connect(function(err) {
if (err) throw err;
});
module.exports = connection;
The first potential cause is that depending on how you authenticate the connection to the Cloud SQL instance, you may have to create a new service account along a new JSON key which would be used by App Engine to connect to it. If App Engine has those credentials to the old database, that would be one root cause. Here is how to configure this.
The second is that the “app.yaml” file may not be updated with the new credentials to the new database if these are set as environment variables. Here is an example of using such configuration. Note that this example comes from this complete tutorial on connecting to Cloud SQL from App Engine running Node.js. I suggest reading it in full along the example files, and compare with your current code/configuration to notice any discrepancies.
Finally, looking at the “server.js” file, there is no mention of the socketPath (located at /cloudsql/INSTANCE_CONNECTION_NAME) or the TCP IP and port. Here is an example of such file with those configured (make sure to click the Node.js tab). Note that the App Engine standard environment uses Unix domain sockets only, while the flexible environment will also allow connecting through TCP.
I'm trying to connect to a Google Cloud SQL second generation in Python from AppEngine standard (Python 2.7).
Until now, I was using MySQLDB driver directly and it was fine.
I've tried to switch to SQLAlchemy, but now I'm always having this error when the code is deployed (it seems to work fine in local) resulting in a error 500 (It's not just some connections which are lost, it constantly fails) :
OperationalError: (_mysql_exceptions.OperationalError) (2013, "Lost connection to MySQL server at 'reading initial communication packet', system error: 38") (Background on this error at: http://sqlalche.me/e/e3q8)
I don't understand because the setup doesn't differ from before, so it must be related to the way I use SQLAlchemy.
I use something like this :
create_engine("mysql+mysqldb://appuser:password#x.x.x.x/db_name?unix_socket=/cloudsql/gcpProject:europe-west1:instanceName")
I've tried different values (with, without the ip, ...). But it is still the same. Is is a version compatibility problem ?
I use
MySQL-python in the app.yaml and SQLAlchemy 1.2.4 :
app.yaml :
- name: MySQLdb
version: "latest"
requirements.txt :
SQLAlchemy==1.2.4
It was a problem in the url. I was adding in a specific part of the code "/dbname" at the end of the connection string, resulting in something like this :
mysql+mysqldb://appuser:password#/db_name?unix_socket=/cloudsql/gcpProject:europe-west1:instanceName/dbname
So in the end, the meaning of this error can also be that the unix socket is wrong.
There are a number of causes for connection loss to Google CloudSQL server but quite rightly, you have to ensure that your setup is appropriate first. I don't think this issue is about version compatibility.
According to the documentation, for your application to be able to connect to your Cloud SQL instance when the app is deployed, you require to add the user, password, database, and instance connection name variables from Cloud SQL to the related environment variables in the app.yaml file(Your displayed app.yaml does not seem to contain these environment variables).
I recommend you review the details in the link for details on how to set up your CloudSQL instance and connecting to the instance.
I am working with ServiceStack evaluating the ORMLite provider with MySql for use on a.NET Core 1.1 project. I am running into a curious issue I am not sure what the problem is and looking for some guidance on how to troubleshoot this further or possible fixes.
I am running the .Net Core app in a standard docker container and MySql in the standard MySql container. I have been able to successfully run MySQL and connect with the workbench tool.
What I cannot do is get the executing code of the web application to successfully connect to the MySQL container. I have tried various combinations. Those where the IP Address or hostname were wrong I received a meaningful error saying the host was unknown.
But under scenarios where server name or IP address values that are used that are appropriate for the MySQL container, I receive a generic MySQLException error. The username and password are correct. I have even used the root account to ensure that there aren't any potential security hangups.
Here is a code snippet of where I am attempting to connect. This setup was working well using a local SQL db file, there is just something I am missing with either the configuration of Docker or MySQL that I haven't been able to isolate.
const string connectionString = "Server=3400f112c973:3306;Database=ServiceDB;Uid=root;Pwd=my-secret-pw;";
container.Register<IDbConnectionFactory>(
new OrmLiteConnectionFactory(connectionString, MySqlDialect.Provider ));
using (var db = container.Resolve<IDbConnectionFactory>().Open())
{
if (db.CreateTableIfNotExists<TypeExample>())
{
//Add seed data
}
}
I have figured out my scenario.
In the MySQL Connection string, if you are using a non-standard port, you need to use the port parameter to specify the different port and omit the port entirely if using the standard port.
My issue was I was always using "Server=servername:port;" which is an incorrect format and should have been "Server=servername;Port=port;" in the cases where I was using a nonstandard port number, otherwise Port= can be omitted.
I'm trying to connect my server code running as a Docker container in our Kubernetes cluster (hosted on Google Container Engine) to a Google Cloud SQL managed MySQL 5.7 instance. The issue I'm running into is that every connection is being rejected by the database server with Access denied for user 'USER'#'IP' (using password: YES). The database credentials (username, password, database name, and SSL certificates) are all correct and work when connecting via other MySQL clients or the same application running as a container on a local instance.
I've verified that all credentials are the same on the local and the server-hosted versions of the app and that the user I'm connecting with has the wildcard % host specified. Not really sure what to check next here, to be honest...
An edited version of the connection code is below:
let connectionCreds = {
host: Config.SQL.HOST,
user: Config.SQL.USER,
password: Config.SQL.PASSWORD,
database: Config.SQL.DATABASE,
charset: 'utf8mb4',
};
if (Config.SQL.SSL_ENABLE) {
connectionCreds['ssl'] = {
key: fs.readFileSync(Config.SQL.SSL_CLIENT_KEY_PATH),
cert: fs.readFileSync(Config.SQL.SSL_CLIENT_CERT_PATH),
ca: fs.readFileSync(Config.SQL.SSL_SERVER_CA_PATH)
}
}
this.connection = MySQL.createConnection(connectionCreds);
Additional information: the server application is built in Node using the mysql2 library to connect to the database. There are no special firewall rules in place that are causing network issues, and that's confirmed by the fact that the library IS connecting, but failing to authenticate.
After setting up Cloud SQL Proxy I managed to figure out what the actual error was: somewhere between the secret and the pod configuration an extra newline was being added to the database name, causing any connection attempt to fail. With the proxy set up this was made clear because there was an actual error message to that effect displayed.
(notably all of my logging around the credentials that I was using to validate that the credentials were accurate didn't explicitly display the newline and was disguised by the fact that the console display added line breaks to wrap the display, and it happened to line up exactly with where the database name ended)
Have you read the documentation on https://cloud.google.com/sql/docs/mysql/connect-container-engine ?
In Container Engine, you need to set up a Cloud SQL Proxy container alongside your application pod and talk to it. The Cloud SQL Proxy will then make the actual call to Cloud SQL service.
If the container worked locally, I assume you have Application Default Credentials set on your development machine. It could be failing because those credentials are not on your container as a Service Account file. Try configuring a Service Account file, or create your GKE cluster with --scopes argument that gives your instances access to Cloud SQL.
I like to setup a dedicated MySQL server in a LAN accessible from other computers of this network. How can I setup the database server and the clients?
How can a Grails application can access the MySQL from the same LAN?
If your MySQL server is going to run on Windows then you can configure it with the installation program. For example, I downloaded the install file mysql-installer-community-5.6.20.0.msi (versions change quickly) and it offers the option of installing just the server:
Just follow the screen prompts and take all the default values (strongly recommended). The main values to remember are:
The default network port number 3306.
The server's ip address.
The username(s) and password(s) that you created that have access to
MySQL.
Then I suggest you download HeidiSQL and configure a connection to your new MySQL server, that way you can manage your database server remotely:
Hope that helps.
You are asking 2 differents questions.
To set up mysql connection in your grails app, did you at least try to read the doc ?
http://grails.org/doc/latest/guide/single.html#dataSource
It's just a jdbc connection string :
https://www.google.fr/?gws_rd=ssl#q=jdbc+mysql+connection+string+example
It's more than just the JDBC connect string. You won't get far without a driver, so uncomment the sample entry in BuildConfig.groovy in the dependencies section and update the version to the most recent:
dependencies {
...
runtime 'mysql:mysql-connector-java:5.1.34'
}
Set the driverClassName in DataSource.groovy, along with the correct JDBC url for your database. Replace <server> with the server name or IP address, and <dbname> with the correct database name. You will likely also want to add parameters at the end of the url in the querystring. And if the port is non-standard (3306 is the default) then add that in also. To ensure that you use INNODB tables (older versions of MySQL default to MyISAM), specify the MySQL5InnoDBDialect (or a subclass):
dataSource {
...
driverClassName = 'com.mysql.jdbc.Driver'
dialect = org.hibernate.dialect.MySQL5InnoDBDialect
url = 'jdbc:mysql://<server>/<dbname>'
}
Run grails compile to download the driver jar and setup the classpath.