I deployed webAPP (Java) using Elastic Beanstalk, RDS(MySQL). HEALTH Status OK!
Access to the database is lost after 1 or 2 days. In the IDEA, when I connect to the database, I get an error [42000][1049] Unknown database 'ebdb'.
I have to rebuild environment (Elastic Beanstalk). But in a time I get that problem again. What is the reason of the error? How I can see in AWS is there database or not? Thanks.
I have never seen this issue. I have a custom Java Spring BOOT app running on Elastic Beanstlak and queries data from a RDS MySQL instance. Its been running well over a year without issue.
The database runs fine without any connection issues you are describing. When you look at the RDS instance in the AWS Management Console, what is the status of the database. Is it available - as shown here?
The URL to the RDS Management console in us-west-2:
https://us-west-2.console.aws.amazon.com/rds/home
I am trying to connect to my database from local machine but I am getting the following error.
ERROR 2003 (HY000): Can't connect to MySQL server on 'finaltesting2.cluster-cxtmwsuqx4ty.us-east-1.rds.amazonaws.com' (110)
Things I have done:
1: Changed the vps security group for inbound traffic. For testing purpose, I have even allowed all TCP traffic from all of the IP range
2: I don't have any firewall on my local machine that is blocking me to connect to port 3306
3: I have already looked many similar issues on stackoverlow and the answers is just to change the inbound rules but its not working for me.
4: I have proper internet connection for my local machine. i-e no network issue
Aurora Serverless (and may other AWS DB offerings - like Amazon Neptune, DocDB etc) are VPC only. You can still connect to them outside of the VPC with some additional setup. I've elaborated a few here: [1] [2]
[1] Connect to Neptune on AWS from local machine
[2] AWS Aurora MySQL serverless: how to connect from MySQL Workbench
Note that the above solutions are for non production setups. If you need something more resilient, you would need to have more infra in place. For example - If you are using an ALB to expose your DB endpoint outside of the VPC, then you need to have mechanisms that would make sure that the ALB is always pointing to the right IP of the DB instance, as IPs are bound to change when failover and host replacements happen. Do keep that in mind.
I'm trying to connect to my Aurora Serverless MySQL DB cluster using the mysql module, but my connection always times out.
const mysql = require('mysql');
//create connection
const db = mysql.createConnection({
host : 'database endpoint',
user : 'root',
password : 'pass',
database : 'testdb'
});
//connect
db.connect((err) => {
if(err){
throw err;
console.log('connection failed');
}
console.log('mysql connected...');
})
db.end();
My cluster doesn't have a public IP address so I'm trying to use the endpoint. I've successfully connected to the db using Cloud9, but I can't connect using node. I must be missing something.
Aurora Serverless uses an internal AWS networking setup that currently only supports connections from inside a VPC, and it must be the same VPC where the serverless cluster is deployed.
Q: How do I connect to an Aurora Serverless DB cluster?
You access an Aurora Serverless DB cluster from within a client application runing in the same Amazon Virtual Private Cloud (VPC). You can't give an Aurora Serverless DB cluster a public IP address.
https://aws.amazon.com/rds/aurora/faqs/#serverless
This same limitation applies to Amazon EFS, for architecturally similar reasons. You can work around the limitation in EFS, and the same workaround could be used for Aurora Serverless, but you'd need to disable the health checks entirely since those health checking connections would keep the instance alive all the time. Exposing a database to the Internet is a practice best avoided.
You could also use some VPN solutions. They would need to be instance-based and would probably need to use NAT to masquerade the client address behind the VPN instance's internal address -- that's effectively what the proxy workaround mentioned above does, but at a different OSI layer.
I was trying to use AWS Aurora Serverless for MySQL in my project, but I am impossible to connect to it, though I have the endpoint, username, password.
What I have done:
From AWS console managment, I select RDS > Instances > Aurora > Serverless
Leave the default settings
Create database
AWS will only create an AWS Cluster
I open MySQL Workbench, and use endpoint, username, password to connect the database
Ressult:
Your connection attempt failed for user 'admin' from your host to
server at xxxxx.cluster-abcdefg1234.eu-west-1.rds.amazonaws.com:3306:
Can't connect to MySQL server on
'xxxxx.cluster-abcdefg1234.eu-west-1.rds.amazonaws.com' (60)
Did I make any wrong steps ? Please advice me.
****EDIT****
I tried to create another Aurora database with capacity type: Provisioned. I can connect to the endpoint seamlessly with username and password by MySql workbench. It means that the port 3306 is opened for workbench.
About the security group:
From https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-serverless.html :
You can't give an Aurora Serverless DB cluster a public IP address.
You can access an Aurora Serverless DB cluster only from within a
virtual private cloud (VPC) based on the Amazon VPC service.
You can't access an Aurora Serverless DB cluster's endpoint through an
AWS VPN connection or an inter-region VPC peering connection. There
are limitations in accessing a cluster's endpoint through an
intra-region VPC peering connection; for more information, see
Interface VPC Endpoints (AWS PrivateLink) in the Amazon VPC User
Guide. However, you can access an Aurora Serverless cluster's
endpoint through an AWS Direct Connect connection.
So, aside from SSH-ing through an EC2 instance, you can also access your serverless cluster with mySQL Workbench with AWS Direct Connect.
You can also set up a mySQL Workbench through a RDP connection to a Windows EC2 and access the Serverless cluster. This instance only needs to be up when you need to access the Aurora.
If one of the setups here don't work, the usual suspects are the VPC Security group, firewall rules vs port number configured on the cluster or IAM configuration if connecting using IAM.
One way to connect to an Aurora Serverless DB cluster is by using an Amazon EC2 instance. You cannot
create publicly accessible Aurora Serverless DB clusters in the Preview. This task walks you through
creating a publicly accessible Amazon EC2 instance in your VPC. You can use this Amazon EC2 instance to
connect to an Aurora Serverless DB cluster.
This is directly from the docs provided upon preview signup. Please try creating an EC2 instance and using SSH Tunnel method in your MYSQL Workbench or SQL UI of choice. During the preview the Aurora Serverless is not allowed to be set to publicly accessible.
To connect to Aurora serverless or any database in private subnet you will need a 'jump host' which can be any EC2 instance in a public subnet.
Follow Below Steps:
Open the security group attached to the database, and add new rule as below:-
Type:MYSQL/Aurora, Protocol:TCP, PortRange:3306,
Source:securitygroupofEC2 (you can all security group by entering
'sg-')
Open the security group attached to the EC2, and make port 22 is open. If not, add a new rule as below:-
Type:SSH, Protocol:TCP, PortRange:22, Source:MY IP
Open Workbench, Click New connection
- Standard TCP/IP over SSH
- SSH Hostname : < your EC2 Public IP > #34.3.3.1
- SSH Username : < your username > #common ones are : ubuntu, ec2-user, admin
- SSH KeyFile: < attach your EC2 .pem file>
- MYSQL Hostname: <database endpoint name> #mydb.tbgvsblc6.eu-west-1.rds.amazonaws.com
- MYSQL Port: 3306
- Username : <database username>
- Password: <database password>
Click 'test connection' and boom done!!
A common pattern used by customers for connecting to VPC only services (like Aurora Serverless, Amazon Neptune, Amazon DocDB etc) is to have a middle layer (EC2 instance, or ALB etc) and making the middle layer accessible from outside the VPC. If your use case is just trying out some queries or connecting a workbench, then the easiest thing to do is:
Resolve the DNS of the serverless db and obtain its IP
Create an ALB in your VPC, with a target group to the IP that you found in #1
Create a new security group and attach that to your ALB
Update the SG to allow inbound from where ever you want. If you want public internet access, then allow inbound from all IPs, enable an internet gateway in your VPC, and use a public subnet for your ALB.
Once all of this is done, you would end up with a new DNS - that points to your ALB. Make sure that your ALB is set up correctly by:
Using telnet to connect to your ALB endpoint. telnet alb-endpoint alb-port. If it succeeds, then you have a full end to end connection (not jsut to your ALB, but all the way through).
Verify ALB metrics to make sure that all health checks are passing.
Once this is done, use the ALB endpoint in workbench, and you are good to go.
This pattern is recommended only for non production systems. The concerning step is the one where you resolve the DNS to an IP - that IP is ephemeral, it can change when scale compute or failover happens in the background.
Hope this helps, let me know if you need more details on any step. Here is a related answer for Neptune:
Connect to Neptune on AWS from local machine
We can't connect Aurora Serverless directly from MySQL Workbench as only private IPs assigned to Aurora Serverless, not public IP ones.
We can connect Aurora Serverless from EC2 but can't connect Aurora Serverless through the Mysql Workbench SSH tunnel.
We can't connect Aurora Serverless through ALB as ALB allow only HTTP and HTTPS traffic.
you can telnet ALB-RDS-DNS from local but can't connect to MySQL Workbench
Then what is a solution here;
We can connect Aurora Serverless through NLB as NLB allow traffic over TCP protocol;
Steps 1: Create NLB and add listener Load Balancer Protocol: TCP, and Load Balancer Port
:3306
Step 2: Select the VPC (It should be the same VPC of Aurora Serverless Cluster), and add subnets (public)
Step 3: Navigate to Configure Routing, select Target type: IP, and Protocol: TCP,Port:3306
Step 4: Use DNS Checker to get private IP of Aurora Serverless Cluster, and add those IPs with port 3306
Step 5: Create NLB
Now modify the Security group of Aurora Serverless Cluster, allow traffic from either 0.0.0.0 (not recommended) or VPC CIDR
Now, go to Mysql Workbench and use the NLB DNS name, and try to connect using the correct username and password of Aurora Serverless Cluster.
New AWS Feature: Aurora Serverless v2.0 Public IP Address Available
Like many of you I've been waiting and hoping for this for some time.
As of today April 27, 2022 RDS Aurora MySQL Serverless now has a Public option. You must create a separate security group for that option and set inbound rules.
Copy your endpoint, user, and password and you're good to go.
Look at the Comparison of Aurora Serverless v2 and Aurora Serverless v1 requirements
Worked like a charm for me.
Data API and Query Editor for connecting to Aurora Serverless are now available in some more regions.
https://aws.amazon.com/about-aws/whats-new/2020/05/amazon-rds-data-api-and-query-editor-available-additional-regions/
You should be using an EC2 instance that has access to your dbinstance.
This EC2 instance should have port 22 opened for ssh.
Now use port forwarding from local to EC2 to db instance.
Now in your work bench give hostname 127.0.0.1 and port <forwarded port>.
Aurora serverless does not have public endpoint to connect from any of the ide like MYSQL workbench,Sequel pro etc. But we can connect through cli by launching an instance in same vpc in which aurora serverless resides.
Besides you can checkout cloud9 an aws cloud ide. This is in turn ec2 only but will have UI also and can be shared with teams and bunch of other features.
Initially, I was got stuck in the same scenario
Points to be noted while connecting AWS RDS Aurora
Cant connect Public, you need an EC2 instance with the same region where Aurora is been created.
Aurora Public access should be checked No(it worked for me).
You need to create the security group, where you should add Inbound and Outbound rules(IpAddress of EC2 instances).
Ex: Type = MYSQL/AURORA, Protocol=TCP, PortRange=3306,Source=Custom and your IP Address Range,
modify instance and security group to the instance and apply the changes immediately.
While creating Aurora, u will create MasterName, Pwd, and default schema to connect.
After creating, go to cluster and take the cluster endpoint and log in with your EC2 Instance and with MySQL Workbench, Hostname as your cluster endpoint, username and pwd entered while creating aurora database.
This can be achieved using haproxy
Install Haproxy on Centos-> yum install haproxy
delete existing configuration in this file /etc/haproxy/haproxy.cfg and add the below lines(make sure you replace your RDS endpoint url in below configuration)
global
user haproxy
group haproxy
defaults
retries 2
timeout connect 3000
timeout server 5000
timeout client 5000
listen mysql-cluster
bind 0.0.0.0:3307
mode tcp
server mysql-1 test.cluster-crkxsds.us-west-2.rds.amazonaws.com:3306
After modifying the file,start the haproxy -> service haproxy start
You can connect Aurora RDS in MYSQL Workbench using Public IP with port no 3307
We have installed softether vpn in one of ec2 instance in vpc public subnet. We connected the softether vpn from linux / mac os / windows like regualr vpn. After then we were able to access all the private resources like aws aurora serverless as like regualr endpoints from mysql workbench, pgadmin, etc tools, even the django admin shell commands from local computer.
Hope this should help.
https://www.softether.org/4-docs/1-manual/2._SoftEther_VPN_Essential_Architecture/2.4_VPN_Server_Manager
My guess is your security group is not correctly setup for access. You need to explicitly allow remote access on that port to that instance.
From the official docs:
Two common causes of connection failures to a new DB instance are:
The DB instance was created using a security group that does not authorize connections from the device or Amazon EC2 instance where the
MySQL application or utility is running. If the DB instance was
created in a VPC, it must have a VPC security group that authorizes
the connections. If the DB instance was created outside of a VPC, it
must have a DB security group that authorizes the connections.
The DB instance was created using the default port of 3306, and your company has firewall rules blocking connections to that port from
devices in your company network. To fix this failure, recreate the
instance with a different port.
See here for more information:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html
I have connected an AWS Lambda function to Amazon RDS (MySQL). When the Lambda function is invoked 100 times simultaneously, there are almost 400 connections opened in RDS (as shown in RDS console). Why is this?
I checked the active connections using:
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE DB = "MYDB";
All the connections are from Lambda containers. Does anyone know how Lambda containers act on simultaneous requests? Why are the containers not reused?
Current Configuration:
var sequelize = new Sequelize('DB','username', 'password' ,{
dialect: 'mysql',
port: port,
host: host,
pool: {
max: 20,
min: 0,
idle: 300000
}
});
Even if one connection is opened per request it should be 100. How 400 connections are opened?
I'm using Sequelize. Node JS 6.9.1
Note: Connection Happens only once outside Lambda Handler method
Sequelize by defaults creates a connection pool, so it's creating 4 connections because it's designed to run as a long running service. You can disable this by setting options.pool to false see the API reference
However as your application scales this is a fundamental problem with Lambda that won't go away. I recommend building a DB proxy layer in EC2 to terminate your db connections (i.e. using ProxySQL). It will then have a connection pool to the rds db.
The only way around this is to use dynamodb as your backend store.
The lambda can have many concurrent executions.
So, more than one connection can be through by the lambda.
To fix this you need to change sequelize:
var sequelize = new Sequelize('DB','username', 'password' ,{
dialect: 'mysql',
port: port,
host: host,
pool: {
max: 1,
min: 1,
idle: 15000
}
});
Keep the pool with only one connection, in this way the connection will be reused on the next execution and remember to dont close connection after the lambda execution.
Read this article about to reuse database connection on next executions.
AWS "new" solution for this problem seems to be RDS Proxy: https://aws.amazon.com/de/rds/proxy/
RDS Proxy establishes and manages the necessary connection pools to your database so that your application creates fewer database connections.
You can use RDS Proxy for any application that makes SQL calls to your database. But in the context of serverless, we focus on how this improves the Lambda experience.
https://aws.amazon.com/de/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/