(upbeat techno music)
-: Hey everyone, welcome to the session
on how Minecraft Realms migrated to Azure Database for MySQL
for improved gameplay, better interoperability
and cost efficiency.
I am Amol Bhatnagar and I work as a product manager
of Azure Database and MariaDB services.
Prior to joining Microsoft,
I have worked as a software designer
with Hewlett Packard Enterprise,
and I've also done my masters
from Carnegie Mellon University.
So let's go and see why Minecraft migrated
to Azure Database for MySQL,
and what other benefits you can get
when you migrate to Azure Database for MySQL.
So as you know,
Minecraft Realms is one of the world's most beloved games
with millions of monthly active players.
This migration for Minecraft Realm
were basically motivated by three factors:
the first one was the cost efficiency,
the second one was the better interoperability
with the Microsoft ecosystem,
and finally, the third one was the improved gameplay
through low latency of the Azure Database for MySQL.
So these were the three reason
why Minecraft Realms migrated
to Azure Database for MySQL.
So, Azure Database for MySQL,
you can also easily lift-and-shift your workload
because Azure Database for MySQL
runs on the community MySQL engine.
So if you are hosting your servers
on AWS RDS MySQL,
or if you are on any other cloud provider,
or MySQL on-prem, then you can easily lift and shift
your workload to Azure Database for MySQL.
The other factor is the enterprise readiness
with Azure Database for MySQL.
You will get the elastic scaling with high availability,
and the secure and compliant through the features
like data encryption.
The global reach of Azure Database for MySQL
and the integrated nice fit with the services
like Azure Kubernetes Services make Azure Database for MySQL
developer productivity friendly.
So let's take a step back
and see the Minecraft Realms architecture on AWS RDS.
So Minecraft offer both single player
and multi-player mode of gameplay.
Minecraft Realms enables player
to create personal multi-player servers,
providing a private online multiplayer gaming experience.
Originally, as you can see,
from the architecture diagram here,
this was completely hosted on AWS,
and this included, their cloud hosted multiplayer game
servers and the data storage,
subscription metadata databases,
along with the service core compute fabric.
So moving this critical workload
for one of the world's most beloved games
with millions of monthly active player,
was one of the daunting and even risky tasks.
So let's see how Minecraft Realms migrated to Azure ecosystem.
The entire migration was planned
executing in two phases: the phase one.
The phase one consists of the cloud
hosted multi-player servers.
The phase two was the lift-and-shift
of the data,
which basically included the Realm databases,
subscription databases, world state data storage
and the compute fabric layer.
So as you can see,
in the architecture diagram, the phase one,
which is migrating cloud host multi-player servers.
As you know, Minecraft Realms
hosts tens of thousand of multi-player servers in the cloud.
The server are dynamically allocated
as per the user demands.
And these servers are allocated, reclaimed
as demand waxes and wanes.
So during phase one, the initial architecture,
the Minecraft Realms was hosted in AWS Job Agents,
and then the move to Azure PlayFab managed
multi-player hosting services.
So this was a phase one migration.
In phase two,
the phase two migration was considered a lift-and-shift
of the workload for this Minecraft Realms
move to Azure Database for MySQL,
utilizing data migration services.
The lift-and-shift workload migration,
basically, was comprised of three major component:
which include the database, storage,
and the compute migrations.
Breaking the migration into such phases
and the component wise,
help Minecraft migration less risk,
and without any visible changes to the users.
So this was all about Minecraft migration to Azure Database
for MySQL, and how Minecraft utilize data migration
services and divided their migration into phases
with minimal downtime and minimal impact to their user base.
Now let's see what all other options are available
to migrate to Azure Database for my MySQL
and how one goes to migrate to, if they want to migrate
to Azure Database for MySQL.
With Azure Database for MySQL, if you are migrating,
the first step is the pre-migration step,
where you have to discover the database and server
you have to migrate.
You have to assess your database schema
and see if it is right fit for Azure Database for MySQL,
then you have to migrate the schema.
These are the pre-migration steps that you have to perform
while migrating to Azure Database for MySQL.
Then another phase is the migration tools,
which you can basically use to migrate
to Azure Database for MySQL.
The migration tools consists of,
first, the dump and restore.
This is basically offline migration,
which gives you the ability to migrate offline
all the data from the source to the target
Azure Database for MySQL.
We will touch base on basically these different tools
in the later slides.
The another tool to migrate your data is basically a native
logical replication, which is an online migration.
And this migration basically keeps a very small downtime
migration to your application.
Again, we will have slides to discuss
more about this migration option in detail
in the upcoming slides.
The another option which Minecraft also utilize
is the Azure Database Migration Services.
It's an online migration and it cause minimal downtime
to your application and migrate your application without any
visible impact to your users.
So that another, the last phase is a post-migration phase.
In this migration phase, basically you will be optimizing
mainly on migrating to Azure Database for MySQL.
You will be looking whether all the data has been
migrated by running the functional and performance tests.
So the post-migration task help you to make sure
that you have migrated successfully and all your data
has been moved to Azure Database for MySQL.
So that discussed, let's move to different option
and deep dive on different tools available
with, while you're migrating to Azure Database for MySQL.
The first tool as we discussed, one, MySQL dump and restore.
As we have already discussed was MySQL dump and restore,
dump and load databases into Azure Database for MySQL.
The downtime for this tool,
if you're using this tool is for the time of the migration
on this, so basically if you're using MySQL dump and restore
to migrate to Azure Database for MySQL,
the downtime will be caused for the time
the tool is running.
And we always recommend to use pricing tier
and server parameters which I will be going
through in the next upcoming slides in details,
to utilize those server parameters and the pricing tiers,
so that you get the highest performance
while you're migrating to, migrating using dump and restore.
And you cause a least downtime during this migration.
We have also linked to some of the resources.
The first resource basically talk about MySQL dump
and restore, and the another resources in the slide
talk about the migration server parameter
and the pricing tier, for MySQL dump and restore
For faster data loads.
The another tool in this category is MyDumper and MyLoader.
MyDumper and MyLoader is exactly the same when you comes
and compare it with MySQL dump and restore,
in the regard to the downtime.
The MyDumper and MyLoader would still cause the same
downtime or in another word,
we'll call the downtime for the entire time,
the MyDumper and MyLoader is running for migrating
your database from the source to target.
The difference, and the important difference with MyDumper
and MyLoader is that, this MyDumper and MyLoader
tool is multi-threaded, and it enables you to have
a multi-threaded data import and export,
which exponentially make the data import faster and cause
lesser downtime for your application.
Again, we have our blog on the best practice
on MyDumper and MyLoader.
I have included a link for MyDumper and MyLoader blog.
And along that, we have the same set of recommendation
for choosing the right pricing tier and server parameters,
so that you can load your database and from the source
to Azure Database for MySQL much faster.
Another tool in this category
when you are looking to migrate from your source
to Azure Database for MySQL is data-in replication.
The data-in replication is different from MyDumper
and MyLoader and MySQL dump and restore.
In a that our data-in replication cause a very short
downtime, the short downtime is caused at two times.
The first time, when you are creating and taking
a dump of the database of your source server.
The another short downtime is caused
while you are shifting your connection link from your old
MySQL server to Azure Database for MySQL server.
So we have also have some of the resources
for data-in replication where you can go and learn more
about how data-in replication
Works with Azure Database for MySQL.
The first link talk about how you can set up
the data-in replication.
The second link, basically talk about the same server
parameter and the pricing tier recommendation,
which we provide so that you can have faster data loads,
and you can migrate faster to Azure Database for MySQL
with minimal downtime to your application.
Next, let's move to the server parameter recommendation,
which I was talking while I was discussing all the options
for migration which include MySQL dump and restore,
MySQL data-in replication and MyDumper and MyLoader.
So these server parameter
has the recommended value.
And basically we recommend this server parameter
so that you can have a faster data load
with Azure Database for MySQL.
The first server parameter in this category
is maximum allowed packet.
So the maximum allowed packet is to provide,
this allowed parameter it's used to prevent any overflow
due to long rows.
And we recommend to set this value,
the value of the max allowed packet to one gigabyte.
That another set of a parameter is the slow query log.
Slow query log, basically this parameter,
what helps this parameter provide is basically
this parameter turn off the logging of the slow queries
which eliminates all the overhead during the migration.
So we recommend to disable this parameter
by setting it to off during migration.
The similar recommendation on the line
is for query store capture mode.
We also recommend turning off query store capture mode
so that all the queries and all the overhead
caused by capturing those queries in the query store
will be eliminated during the migration.
Just set the query store capture mode to none
during the migration and it will not log any of the queries
to the query store.
The another recommendation is to use
the InnoDB buffer pool size.
And we recommend here to increase
the InnoDB buffer pool size.
And the only way you can increase
the InnoDB buffer pool size is to scale up the SKU.
So we recommend during the migration,
you can scale up the SKU to memory optimized 32 vCore.
This will help you to quickly ingest the data
into Azure Database for MySQL.
And when you are done with the migration,
you can scale back to the SKU,
which was desired for your workload.
The another two parameter are basically InnoDB IO Capacity
and InnoDB IO Capacity Max.
This two parameter improves the IO utilization
to optimize migration speed, and we recommend to set
the value of these two parameters to 9,000.
The another parameter is InnoDB write IO threads.
This parameter also increases the speed of the migration
and we recommend to set the value of this parameter to four.
The last parameter, or I would say this is not a parameter.
The last recommendation basically is to increase the IOPS,
increasing the IOPS, make the speed of the data injection
into Azure Database for MySQL much faster
and we recommend to increase the IOPS.
The only way you can increase the IOPS and the point
to note is basically increasing the storage.
And you can increase that storage and you can get 3X
of the storage as IOPS.
So if you have 100 GB or 200 GB of storage,
you can get 600 IOPS.
So we recommend increasing the storage
to get the higher IOPS.
One point to note here is basically that if you increase
in that storage, you cannot scale it back.
So if you we recommend increasing that storage,
by few gigabytes and see the migration data,
data ingestion speed.
And see whether they did improve and under the requirement
of your downtime and migrate to Azure Database for MySQL.
So these are the parameters recommendation,
plus some of the best practices which we have seen with many
of the migration, which will help customer.
So you can use this parameter,
utilize for faster data loads.
So with this, we are at the end of our presentation
and I put some of MySQL resources where you can get
the details which we have discussed.
The first one is a Single Server docs.
You can get, you can go to Single Server docs
and get all the details.
You can also read about Minecraft Realms migration blog.
And if you have any questions, please, please feel free
to reach out to us on,
AskAzureDBforMySQL@service.microsoft.com.
So, thank you everyone for attending this session.
(upbeat techno music)