►
From YouTube: Vitess: Intro and New Features - Deepthi Sigireddi, Alkin Tezuysal, Andrew Mason & Malcolm Akinje
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Vitess: Introduction and New Features - Deepthi Sigireddi & Alkin Tezuysal, PlanetScale, Inc.; Andrew Mason & Malcolm Akinje, Slack Corp.
Vitess is a cloud-native storage solution that can scale indefinitely. In this session, we will first cover a high level overview of Vitess features, the architecture, and what database workloads are a good fit. Then we will demonstrate how to get started with Vitess on Kubernetes. This will be followed by VTAdmin, the next generation of tooling and UIs for managing large-scale, multi-cluster Vitess deployments, built for developers and operators alike. We will demo resharding using VTAdmin, and will talk about improvements to performance and scalability along the way.
A
A
A
A
We
have
contributors
from
many
different
companies
and
a
vibrant
community
in
our
slack
workspace,
and
it's
mostly
written
in
golang
fittus-
is
a
cloud
native
database.
It
runs
in
kubernetes.
It
was
started
at
youtube
where
it
used
to
run
in
borg.
So
it
was
a
natural
evolution
for
bitters
to
be
able
to
run
in
kubernetes.
A
It
is
scalable
highly
available.
All
of
those
good
things
with
provides
certain
durability
guarantees
that
you
don't
get
with
vanilla
mysql.
It
also
gives
you
the
illusion
of
a
single
database.
So
behind
the
scenes
you
might
be
running
hundreds
or
thousands
of
individual
database
servers
in
order
to
achieve
the
scalability
and
the
high
availability,
but
to
an
application.
It
looks
like
a
single
database.
A
Applications
can
get
single,
dedicated
connections
to
with
us
which,
behind
the
scenes
translate
to
many
individual
mysql
connections
and
vitus
can
present
as
mysql,
5.7
or
8.0.
It
can
run
with
mysql,
5.7
or
8.0,
and
it's
compatible
with
many
frameworks
and
orms
bitter
serves
millions
of
qps
in
production.
A
A
The
union
of
all
the
shards
comprises
your
database
as
far
as
the
application
is
concerned
and
a
cell
is
a
failure
domain.
So,
depending
on
the
availability
guarantees
you
want,
you
will
deploy
witness
components
in
different
cells
and
a
cell
could
be
a
data
center
or
it
could
be
an
individual
server
rack
or
it
could
be
an
availability
zone
or
a
region,
or
something
like
that
in
a
cloud
provider.
A
A
When
you
run
bitters
in
front
of
such
a
replicated
configuration
of
mysql,
there
is
a
witus
component
that
lives
with
each
of
those
mysqls
called
a
vt
tablet
in
production.
You
typically
run
multiple
clusters.
They
might
be
shards
of
the
same
key
space
or
they
may
be
multiple
key
spaces.
That
has
multiple
logical
databases.
A
All
traffic
goes
through
a
component
called
vtgate.
This
is
a
proxy
that
pretends
to
be
my
sql.
It
speaks
to
my
sql
protocol.
It
looks
like
a
single
mysql
server
to
an
application
and
it
figures
out
which
actual
mysql
the
query
needs
to
go
to
and
in
order
to
scale
out
depending
on
the
application,
traffic
vt
gates
can
be
scaled
up
as
the
traffic
grows
and
each
vt
gate
will
be
able
to
route
to
any
of
the
key
spaces,
and
shards
vtgate
has
to
do
this
in
a
transparent
way.
A
As
as
far
as
the
application
is
concerned,
there
is
only
a
database
and
vtgate
has
to
route
them
to
the
right
databases:
the
right
shards,
the
right
clusters.
How
does
it
do
this?
It
does
this
by
looking
at
the
schema,
and
the
sharding
scheme
sharding
scheme
is
what
is
also
known
as
v-schema
or
vita
schema.
This
tells
vtgate
the
necessary
metadata
in
order
for
vtgate
to
figure
out
where
to
route.
The
queries.
A
A
The
last
thing
I
want
to
talk
about
is
the
control
daemon.
There
is
a
component
called
vtctld
which
allows
you
to
perform
management
operations
on
the
cluster.
It
works
with
the
toppo,
it
gives
you
a
view
of
the
topo
and
it
allows
the
operators
to
perform
manual
failovers
and
things
like
that.
All
sorts
of
manual
operations.
A
Just
briefly
about
what
is
new
in
with
us
recently
and
what's
coming
up,
we
are
doing
our
12-0
release.
Ga
in
about
two
weeks,
we
did
a
release
candidate.
Last
week
we
have
been
improving
the
query
support
we
have.
There
is
still
a
small
set
of
sub
queries
that
are
not
supported,
especially
in
sharded
mode,
but
that
set
keeps
getting
smaller
as
we
keep
working.
B
B
As
you
know,
we
heard
from
the
other
talks
the
operator
and
the
kubernetes
are
recommended
way
of
running
stateful
applications
for
especially
for
databases,
and
there
is
also
with
operator
for
kubernetes,
which
is
open
source,
and
what
does
it
do
beyond
the
regular
operators?
It
does
automation
of
vtest
functions
and
basically
it
helps
with
the
the
cluster
management
and
all
that
other
flags
and
and
the
command
line
tools
that
you
would
have
to
run
and
also
keeps
the
consistency
and
and
the
failovers
automated,
and
helps
a
lot.
B
So
so
I
want
to
show
you
a
little
bit
of
the
operator
how
it
does
it
and
because
this
time,
consuming
and
and
it
won't
fit
in
this
part
of
the
the
talk
we
need
to
deploy
a
test
cluster.
In
this
case,
it's
going
to
be
deployed
in
gke
and
and
then
we
deployed
operator,
which
is
a
very
low
footprint
and
it's
basically
fast.
B
B
So,
first
of
all,
that's
not
correct.
Okay,
this
one!
Hopefully
you
can
see
this.
I'm
gonna
start
this.
So
we
have
kubernetes
cluster,
that's
already
deployed
and
and
then
running
with
the
with
the
test
operator
and
basically
operator
has
one
pod
there's
three
parts
for
xcd
and
and
then
we
have,
since
we
already
ran
the
sharded
cluster,
we
have
a
commerce
and
and
a
customer
key
spaces
which
they
have
vt
tablets
as
a
pod.
B
So
also
we
have
some
some
vtc
tld
and
vtgate
pods
in
this
cluster
and
already
running
along
with
the
operator,
and
what
I
wanted
to
do
is
to
deploy
some
load
and
two
parts.
It's
going
to
deploy,
select
and
and
insert
recursive
on
this
database
in
key
space
customer
and
it
will
create
some
load
on
it
and
we
have
the
customer
table
and
we
have
the
order
table.
It's
called
c
order
and
then,
as
we
run,
these
db
load
pods,
which
are
actually
docker
images,
that's
pre-created.
B
We
have
all
documented
all
the
on
the
link
that
I
mentioned.
If
you
want
to
try
this
yourself,
it's
very
easy
to
do
this,
and
and
then
we
generate
some
load
on
the
sharded
cluster
and
and
then
the
traffic
starts
coming
in
for
the
sake
of
this
demo,
and
so
the
the
inserts
are
increasing,
that
the
number
of
rows
are
increasing
and
then
the
cluster
is
healthy.
Running
with
the
operator.
An
operator
actually
manages
everything.
B
So
if,
if
in
in
this
case
of
of
kubernetes,
if
a
pod
was
killed,
it
will
reinstate
and
and
then
recover
the
pod
from
the
existing
image
and
then,
if
it's
a
replica
it
will
fail
over
to
the
primary
it
would
do
all
of
that.
So
what
we're
going
to
do
in
this
example
over
here
we
have
a
table
called
c
order
and
it
has
multiple
columns.
Skew
is
the
one
of
them.
It's
var
binary,
128
default.
Now
I
set
the
ddl
strategy,
which
you
mentioned.
B
We
do
online
ddl
and
in
the
test
world
and
then
to
online
and
then
invoke
this
ddl
with
altar
table,
and
then
it
becomes
a
migration.
The
migration
gets
executed
behind
the
scenes
without
impacting
the
load
or
the
there's.
No
like
locking
or
anything
it's
it's
it's
online
and
and
then
we
can
see
the
the
migration
status
that's
running
and
running
on
the
customer
key
space
on
a
charted.
B
There
are
two
two
shards
in
this
example,
and
each
chart
has
one
primary
and
one
replica
running
under
this
kubernetes
cluster
and
and
then
we
can
see
it's
actually.
The
tablets
are
are
healthy,
whether
from
the
command
line
example
over
here
from
mysql
or
from
the
test
commands
that
you
can
do
it
look
at
it
also
there's
an
option
to
see
from
the
kubernetes
end.
B
We
have
the
the
primary
and
replicas
set
up
for
this
customer
key
space.
You
can
see
in
the
in
the
customer
charted
replicas.
We
have
two
primaries
what
I
wanted
to
show
over
here.
While
the
load
is
running,
there
is
a
there's.
A
replica
ended
with
four
two
two
three
and
I
want
to
actually
say
I
want
to
fail
over
to
this.
Just.
B
I
think
that
the
the
primary
on
this
shard
is
not
doing
well
just
a
a
scenario
over
here,
and
I
want
to
fail
over
to
to
the
replica
while
the
the
migration
the
altar
is
running
on
that
cluster.
On
the
sharder
cluster,
I
can
actually
tell
with
this
okay
fail
over
to
this
shard.
This
is
called
a
planned
repair
and
shard,
because
I
know
this
is
not
an
emergency,
I'm
planning
this
and
then-
and
I
invoke,
and
because
it's
a
small
cluster
it
becomes
available,
and
then
it
flips
over.
B
So
when,
when
we
test,
when
you
tell
vitesse
that
I
want
to
get
this,
this
replica
become
a
primary
and
it
will
actually
take
the
other
one
if
the,
if
the
the
old
one
is,
is
available,
it
will
actually
detach
and
and
attach,
as
a
replica
so
always
have
one
replica
available.
Of
course,
in
production
you
would
have
multiple
replicas,
not
just
one
at
least
two
and
and
then
you
could
actually
set
them
in
different
regions.
B
So
so
that's
it
and
we'll
go
back
to
the
workflow.
So
what
we
did
is
we
ran
the
101
example
it's
in
sio,
and
then
we
created
a
load
with
an
example.
Docker
image
did
the
recursive
select
and
insert,
and
we
graph
there's
a
load
coming
in.
We
execute
an
online
ddl
while
all
this
running,
and
then
we
failed
over
in
one
of
the
shards
from
a
replica
to
a
master
to
primary
and
then
and
then
we
were
able
to
continue
the
load.
Thank
you
all
right.
B
C
Okay,
my
demo
is
done
hello.
My
name
is
andrew
mason.
I
am
a
senior
oh
yeah.
I
can
take
my
mask
off.
You
can
probably
hear
me
a
lot
better
hi.
My
name
is
andrew
mason,
I'm
a
senior
software
engineer
at
slack,
and
I
am
a
maintainer
on
the
test
project
and
I'm
here
to
talk
to
you
about
something
that
I
and
a
couple.
Other
people
have
been
working
on
called
vt
admin.
As
deepti
was
saying
earlier,
vitamin
is
the
next
generation
of
cluster
management
and
web
ui
tooling.
C
For
for
cluster
management,
it
will
eventually
replace
the
vtc
tld,
which
we
just
saw
in
in
alken's
demo,
so
I'm
gonna
kind
of
do
a
demo
and
talk
at
the
same
time.
So
we'll
see
how
that
goes
in.
In
the
original
case,
you
have
a
single
vitesse
cluster,
which
is
like
a
let
me
jump
through
here.
So
different
version
of
what
dp
showed
you
earlier.
Basically,
everything
that
talks
to
the
topo.
C
C
And
that
you
know
looks
like
this,
so
I
have
some
shards.
I
have
some
not
serving
don't
worry
about
that.
We'll
come
back
to
that
later
and
what
vt
admin
does
is
vtm
is
going
to
sit
in
front
of
these
vtctlds
and
allow
you
to
manage
multiple,
completely
isolated
deployments
at
the
same
time.
So
that
looks
like
this,
so
we
took
that
one
chart
and
shrunk
it
down
and
stamped
out
two
more
of
them
and
we
have
a
single
vt
admin,
api
and
v2,
ad
and
web.
C
That
sits
in
front
of
all
three
clusters
where
this
is
useful.
Just
as
a
trivial
example
is,
if
you
have
prod
dev
and
qa,
you
would
like
them
to
not
overlap
and
not
collaborate
each
other,
so
you
can
have
them
completely
isolated
from
each
other
and
then
stick
a
vt
admin
and
have
traffic
admin.
Traffic
flow
only
one
way,
application
traffic
being
completely
separate.
C
So
in
words,
it's
a
single
control
plane
for
multiple,
the
test
deployments,
which
are
we
use
the
very
overloaded
but
useful
term
of
cluster.
It
provides
both
grpc
and
http
api
endpoints
for
you
to
program
against.
If
you
want
to
build
any
automation
on
top
of
vt
admin
api,
you
can
do
that.
There's
also
ui
for
human
friendly
use
of
the
tool.
C
The
back
end
is
written
in
go
along
with
the
rest
of
the
test
project
and
we're
using
react
on
the
front
end
and
the
goal
here
being
to
eventually
replace
the
existing
btc
dlv
ui,
which
is
for
a
single
cluster
and
vtm.
It
works
just
as
well.
If
you
only
have
one
cluster,
but
you
get,
you
know
more
power
out
of
it
from
having
a
many
to
one
relationship
and
so
there's
a
branch
which
you
can
get
from
the
slides.
C
So
here
I
have
a
local
deployment
running
on
my
laptop,
so
to
be
a
little
small
and
use
our
imaginations
a
little
bit,
because
my
laptop
is
not
very
large.
So
I
have
two
two
clusters:
one
having
a
single
key
space
called
media,
which
has
two
shards
zero
to
80
and
80
to
zero,
and
then
four
non-serving
shards,
which
I
will
get
to
in
a
moment.
C
C
Each
cluster
has
a
vt
gate,
they're
called
local
one
and
local
two
key
spaces
as
before
schemas
with
sizes.
I
can
look
at
the
schema.
I
can
see
how
they
are
sharded
and
one
of
the
other
useful
things
to
do
in
the
tests
which
has
not
been
talked
about,
I
think,
is
a
thing
called
vt
explain,
which
is
basically
my
sql
explain,
plan,
but
the
test
style.
C
So
you
can
sort
of
see
how
the
test
will
route
a
query
based
on
the
sharding
scheme.
So
I
can
go
into
vt
admin
and
I
can
go
here
select
star
from
books
and
unsurprisingly,
this
will
go
to
every
shard
in
the
key
space,
because
in
order
to
collect
everything,
we
have
to
go
everywhere,
but
if
I'm
going
to
pin
it
down
based
on
a
single
sharding
key-
and
this
is
actually
my
most
popular-
my
personal
most
common
use
of
vt
explain-
is
to
see
where
a
particular
row
lives.
C
So
where,
in
this
logical
database,
does
this
row
actually
live?
So
I
can
go
to
the
tablets
in
that
shard
and
do
some
diagnostics,
so
I
can
see
that
id10
gets
mapped
to
shard
media-80
and
that
is
pretty
much
vt
admin.
So
now,
as
you
grow
over
time,
your
sharding
may
end
up
not
fitting
in
the
space
that
you
allowed
anymore.
So
right
now
I
have
two
shards,
but
I
have
a
whole
bunch
more
users
and
so
a
whole
bunch
more
data.
And
now
my
data
doesn't
fit
onto
two
charts
anymore.
C
So
I'm
going
to
use
a
feature
of
a
test
called
reshard
to
live
without
taking
down
time.
Take
my
data,
that's
on
two
shards
and
split
it
across
four
shards
and
we're
going
to
see
what
that
looks
like
inside
of
et
admin.
So
that
is
what
these
other
four
shards
are
for,
so
I'm
going
to
go
over
to
workflows,
which
is
where
things
are
going
to
show
up,
and
the
ap
has
made
my
thing:
tiny
that
looks
sufficiently
large.
C
Okay.
So
the
first
thing
that
I'm
going
to
do
is
I've
done
a
bunch
of
prep
work.
I've
inserted
some
test
data,
I've
spun
everything
up.
I've
created
all
the
shards
because
it
takes
forever.
So
I'm
going
to
go
right
to
it
and
I'm
going
to
create
two
workflows,
one
for
going
from
dash
80
to
40
boy,
40
and
40
80,
and
then
a
second
workflow
going
from
80
to
80
00
to
zero.
To
the
end
of
the
key
range
you
can
reshard
the
entire
key
space
with
a
single
workflow.
C
We
have
found
in
our
personal
experience
that
when
you
are
operating
on
sufficiently
large
key
spaces
and
you
have
dozens
to
hundreds
of
shards,
it
becomes
trickier
to
manage
with
like
retrying
and
restarting
and
doing
cut,
overs
and
piecemeal.
So
we
like
to
create
one
workflow
per
source
to
destination,
which
is
why
I'm
doing
this
way.
C
C
D
D
D
Vdif
is
the
only
optional
step
of
a
resharding
experience,
but
is
immensely
critical
when
wanting
to
validate
that
the
prior
steps
of
your
resharding
workflow
have
ran
to
completion
and
ran
as
intended.
What
vdif
does
is
that
it
takes
a
diff
between
your
target
and
source
charts
to
actually
validate
that.
The
data
that
you've
copied
over
is
there
and
it
validates
if
that
the
data,
thank
you
and
it
validates
that
the
there
is
no
extra
data
that
has
been
copied
over
any
data
that
you
did
not
intend
to
be
in
your
destination
charts
at
slac.
D
We
currently
manage
one
of
the
largest
for
test
clusters
in
production
and
because
of
that,
due
to
our
scale,
we
do
end
up
in
certain
situations
where
we
run
into
certain
bottlenecks
or
unintended
situations.
That
is
only
due
to
our
scale.
Most
recently
that
has
been
noticed
in
vdif
if
we
step
into
v
diff
specifically,
what
happens
is
that
v
diff,
mainly
all
of
the
work
happens
in
the
vtc
tld.
D
All
of
the
most
of
the
load
is
generated
on
the
vtc
tld
and
also
you
need
to
run
one
v
diff
per
source
shard.
So
if
you're
splitting
one
shard
to
two
or
two
to
four
you'll
need
one
v
diff
or
two
and
two
v
diffs,
respectively,
and
at
slack
when
we
run
a
vdif
in
production,
it
normally
ends
up
around
averaging
seven
hours.
So
if
you're
running
one
vdif,
things
are
okay,
you
can
run
it
and
finish
it
by
the
end
of
the
workday.
D
But
as
that
number
increases,
you
need
to
run
these
v-diffs
either
sequentially
so
back-to-back
or
you
can
run
them
manually
in
parallel
running
them.
Sequentially
leads
you
into
the
issue
of
you
run
one
v-diff.
You
come
back
seven
hours
later.
Hopefully
it's
done,
and
then
you
run
the
you
run
the
next
one
that
obviously
becomes
a
more
that
be
obviously
becomes
more
unmanageable
as
the
amount
of
vidifs
you
need
to
run
increases
and
then
you
step
into
the
world
of
okay.
D
Let
me
try
to
run
these
v
diffs
in
parallel
when
you
want
to
run
these
vdifs
in
parallel
since
they're
blocking
calls.
What
normally
happens
is
that
you
end
up
running
multiple
screens
or
multiple
t-muxes
and
a
common
scenario
at
slack.
Is
that
we'll
be
splitting
more
than
one
or
two
shards
and
in
that
case
you'll
be
juggling?
Maybe
six
plus
t-muxes
and
screen
sessions
at
one
time,
but
you're
also
now
doing
this
in
parallel
and
one
v,
diff
is
already
generating
load
on
a
vtc
tld.
D
D
So
what
ended
up
happening
over
the
past
six
months,
while
I've
been
at
slack
as
I
have
worked
on
an
in-house
tool
built
on
top
of
our
existing
vtops
binary
adslock,
which
allows
us
to
interact
with
our
topology
with
our
cluster
and
it
will
orchestrate
vdifs
and
it
will
work
with
our
concurrency
limit
and
it
will
allow
us
to
spread
out
all
of
the
load
on
all
of
our
vtc
tlds
and
also
allow
vdiffs
to
run
back
to
back.
So
even
if
vita
finishes
at
3
a.m.
D
D
We
have
our
service
discovery,
which
will
end
up
finding
these
vtc
tlds
and
from
there
you
start
your
vdif
workers
and
the
vdif
workers
are
tied
to
a
specific
vtc
tld
and
all
they
do
is
grab
one
workflow
and
then
send
that
request
to
a
vtctld,
and
when
it's
done
it
will
grab
another
one.
You
can
specify
the
number
of
vt
v
diff
workers
you
want,
and
with
that
you
can
also
increase
the
number
yeah.
D
D
And
if
we
look
back
here,
we
can
see
is
that
in
the
output
of
this
command
v
diff
for
media
80
dash
is
completed.
V
diff
for
media
dash,
80
has
completed,
and
in
this
disfound
false
shows
you
what
vtc
tld
was
used,
and
it
also
shows
you
the
output.
So
the
v
diff
will
tell
you
how
many
rows
were
processed,
how
many
rows
were
matching
if
there
were
extra
rows,
as
I
mentioned
before,
and
this
is
grouped
by
workflow
and
then
by
table.
D
D
D
So
now,
if
we
head
here
and
refresh
the
page,
we
can
see
now
that
the
original
source
shards
dash,
80
and
yeah,
the
the
original
source
shards,
are
no
longer
serving
and
the
destination
shards
are
now
the
serving
charts
here,
and
so,
with
all
of
that
said,
thank
you
for
your
time.
I
appreciate
everyone
who
was
able
to
make
it
here.
A
Does
the
test
require
a
storage
manager
like
rook
or
fort
worts,
or
does
it
manage
the
local
storage
on
each
node
I'll?
Take
that
one
yeah
with
us
does
not
require
a
storage
sorry,
so
the
question
was:
does
witness
require
a
storage
manager
like
rook
or
portworx,
or
does
it
manage
local
storage
on
its
own
with
us,
does
not
require
a
storage
manager
like
seph
or
like
rook
or
portworx?
A
It
can
work
with
cloud
storage
or
network
attached,
storage
or
local
storage
in
when,
when
running
with
the
kubernetes
operator,
most
people
use
cloud
storage
like
amazon,
I'm
blanking
on
the
ebs
or
gcs
google
cloud
storage,
but
people
have
also
run
with
us
with
ceph.
So
storage
managers
are
optional.
C
So
the
question
was
for
vt
admin:
does
it
talk
to
the
vtc
tlb,
or
does
it
ever
talk
to
the
topo
directly
and
it
only
ever
talks
to
the
vtc
tlv
there's
a
couple
of
things
that
go
through
the
tablets
or
sorry
for
through
the
vt
gates,
because
vtgates
have
a
different
view
of
the
health
of
the
tablet.
So
that's
what's
powering
those
those
tablets
serving
not
serving?
C
If
I
go
like
this,
this
one
two
three
fourth
column,
that's
coming
from
the
gates,
because
we
are
interested
in
what
the
gates
think
about
tablet
health,
because
it
affects
query
serving
versus.
What's
in
the
topo,
which
is
delayed
basically
but
other
than
that,
everything
goes
directly
to
the
vtc
dld,
which
then
proxies
the
topo.
C
So
commands
have
to
be
run
from
the
cli.
Vtm
is
mostly
read-only.
Is
the
plan
to
to
make
it
more
powerful
than
just
just
a
read-only,
a
very
good
read-only
ui?
And
yes,
that
that's
the
plan?
That's
where
we're
going.
The
vtc,
that's
part
of
the
vtct
ld
parity
is
the
vtc
dld
ui
lets
you
do
all
of
those
like
destructive
administrative
operations
and
we're
we're
getting
there.
A
We
support
5.7
and
8.0
and
the
minor
versions
of
those
two
major
versions
we
used
to
support
5.6.
We
don't
really
support
it
anymore,
because
it's
been
and
end
of
life
with
us
can
work
with
the
percona
distribution
of
mysql
oracle,
community
edition
enterprise
edition
mariadb,
almost
all
the
variants.