Hello, Cloud Gurus and welcome to the GCP service spotlight. In this series,
we're going to put the spotlight on specific GCP services,
walking through detailed technical demos to explore the features, benefits,
and costs.
I'm Broadus Palmer and today we're going to talk about Google Cloud SQL. Now,
if you're an organization you're probably looking to maintain structured data
and also have the ability to back up, protect and restore.
Managing this yourself can be a huge headache,
which is where the service could come in and help.
Google Cloud SQL is a fully managed database service that can help you manage
and administer mySQL Postgres and SQL server databases in the cloud.
In this episode, we're going to take a dive into using Cloud SQL.
Talk about the pros and cons. And in the end, I'll give you my final verdict.
Using Cloud SQL can help you reduce costs by having a fully managed,
as well as automated, storage capacity management,
so you can have the storage resources you need to support your application.
You can access Cloud SQL from about any applications, such as app engine,
compute engine and Google's Kubernetes engine.
Also you have reliable and easily configure backups and replication for your
data and not to mention that your data is automatically encrypted.
Now I know one of the most important things we worry about is cost.
Cloud SQL addresses this by offering instances to fit any budget. Now,
some of your costs would depend on the engine that you choose,
whether it's SQL server, mySQL or Postgres.
Instance pricing for mySQL engine is charged for every second that the instance
is running. Now with Cloud SQL,
your pricing structure will also depend on CPU and memory,
which can cost around 4 cents per virtual CPU.
It can depend on storage which can cost about 17 cents per gigabyte for SSD
storage capacity, and networking and licensing,
which can cost up to 19 cents per gigabyte for internet egress and up to 47
cents per core hour, depending on the licensing. Now,
one of the most important questions that we have when choosing a service is how
does it benefit me and my team?
You get more secure connections to your instance,
as all traffic on internal Google Cloud networks is secured already.
You will also have automated backups that easily replicate your data to a
standby instance in another zone,
which enables automatic fail over from your primary instance and easy import and
export into Cloud SQL using Cloud Storage.
Now that we learn a little bit about Cloud SQL let's head to the demo and check
it out.
All right, I am in my Cloud playground environment.
And I want to just show you guys how simple and easy it is to really set up a
Cloud SQL instance.
And we are going to be choosing a mySQL engine on this Cloud SQL instance.
So what we are going to do is head down to storage and we're going to click on
SQL.
We're just going to click on create instance,
and we're going to choose mySQL here.
We're going to call this instance service instance,
and we're going to set a root password of one, two, three, four, five,
just something very simple.
Now location - We can choose any region within the world.
So we're going to stick to us central one, Iowa. And let's just say,
we're going to choose us central one, a zone. All right,
now for our database version,
we have a choice - and we're going to choose for my SQL 5.6 or 5.7
and 5.7 it's default. So we're just going to keep it that way.
And we're going to show configuration options here. So for connectivity,
we have the option to add a private IP address for this instance.
So we could connect to it internally and not over the internet.
And as you see by default, we have public IP already added to our instance.
So we're just going to keep the default here and we're going to go to machine
type in storage. Now machine types are also known as tiers. Now,
if you click on change, now,
this is the main image that you would use for your workload. Now,
since we're doing a test environment,
we want to make sure we save as much money as possible, right?
So let's head to the DB F1 micro,
and we're going to click on select here. Now,
as you see for the DB F1 micro,
we only have 614 megabytes of memory,
but that's enough and definitely proficient for this test environment.
All right. So we head down to our storage here.
We have the option to choose SSD or HDD.
Now SSD is solid state drives,
and it actually is more lighter, faster,
and uses more energy than hard disc drives,
but hard disc drives are actually cheaper and you can get more storage space.
So we actually want a solid state drive disc that's lighter,
more durable and uses less energy.
So we're going to stick with our storage type of SSD.
Now we can enable automatic storage increases.
So this is whenever we're near capacity for our storage,
storage will be incrementally and permanently increase.
All right now for encryption data is encrypted automatically.
Now we can use a Google managed key for our encryption key solution,
or we can use a customer managed key for an encryption key solution.
We're going to stay with the default here. Now, backups, recovery,
and high availability.
Now automated backups and point in time recovery, as it says,
helps you protect your data from loss at a minimal cost.
Now we can choose a window for our automated backups,
and this should be used particularly for the window of the most downtime,
right?
So let's say if our downtime is we have the least amount of
traffic from 1:00 AM to 5:00AM.
That's when we want our automated backups to complete.
Now we can enable point in time recovery and allows us to recover our data.
However, if we do recover our data from a clone,
we have to a new instance to do so. Alright, now availability.
We can choose single zone or high availability. In this case,
we want to choose high availability because Cloud SQL will create a fail over
instance in another zone.
So if we have any type of disaster and let's say that U S central one, a zone,
we will automatically fail over to the U S central one B zone where our fail
over instance is, or U S central one C. Here,
you can add some database flags. As you see,
we have a lot of database flags we can add here for our Cloud SQL
instance. So we're going to X out of this,
and we're going to go to our maintenance window. Now, the maintenance window,
it should happen once every few months.
So if we have a preferred window that our instance can undergo routine
maintenance, let's say we're going to do a Sunday.
And now we can choose 1:00 AM to 2:00 AM.
Since we chose 1:00 AM to 5:00 AM for our automated backup window,
we can choose the same here because that's where we have the most downtime for
our instance. Now, order of update.
Early time is useful for test instances,
allowing you to see the effects of an update before it reaches your production
instance. Now, relative to the other instances in this project,
we could choose any, later or earlier.
So we're just going to leave default at any.
And labels - we can set labels for our instance as well,
but we're just going to click on create here.
Now it can take a few minutes for instance, to create.
So I'll pause the video and I'll be right back once that instance has been
created. All right, guys, our instance has been created.
So there's a few things we can look at.
We could connect to the instance over a public IP.
We could connect using a Cloud shell, a compute engine BMI instance,
and we could connect using other methods as well, which would be app engine,
Google Kubernetes engine, Cloud function, and Cloud run.
Now we see our database version is my SQL 5.7.
Auto storage increase is enabled, automated backups are enabled,
point in time recovery is enabled. We're located in the U S central one, a zone,
highly available,
no database flag sets and no labels set as well. Now,
as you see here, we have a few options import, export, restart, stop, delete,
clone, and fail over.
We can import and export data out of our Cloud SQL instance,
and we can actually connect Cloud storage to do so. So if we import data,
we can import it from Cloud storage and we can export it to a bucket in cloud
storage as well. We can restart our instance, stop our instance,
delete our instance. We can clone our instance here.
So if I click on clone here,
get this out the way you see a clone as a separate independent copy of the
master instance and can assist in point in time recovery.
So let's hit cancel, and we can actually click on fail over as well.
So you can manually trigger failover,
and this would actually create some downtime for a few minutes.
Your instance would not be available for several minutes while the fail over is
taking place. So if you're in a production environment,
these are things you may want to consider. Okay,
so now we got a great look at how easy it is to really set up and configure a
Cloud SQL instance.
Here's what I like about using Google Cloud SQL.
Cloud SQL offers high availability and great fault tolerance for your data with
data replications and 11 nines of availability and durability of Cloud storage
as well.
The pricing was less than 5 cents per virtual CPU and less than 26 per
gigabyte for storage capacity.
And also being able to offload read requests with read replicas.
Really the only existing con I see at the moment is researching and improving on
the need to connect with more existing data sources and marketing tools outside
of Google Cloud itself. So should you invest, evaluate or revisit?
My recommendation is to invest.
Cloud SQL is a valuable service to use for easy access to your data.
It's fully managed and secure backed by a 24/7 SRE team.
Scalability is super easy. And with Cloud SQL,
you can get it set up with just a couple of clicks.
So that's it keep being awesome Cloud Gurus.
And I hope to see you in the next GCP Service Spotlight.