►
From YouTube: Webinar: How to migrate a MySQL Database to Vitess
Description
Though starting off new projects on Vitess is generally a friction-free process, in a lot of cases, the need for horizontal sharding doesn’t become apparent until rapid growth has already pushed the boundaries of a single MySQL instance. This webinar will discuss a basic process that will allow you to test and gradually cut over to Vitess when your application can’t afford to go down in the process.
Presenter: Liz van Dijk, Solution Architect and Field Operations @PlanetScale
A
And
again,
sorry
so
I'd
like
to
thank
everyone
who
is
joining
us
today.
Welcome
to
today's
CNN
signal
webinar
how
to
migrate
the
bicycle
database
to
details.
So
my
name
is
Daniel:
oh
I'm,
a
preschool
technical
marketing,
major
and
my
head
as
a
lad.
I'm,
a
CSF
investor,
so
I'm
gonna
be
moderating
today's
webinar
and
we
like
to
welcome
our
presenter
today
obese
event,
a
the
solution
architect
in
a
field
operation
and
premise
scale.
There
are
a
few
thing
housekeeping
items
obligatory
during
the
webinar.
A
You
are
not
able
to
tall
as
a
nd,
so
there's
a
create
box
at
the
bottom
of
your
screen.
So
please
do
feel
free
to
drop
your
question
in
there
and
will
we
get
as
many
as
we
can
get
the
end.
So
this
is
your
official
webinar,
obviously
ncf
and
it's
achieve
its
objective
científico
to
conduct.
So
please
do
not
add
anything
to
the
chair
or
a
question
would
be
no
violation
of
the
code
of
conduct.
So
basically
it
please
do
respectful
all
over
your
fellow
participant,
pretenders
and
please
also
know
the
recurring
answer.
B
Thank
you
very
much.
Daniel
welcome
everyone,
today's
webinar
so
yeah,
my
name
is
Liz
Van,
Dyke,
I
work
for
planet-scale
and
today
I'm
going
to
be
talking
about
four
tests
and
the
things
you'll
need
to
consider
when
moving
into
it
from
an
existing
MySQL
base.
Deployment
first
help
establish
the
why
I'm
going
to
be
starting
off
by
covering
some
of
the
basic
concepts
about
the
tests
and
then
we'll
go
over
some
typical
pitfalls
and
just
a
few
recommended
methods
to
avoid
those
when
making
the
jump.
First,
let's
see
a
really
quick
introduction.
B
B
We
are
headquartered
in
Mountain,
View
but
I
suppose,
like
many
of
you,
we're
all
remote
employees.
Currently
I
am
myself
a
Belgian
I
live
in
Portugal,
but
I'm
talking
to
you
from
California.
So
my
background
is
mainly
MySQL
and
I'm
just
beginning
to
dip
my
toes
into
this
wacky
world
of
cloud
native
architectures.
So
I'm
really
excited
to
bring
you
along
as
I
figure
it
out.
B
So
what
is
Vitesse?
We
throw
the
word
cloud
native
around
quite
often,
but
what
does
that
really
mean
when
it
comes
to
databases?
Well,
10
years
ago
YouTube,
which
was
a
real
web
2.0
darling,
was
facing
some
pretty
unique
data
related
challenges
and
instead
of
building
something
new,
their
database
team
at
the
time
decided
to
try
and
adapt
MySQL
and
MySQL.
By
now
has
seen
more
than
25
years
of
active
development.
It's
got
tons
of
optimizations
and
durability
increases
and
by
itself
as
great
performance
and
reliability
already.
B
That's
why
it's
such
a
great
foundational
building
block
for
any
application,
but
it
doesn't
scale
horizontally.
So
Vitesse
was
designed
as
a
middleware
layer
on
top
of
my
escape
well
to
provide
that
transparent,
sharding
logic,
and
it
does
so
while
presenting
itself
to
your
application
as
a
single.
My
sequel
end
point.
B
Secondly,
you
might
remember
that
Google
had
acquired
YouTube
a
couple
years
prior,
so
the
database
team
also
needed
to
adjust
their
framework,
so
it
could
survive
in
Google's,
stateless
container,
orchestration
environment,
which
is
called
Borg.
Because
of
this
reason,
and
I
only
realized
this
recently
myself,
we
can
actually
proudly
claim
that
the
test
was
ready
to
run
on
kubernetes,
even
before
kubernetes
was
first
officially
released.
It
was
built
to
be
cloud
native
from
the
start,
so
a
very
quick
glance
at
Vitesse
as
a
part
of
the
CN
CF
portfolio
is
right
here.
B
It
became
an
incubation
project
as
part
of
the
CN
CF
database
landscape
in
early
2018
and
as
of
last
November,
it
was
the
first
project
to
graduate
there
we're
going
to
be
releasing
6.0
in
april
and
some
of
the
features
I'm
covering
in
this
webinar,
it's
ha-joon,
but
but
everything
we're
talking
about
today
can
be
accomplished
with
Vitesse
already
I'm
not
going
to
go
too
deeply
into
the
rest
of
our
stats,
but
suffice
to
say
it's
considered
a
very
healthy
and
active
project
by
a
lot
of
large
scale.
Web
companies
today.
B
B
So,
to
help
take
in,
let's
take
a
look
at
our
reference
architecture,
quite
a
lot
going
on
in
this
diagram,
but
understanding
it
is
going
to
be
very
helpful
in
our
later
explanations
about
how
we
can
gradually
build
up
to
an
environments
just
like
it,
as
I
explained
before,
Vitesse
speaks
MySQL
and
even
when
split
across
many
different
shards,
it's
going
to
present
itself
to
your
application
as
a
unified,
my
sequel
database.
So,
what's
on
the
left
of
the
dotted
line
in
this
diagram,
could
be
anything
from
my
sequel,
GUI
clients.
B
The
right
thing
to
do
so,
as
your
application
scales
you're,
going
to
be
learning
lessons
about
which
architectural
choices
do
and
don't
work
we'll
get
into
the
ways
to
gradually
close
that
gap
for
your
application,
though
so
there
doesn't
need
to
be
one
big
dramatic
cut
over
for
now.
Let's
quickly
discuss
what
we're
looking
at
here
from
the
ground
up,
we
can
see
that
all
of
the
components
in
Vitesse
are
meant
to
be
treated
as
cattle
rather
than
pets,
especially
in
the
query
path.
Each
element
is
built
to
be
duplicated
and
recoverable
from
sudden
failure.
B
B
So,
let's
take
a
closer
look
at
these
building
blocks
real
quick
to
build
a
bit
of
foundational
knowledge
about
how
Vitesse
works
behind
the
load
balancer
in
that
diagram.
Just
now
you
saw
what
we
call
the
VT
gates.
This
is
your
applications,
entry
point
to
the
tests
by
itself.
It's
a
very
light,
stateless
proxy.
B
It
also
has
a
couple
of
built-in
optimizations,
like
connection
pooling,
to
help
boost
performance,
so
I'm
just
going
to
mute
or
at
least
join
someone
feedback
here.
Where
can
someone
of
the
moderators
help
do
that?
For
me?
Please,
alright!
So,
as
I
said,
VTA
that's
got
a
couple
of
built-in
optimizations
like
connection
pooling
to
help
boost
performance
and
it
also
installs
some
guard
rails
around
queries
that
could
potentially
harm
our
cluster.
B
We
know
that,
as
far
as
instances
go,
each
shard
may
have
multiple
copies
of
our
data,
but
the
overall
design
of
our
database
schema
and
how
it
presents
itself
is
still
very
important.
Piece.
Paces
in
Vitesse
are
defined
by
the
combination
of
a
good
old,
normal
schema
file,
as
well
as
the
added
v
schema,
which
describes
the
sharding
related
metadata
in
a
JSON
format.
B
We
generally
recommend
spinning
up
at
least
three
replicas
tablets
to
ensure
high
availability
on
that
level
within
a
shard,
replication
is
managed
by
the
tests,
but
it
uses
my
sequel
standard
replication
functionality,
so
we
use
the
same
terminology
to
describe
them
so
zooming
in
on
the
shard
itself
and
I
guess
I
jumped
to
this
slide
a
little
too
soon
so
zooming
in
on
the
shard
itself.
These
are
made
up
of
one
or
more
Vitesse
tablets.
So,
as
we
said,
the
recommended
amounts.
B
Minimum
amounts
for
high
availability
is
three,
but
these
the
tests
tablets
are
the
smallest
worker
units
that
we
have
available,
and
it's
where
existing
my
sequel
users
should
be
getting
into
more
familiar
territory.
The
Vitesse
tablet
is
made
up
of
a
normal,
my
sequel
server
process
and
a
small
V
T
tablet
sidecar
process
that
helps
inject
the
logic
that
we
need
to
make
my
sequel
sharding
aware
this
pair
of
processes
could
run
anywhere
that
you
would
like
to
run
MySQL.
B
You
could
run
it
on
a
bare
metal
machine
on
a
virtual
machine
inside
of
a
container
and
the
my
sequel
server
flavor.
That
is
used,
we're
actually
agnostic
too,
so
it
could
be
any
type
or
version
that
you're
already
familiar
with
or
running
now,
within
a
shard
VT
gate
is
able
to
send
reads
to
each
available
tablets,
but
the
rights
are
reserved
for
only
a
master
tablet,
of
which
there's
always
just
one
so
to
make
sure
that
within
a
given
shard,
we
always
have
at
least
two
fully
consistent
copies
of
our
data.
B
B
This
GUI
is
not
a
standard
part
of
the
tests,
but
it
helps
me
illustrate
all
of
the
previously
mentioned
concepts
a
little
bit
more
easily.
So
while
we
were
talking,
we
discussed
a
couple
of
different
elements,
so
we
talked
about
VT
gates.
We
talked
about
key
spaces,
shard
sharding
schema,
as
well
as
a
normal
database
schema
and
I
just
want
to
give
you
four
that
looks
like
so
over
here.
We
can
see
basically
a
dashboards
of
what
it
looks
like
to
run.
Four
tests
I'm
just
using
a
little
example,
application
just
move
arm
for
variety.
B
So,
if
you've
seen
some
of
our
talks
at
conferences,
you
might
recognize
the
name
of
this
database,
but
just
to
give
you
a
quick
peek,
the
tests
really
to
give
you
a
look
at
the
schema,
real
quick.
So,
as
you
can
see,
our
schema
is
made
up
of
normal.
Sql
looks
very
familiar.
There's
nothing
strange
going
on
here.
B
This
just
looks
like
a
good
old
MySQL
database
schema
very
simple
database
here,
just
three
tables,
but
on
top
of
that
schema
we
do
need
to
embed
a
little
bit
more
logic
to
ensure
that
sharding
works
properly
as
expected.
So
we
have
a
sharding
schema
on
top
of
that
which,
in
in
Vitesse,
is
called
the
V
schema,
and
we
discussed
that
earlier.
So
the
V
schema
is
described
by
a
JSON
file
that
essentially
it
latches
on
to
the
existing
schema
definition
and
and
just
adds
more
metadata
to
it.
B
It
helps
us
define
a
variety
of
details
here.
I
won't
get
into
the
specifics
of
how
to
build
a
schema
too
deeply
on
this
talk,
because
there's
there's
hours
that
we
could
fill
about
that.
But
I
wanted
to
give
you
a
quick
idea
of
what
it
looks
like
and
we'll
talk
about
some
methods
to
go
back
and
forth
and
testing
whether
your
design
is
being
effective
or
not.
B
B
So
let
me
show
that
real,
quick
how
that
works,
so
I
just
copied
the
connection
string
just
using
normal,
my
sequel,
client
as
we're
logging,
and
you
can
see
the
server
version
right
here-
the
Vitesse,
my
sequel,
community
server.
That's
actually
what's
telling
us
that
we're
logging
into
VT
gates,
but
operationally
you'll
see
that
it
works
very
similarly.
So
we
have
two
databases
available
I'm
going
to
use.
One
of
them
just
prove
that
this
really
does
look
and
feel
exactly
like
MySQL,
so
I'm
just
going
to
run
a
query
here.
B
B
B
B
Will
do
thank
you,
I'm
sorry,
I
had
not
seen
those
messages
all
right,
so
let's
hope
that
this
stays
more
stable.
Please
feel
free
to.
Let
me
know
if,
if
there
are
any
more
issues,
moving
forward,
okay,
so
this
was
just
a
quick
demo
to
show
or
to
illustrate
that
when
Vitesse
is
up
and
running,
even
though
there's
a
lot
of
complexity.
In
the
background
to
your
application,
it
actually
looks
and
feels
just
like,
like
an
individual
like
a
single
MySQL
and
two
points
and
all
of
the
logic
required
to
distribute
your
queries.
B
Bringing
back
the
architecture
slide,
let's
collect
all
of
those
components
that
we
talked
about
and
start
thinking
about
how
we
can
move
towards
our
implementation.
So
there's
a
few
critical
items
to
consider
when
moving
to
the
test
today,
as
I
mentioned
before,
it's
not
yet
a
hundred
percent
compatible
with
all
of
my
sequels
query
language,
but
even
where
compatibility
is
not
an
issue,
queries
might
respond
differently
in
a
sharded
environments
than
you'd
expect,
and
it's
important
to
start
familiarizing
yourself
with
what
makes
or
breaks
a
sharding
strategy.
B
Just
because
your
query
were
doesn't
mean
that
using
it
is
a
good
idea,
make
sure
to
test
your
query
workload
extensively
and
expect
that
you'll
need
to
do
some
rewriting
in
most
cases
so
where
and
how
do
we
even
start
that
process
now?
The
first
step,
the
very
first
step
to
assessing
your
workloads
compatibility
can
be
done
without
even
installing
the
tests,
thanks
to
a
tool
called
VT
explain.
B
This
tool
is
analogous
to
my
sequels
explained
statement
and
when
it's
fed
a
V
schema
and
a
schema
file,
this
tool
is
going
to
return
a
breakdown
of
how
VT
Gate
is
expected
to
handle
the
query
in
a
real
cluster
environment.
So
it's
also
going
to
provide
immediate
feedback
in
case
your
query
is
not
supported
at
all
by
the
tests,
rather
than
setting
up
a
full
the
test
cluster.
B
From
the
start,
this
step
could
be
executed
on
anyone's
local
machine
I'm,
going
to
show
that
momentarily
in
a
brief
demo,
you
can,
you
can
grab
VT
explained
either
by
getting
the
latest
test
packages
or
building
the
tool
from
source.
Now,
just
because
you
can
run
it
locally,
doesn't
mean
you'll,
be
able
to
start
completely
unprepared,
first
and
foremost,
to
get
started.
We're
going
to
want
a
a
solid
snapshot
of
your
actual
load.
B
So
some
monitoring
tools
like
pmm
or
vivid
cortex,
allow
you
to
already
take
a
normalized
set
of
queries
to
use,
which
is
definitely
a
very
efficient
way
to
test.
But
if
you
don't
use
either
of
those
monitoring
services,
you
can
also
create
your
own
normalized
query
list
by
collecting
a
set
of
queries
in
production
yourself.
You
can
do
so
by
setting
my
sequel,
slow
query
log
in
feature
to
log
all
queries
for
a
limited
amount
of
time.
B
However
long
it
takes
to
capture
a
representative
sample
and
then
running
that
throughput
through
the
PT
query,
digest
tool
to
get
a
ranked
list
of
your
most
impactful
queries
and
those
will
be
normalized
as
well.
So
you'll
have
a
nice
clean
list
to
work
with
and
get
a
good
idea,
yes
of
how
the
tests
will
respond
to
them.
So
once
you've
done
that
you're
gonna
want
to
read
up
on
schema
and
V
schema
design.
B
There
is
a
lot
to
consider
when
building
the
right,
V,
schema
and
testing
your
design
with
VT
explained
is
a
very
important
step
towards
getting
that
right
in
the
first
place
as
the
rule
of
thumb,
if
you're
always
selecting
information
is
filtered
by
a
specific
customer
or
business
ID,
those
tend
to
be
good
starting
points
for
your
scarf
is
sharding
key.
Try
it
out,
though,
with
VT
explained
to
see
how
well
your
V
schema
works
with
your
existing
query
workload
or
how
either
your
schema
or
your
queries
can
be
tweaked
for
better
results.
B
B
Minimal
example
of
how
this
works
on
the
top
of
the
slide
here
is
our
current
schema
definition,
which
is
no
different
than
you
would
see
in
MySQL
and
off
to
the
right.
Is
our
V
schema
for
this
database,
which
has
a
single
key
space
defined
as
charted
on
the
column
data
for
both
tables?
If
we
run
the
VT,
explain
command
and
we're
assuming
a
shard
count
of
two,
we
can
see
from
the
outputs
exactly
how
VT
gates
will
break
the
query
down
into
pieces
and
gather
information
across
the
cluster.
B
Now
VT
gate
doesn't
actually
connect
to
anything
it's
not
connecting
to
an
actual
topology
server.
So
there
is
no
Vitesse
cluster
right
now
to
help
us
predict.
We
can
give
it
a
clue.
We
can
give
it
the
amount
of
shards
that
we
predicts
will
we'll
need
to
use,
and
it
will
make
its
determination
based
on
the
information
that
we're
feeding
it
here.
B
But
it's
going
to
give
you
a
sense
of
how
VT
gate
is
going
to
respond
to
that
query,
how
it
will
need
to
break
apart
the
query
to
make
sure
that
it's
it's
you
know
it's!
It's
accessing
the
correct
shards
rather
than
have
you
just
believe
me,
though
I'm
just
going
to
show
it
off
real
quick.
So
let's
do
another
short
demo.
B
Right
here,
oh
I,
think
I
am
already
in
the
right,
folder.
Okay,
so
I
have
the
VT
explained
binary
just
installed
right
here
in
my
in
my
demo,
folder
I
also
have
exactly
those
two
files
as
displayed
on
the
slide.
So
if
you
get
these
slides,
you
can
just
copy-paste
both
of
those
yourself
to
give
this
a
quick
shots.
B
And
because
it's
a
rather
long
command,
I
did
execute
it
right
before
starting
here.
If
we
want
to
run
Fiji,
explain
to
get
a
sense
of
how
it
would
work
here
is
the
he
here
is
how
you
break
down
the
cup
itself.
So
we've
got
VT
explained
we're
specifying
our
schema
file,
which
is
just
our
normal
schema
definition.
Rv
schema
file,
which
is
the
Vitesse
related
metadata.
B
B
It's
going
to
send
it
right
away
to
the
exact
shard
it
predicts
will
contain
the
correct
answer
so
here
in
this
list.
Right
now,
only
one
query
has
been
executed.
You
can
see
the
steps
that
VT
gate
needs
to
take
to
execute
this
query
in
our
current
example.
This
is
a
perfectly
normal
supported
query,
so
we're
not
getting
an
error
in
return
in
you
know
in
case
you
have
a
query
workloads
that
has
some
unsupported
language
you're,
also
going
to
get
an
immediate
error
results
with
it
with
a
clear
message
about
that.
B
But
if
we're
writing
up
a
query
that
does
a
comparison,
for
example,
we'll
see
that
right
away
the
tests
will
need
to
start
querying
every
single
shard
to
make
sure
that's
each
row
is
matched
against
this
requirement.
So,
given
that
we're
specifying
two
shards
in
this
gate,
VT
gate
predicts
that
we
will
be.
B
B
B
Vt
gate
as
as
a
rule
will,
you
know,
will
just
compile
the
sets
of
results
and
return
it
back
to
your
application
as
a
single
table.
Just
as
MySQL
would
but
VT
explained
allows
you
to
figure
out
what
you
know,
how
it
needs
to
go
about,
gathering
your
data
and
what
the
expected
impact
is
going
to
be.
So
this
actually
helps
you
tweak
both
your
your
V
schema
or
your
queries.
B
B
Just
a
quick
summary
of
Viti
explained
it's
a
pretty
handy
tool
and
it's
kind
of
the
the
first
step
that
we
recommend
anyone
take
when
you're,
considering
moving
your
existing
work
load
into
the
tests,
and
it
will
bring
you
a
long
way
into
making
sure
that
your
application
is
is
the
right
fit
is
set
up
for
success
there.
So
oops
now
that
we
have
built
an
understanding
of
our
workloads
through
some
trial
and
error,
we're
gonna
want
to
start
building
out
of
a
test
environments
in
your
dev
QA
environment.
B
B
B
Another
aspect
to
consider
with
Vitesse
is
the
additional
network
latency
created
by
VT
gate.
If
you
are
already
running
a
load
balancer,
this
should
not
be
too
unfamiliar,
but
under
normal
circumstances
we
expect
VT
gate
to
add
about
1,
to
2
milliseconds
to
your
round-trip
time
so
add
another
1
to
2
milliseconds,
if
you're,
just
introducing
a
load
balancer
for
the
first
time
as
well
and
generally
speaking,
VT
gate
by
itself
adds
almost
no
time
at
all
to
your
queries
and
it
may
actually
speed
them
up
thanks
to
the
performance
enhancements.
B
B
I'm
gonna
pull
in
our
diagram
one
more
time
to
refresh
your
memory
of
the
components
that
we
covered
earlier
and
how
they
all
work
together
in
our
reference
architecture.
Pulling
this
up
specifically
because
now
you
can
look
at
this
illustration
of
a
slightly
simplified
and
less
beautiful
rendition.
B
B
So
VT
tablets
will
be
acting
purely
as
a
pass-through
layer
without
attempting
to
manage
the
original
instance
by
say,
controlling
its
replication
settings
or
trying
to
take
backups.
So
VT
tablets
can
be
set
up
in
such
a
way
that
it's
it's
only
acting
as
a
pass-through
layer,
VT
gates
are
proxy,
is
kind
of
agnostic
to
this
distinction,
and
it's
going
to
treat
this
original,
my
sequel
instance
as
a
fully
fledged
uncharted
key
space.
So
we
have
a
parallel
query
path
available.
B
That's
going
to
run
through
most
components
of
the
tests,
even
without
having
established
a
fully
managed
for
tests
key
space.
So
how
we
dip
our
toes
and
start
to
divert
traffic
is
strongly
dependent
on
your
application
design.
If
you
are
using
your
own
application
internally,
we
would
recommend
starting
off
there
and
just
using
you
know
using
it
in
production
in-house,
so
divert.
B
But,
however,
it's
accomplished,
we
do
recommend
starting
small
and
switching
more
of
the
traffic
over
as
your
confidence
grows.
This
is
a
process
that
you
could
take
days
weeks
even
months
to
complete.
However
long
you
need,
but
it
should
definitely
be
completed
before
moving
on
to
the
next
stage,
so
once
cutover
as
completed-
and
we
do
have
all
of
our
traffic
running
through
fiji
gates,
we're
still
not
running
a
fully
fledged
Vitesse
tablet
here,
but
we
have
started.
B
B
B
So
we
are
going
to
use
to
accomplish
this
we're
going
to
use
of
a
test.
Workflow
called
table
migration,
which
specifically
is
going
to
come
out
with
the
test
6
to
start
separating
out
these
tables
needing
to
be
sharted.
So
in
previous
versions
of
the
tests,
this
process
was
called
vertical,
vertical
split
clone
and
it
used
a
slightly
different
internal
mechanics
to
accomplish
a
similar
goal,
the
goal
being
to
perform
a
live
table
copy
and
a
traffic
cut
over
between
running
to
running
instances
of
mysql.
B
B
We're
using
table
migration
there's
a
little
bit
more
information
here
as
we're
copying
that
over
when
the
process
has
completed
your
newly
migrated
tables
are
going
to
be
running
in
a
separate
key
space,
though
thanks
to
VT
gate,
you'll
still
be
allowed
to
join
tables
between
both
of
those
environments.
So
we've
moved
over
some
tables
to
a
completely
different.
My
sequel
instance
a
separate
key
space,
but
VT
gate
still
allows
us
to
join
tables.
B
The
Vitesse
tablets,
as
it's
spun
up,
is
also
going
to
enjoy
the
benefits
of
being
full
managed
by
the
tests.
So
that
means
it
can
be
very
easily
made
ready
for
high
availability.
Just
by
having
multiple
replicas
spun
up,
it's
going
to
have
its
backup
state
you
can
automatically
etc.
So,
as
you're
building
your
familiarity
with
the
tests,
this
very
same
process
can
be
used
to
eventually
migrate.
B
B
There's
a
more
description
of
the
process
itself,
just
a
couple
of
highlights
here
about
the
setup,
as
I
mentioned
before
our
legacy.
My
sequel
instance
is
treated
as
an
uncharted
key
space
by
itself
that
my
sequel
instance
is
untouched
unmanaged.
It
doesn't
really
require
any
changes.
In
our
example,
I
didn't
really
get
into
sharding
for
the
new
key
space,
but
we
might
as
well
have
so
don't
hesitate
to
dive
into
the
documentation
to
familiarize
yourself
and
skip
a
few
steps
ahead.
B
If
you
know
it
is
exactly
what
your
environment
needs,
Vitesse
has
workflows
available
for
all
of
these
major
reconfigurations
and
data
migrations
and
planet-scale
engineering
has
also
been
hard
at
work
at
a
new
set
of
migration
tools
that
will
serve
to
better
support
this
process.
Every
step
of
the
way
just
making
it
easier
for
you
to
generate
an
initial
V
schema
as
well
as
automating
much
of
the
table,
migration
workflow
so
more
to
come
on.
That's
pretty
soon,
either
way
until
then
there's
a
great
set
of
tutorials
available
on
the
Vitesse
io
website.
B
B
So
you
get
a
look,
there's
a
couple
of
very
important
operations
here
that
have
clear
user
guides
built
up
around
them
and
I
highly
recommend
them
as
a
way
for
you
to
get
familiar
with
how
all
of
this
works
and
I
hope
you
enjoyed
this
webinar
as
much
as
I
enjoyed
delivering
it.
My
goal
was
to
inspire
some
confidence
in
the
fact
that
there's
methods
that
will
allow
you
to
safely
and
gradually
support
your
adoption
of
container
orchestrated
cloud
environments
without
having
to
leave
your
database
behind.
Thank
you
very
much
for
listening.
B
Don't
hesitate
to
reach
out
on
the
Vitesse
community
slack
if
you
end
up
trying
out
those
tutorials
so
as
I
as
I
mentioned
at
the
start,
I'm
just
getting
started
in
this
world
myself,
but
I'm
happy
to
be
joined
by
two
contributing
engineers
today,
who
can
help
answer
any
questions?
I'm?
Not
able
to
field
myself
and
on
that
note,
Deepthi,
Morgan
and
I
are
happy
to
dive
in
then
ready
for
some
Q&A.
A
Awesome,
that's
a
reason
for
great
presentation
and
demo,
so
we
are
now
having
some
time
for
questions.
So
you
have
any
question
just
please
just
drop
into
the
crane
and
talk
at
the
bottom
of
your
screen
and
we
will
get
administering
we
have
time
for
so
by
the
way
we
have
a
two
question
here.
The
first
one
is:
is
it
possible
to
be
used
to
Maria
Devi.
B
Yes,
answer
that
right
away,
it
is
possible
to
use
Maria
DP
or
any
flavor
of
MySQL
as
you're
backing
database,
so
you
can
build.
You
can
attach
the
test
tablets
to
any
flavor
of
MySQL.
As
of
right
now,
I
see
right
nice
follow-up
question
there
is
it
possible
to
use
PostgreSQL?
No?
No,
as
of
right
now,
Vitesse
support
liam
my
sequel
as
a
backing
database.
This
is
a
question.
B
A
A
B
D
B
Thank
You
Morgan
next
question
looks
like:
could
you
explain
a
bit
more
on
how
to
migrate
the
existing
data
into
shards
any
tools
available
for
it?
We
have
a
32
terabyte
in
ODB
table
I.
Suppose
I
can
take
a
crack.
I
can
take
a
crack
at
this
at
this
at
this
question,
but
it
is
a
relatively
large
one
and
it's
highly
dependent
on
the
design
of
your
schema.
B
Where
you
know,
people
will
be
able
to
get
into
your
environments
with
a
bit
more
detail
and
trying
you
know,
get
get
a
little
bit
more
and
give
you
a
little
bit
more
information
and
a
little
bit
more
of
a
background
about
how
to
start
approaching
this.
It's
it's
going
to
be
multiple
steps,
basically,
depending
on
your
current,
your
current
schema
and
how
much
of
it
you're
willing
to
change
to
adapt
it
to
a
sharted
environment.
D
I
might
just
add
a
couple
of
points
on
that,
because
it
is
quite
a
large
database,
the
tests
in
being
cloud
native.
It
encourages
you
to
run
with
smallish
odds
so
that,
if
you
have
the
failure,
it
can
kind
of
move
the
data
around
quickly.
You
know
so
that
you
have
this.
You
have
this
probability
where
you
could
have
a
failure,
while
you're
doing
your
redistribution
so
encourages
shots
to
be
about
250
gigabytes
each
knowing
that
that
takes
about
10
or
15
minutes
to
be
able
to
copy
that
data.
D
C
If
I
may
also
jump
in,
if
this
is
really
a
single
table,
that
is
32
terabytes
with
witness,
it
is
definitely
possible
to
shout
it.
It
may
just
be
a
long
process
and
as
far
as
tools
for
accomplishing
the
actual
shouting,
they
are
part
of
with
us,
the
rest
of
it.
What
you're
shouting
key
is
and
any
other
changes
that
might
make
that
process
easier.
That,
of
course,
is
dependent
on
the
data
characteristics
and
your
current
schema.
B
B
B
D
B
So,
just
to
provide
a
little
bit
more
background
there,
so
we
are
in
fact
very
there's,
there's
ways
that
you
can
run
the
VT
tablet
process
in
a
very
transparent
way,
and
this
is
this
is
the
way
that
we
would
recommend
running
if
you
had
to
use
PXE
as
dear
backing
database,
but
in
theory.
Yes,
you
could
use
VT
tablet
as
a
front
for
PXE
as
well.
In
that
case,
you
would
just
not
you
would
just
not
let
Vitesse
manage
your
replication
settings
and
choose
to
rely
on
PXE
for
that
I.
A
B
A
Right,
that's
at
least
for
the
great
presentation
once
again
and
demo,
and
thanks
for
answering
the
mokra
ntp
so
yeah.
That
is
all
good
question.
We
have
time
for
today
and
thanks
for
joining
us
today
again
and
the
webinar
recording
in
slicer
will
be
online
later
today,
and
we
are
looking
forward
to
seeing
you
at
future
CNN
best
possible
webinar
as
well,
so
have
a
really
good
day.