►
From YouTube: Vitess: Introduction and New Features - Sugu Sougoumarane & Deepthi Sigireddi, Planetscale, Inc.
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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 - Sugu Sougoumarane & Deepthi Sigireddi, Planetscale, Inc.
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. This will be followed by demos of the exciting new features that have been built in the last 6 months: - Automatic failover - Online schema changes with gh-ost or pt-osc - Compatibility with popular MySQL frameworks like Ruby on Rails and Spring - Streaming and Change Data Capture workflows with VReplication
https://sched.co/ekIT
A
Hello
today
we
will
be
talking
about
viktors,
we'll
give
you
a
brief
introduction
and
we'll
also
give
you
a
few
demos
that
cover
some
of
the
new
features
that
we
have
recently
developed.
I
am
sugu
sugumaran,
I'm
co-creator
of
with
tess
and
also
cto
at
planetscale,
and
I'm
joined
with
deepti
cigaretty,
who
is
lead
maintainer
at
quick
test
and
also
software
engineer
at
planetscape.
B
B
Pittus
is
also
highly
available,
and
this
is
a
result
of
the
primary
replica
configuration
in
which
widows
clusters
typically
run
and
the
seamless
way
in
which
you
can
fail
over
from
a
primary
to
a
replica
in
case
of
unexpected
downtime
with
this
is
right.
Now
my
sequel
compatible.
It
runs
against
any
mysql
flavor
community
enterprise,
corcona,
mariadb,
etc.
B
B
Let's
cover
a
few
key
concepts
in
with
this.
The
first
one
is
key
space
in
a
traditional
database
architecture.
People
usually
have
a
monolithic
database
in
witis.
You
break
that
monolithic
database
into
segments,
each
of
which
is
called
a
key
space,
and
a
key
space
scan
itself
consists
of
multiple
individual
databases,
but
it
is
a
logical
database
and
a
width
cluster
can
contain
multiple
key
spaces,
so
multiple
logical
databases,
each
of
which
may
contain
more
than
one
physical
database.
B
B
Let's
look
at
the
witter's
architecture
in
this
picture.
We
are
showing
n
shards
and
all
of
these
shards
together
comprise
a
key
space
or
a
logical
database,
and
it
consists
of
multiple
physical
databases
and
for
each
of
those
physical
databases.
We
run
a
component
called
a
vt
tablet
which
takes
over
the
management
of
those
physical
databases
in
terms
of
doing
backup,
restores
and
providing
protection
against
unanticipated
queries
that
might
overload
the
database
and
things
like
that.
B
B
C
C
C
C
You
have
to
work
with
object,
object-relational,
mappers
tools
that
translate
from
the
objects
and
struct
your
work.
You're
working
with
in
your
host
language,
to
complicated
sweet
sql
queries
that
the
test
has
to
be
able
to
understand
and
run.
We
also
want
your
old
code
to
work
with
the
tests,
not
just
the
new
projects,
forcing
our
users
to
have
to
change
old
sql
queries
is
not
a
good
idea
if
we
want
happy
users.
C
Lastly,
we
want
you
to
be
able
to
use
an
application
that
works
well
with
my
sql
and
make
it
scale
by
pressing
the
tests
in
front
of
my
sql
when
we
started
working
with
this
project
in
last
spring,
we
quickly
picked
the
wordpress
as
the
thing
that
we
were
aiming
to
support
here.
We
are,
we
have
our
newly
installed
mysql
cluster
and
we
have
the
test
in
front
of
it,
and
we
are
configuring
wordpress
to
talk
first
directly
to
the
banking
mysql
cluster.
C
C
C
C
C
The
last
piece
of
the
illusion
that
I
want
to
show
here
is
user-defined
variables.
This
is
something
that
lives
in
the
session
states
on
my
sql
and
because
we
can't
trust
which
my
sequel
will
end
up
in.
We
have
to
do
the
same
thing
copy
these
values
into
the
session
state
at
the
bt
gate
level
and
provide
it
to
the
tablet
when
necessary
or
evaluate
directly,
when
we
can
here's
an
example
of
us
having
to
send
down
the
information
in
form
of
a
parameterized
query
to
the.
C
D
D
D
D
Tablets
have
started,
200
is
the
master,
and
now
we
can
initiate
the
application.
Workflow
called
move
tables
which
lets
you
move
a
number
of
tables
from
a
source.
So
commerce
is
what
we
called
the
existing
database.
That's
the
key
space
customer
was
the
new
bitters
cluster
and
we
copied
over
customer
and
see
order
from
commerce
to
customer.
D
D
It
shows
you
the
which
position
it's
running
at
it's
syncing,
currently
from
commerce
to
customer.
At
this
point,
your
existing
database
is
still
contains
all
the
data
it's
where
the
app
is
pointing
to,
and
you
can
see
when
you
insert
into
the
existing
database.
It
gets
synced
and
the
target
still
has
the
new
row
that
you
created.
D
Now
we
start
switching
over
to
the
latest
cluster
with
switch
reads
or
read-only
and
replica,
and
then
finally,
we
switch
over
the
rights
which
space
all
traffic
from
your
app
is
going
to
the
biggest
cluster
note
that
we
are
still
running
a
reverse
replication
at
this
point
when
we
switch
rights,
keeping
your
original
existing
database
server
in
sync
with
the
latest
cluster.
We
can
look
look
at
this
by
looking
at
the
reverse
workflow
that
is
automatically
created
by
vitas,
and
you
can
see
that
the
position
is
in
sync.
D
So
to
do
this
to
switch
back,
we
do
the
reverse.
We
switch
reads
back
to
your
existing
database
and
then
we
switch
rights,
in
which
case
now
the
app
is
pointing
to
your
existing
database
with
this
cluster
is
just
there
in
the
background.
It
is
still
the
forward.
Replication
is
still
running.
So,
if
you,
the
app,
is
now
inserting
data
into
the
existing
database,
the
whitish
cluster
still
is
kept
in
sync.
D
E
With
my
skill
on
large
and
busy
systems
in
multi-table
is
a
risky
operation.
It
is
blocking,
if
not
on
the
primary
aid
and
on
the
replicas,
it
will
create
replication
lag,
it
is
resource-ready,
it
can
consume
so
much.
I
o
that
your
environment
is
unable
to
serve
production
traffic.
It
is
unauditable
and
uninterruptible.
You
can't
expect
to
know
what
the
status
is
or
hit
control
c
and
expect
things
to
just
come
back.
E
The
way
they
were
workarounds
exist
in
the
form
of
external
tools,
like
ghost
spitting
on
online
schema
change
or
facebook's
online
online
schema
change.
These
are
tools
that
req
that
require
operational
knowledge
from
the
engineer
they
need
to
run
in
in
the
production
environment.
They
need
to
know
they
need
to
get
the
identities
of
the
affected
service.
They
need
service
discovery,
they
can
do
throttling,
but
they
need
to
understand
how
to
do
throttling
which
service
to
throttle
by
what
is
the
environment?
What
does
the
environment
look
like?
E
This
situation
is
undesired
and
this
is
why
vitesse
is
happy
to
present
a
new
syntax
for
online
ddl,
an
alter
with
ghost
table
author
with
pd
online
schema
change,
table,
putting
the
power
back
into
the
developer's
hands
and
abstracting
away.
All
of
the
complexity
of
running
schema
migrations.
Let's
look
at
a
quick
demo.
E
E
I'm
going
to
begin
with
the
normal
outer
table.
That's
a
blocking
operation
in
production.
I
wouldn't
run
that
that
could
take
minutes
hours
or
days
to
run.
But,
of
course,
here
on
this
very
small
table,
it
returns
instantly
already.
We
see
that
vtes
is
very
useful
to
us
here,
because
it
abstracts
away
the
need
to
know
what
are
the
affected
shards.
How
many
shards
are
there
for
this
table?
Who
are
the
primary
servers
for
these
tables?
This
is
something
that
vitesse
already
is
aware
of
and
abstracts
away.
E
E
That's
because
this
operation
goes
asynchronous
and
offline
vitesse
becomes
the
owner
of
the
scheduling
of
this
migration.
In
fact,
every
shot
in
itself
owns
the
scheduling
of
the
migration.
It
can
take
place
in
the
next
minute
or
in
the
next
hour,
depending
on
whether
there
is
other
running
migrations.
E
E
E
A
Hello,
everyone
I'm
going
to
give
you
a
very
quick
demo
of
the
orchestrator,
which
is
actually
a
new
component
of
with
us
with
us,
has
previously
had
what
we
call
as
planned.
Failovers,
which
means
that
if
you
plan
to
deploy
software
or
if
a
port
goes
down-
and
it
gets
an
event,
it
does
automatically
performs
failovers
where
it
changes
the
current
master
and
fails
and
promotes.
C
D
A
A
A
Which
is
a
single
which
is
an
uncharted
key
space,
and
in
this
key
space
I
have
a
master
and
four
replicas,
of
which
one
is
not
an
eligible
master,
and
now
that
I
have
now
that
I've
also
brought
up
the
orchestrator
which
is
running,
and
the
orchestrator
also
has
the
same
view
of
the
topology
except
it
actually
has
a
better
ui.
You
can
see
that
it's
now
beautifully
graphically
represented.
A
So
as
soon
as
you
do
a
reparent,
then
what
with
us
has
done
it
has
performed
the
failover,
but
as
soon
as
it
does
a
failover,
the
orchestrator
notices
that
it
has
happened
and
adjusts.
I'm
saying
that
see
now,
one
one
one
is
the
new
master,
so
they
are
both
in
agreement,
but
you
could
also
go
to
the
orchestrator
and
say:
hey
you.
A
C
E
A
D
A
A
After
a
few
seconds,
it
will
notice
that
something
is
off
and
it
says:
okay,
I'm
going
to
perform
some
functions.
These
are
I'm
running
it
in
repose
mode,
but
if
you
refresh
here,
101
was
the
previous
master,
and
now,
if
you
see
it,
says
hey,
I
have
now
promoted
100
as
a
master,
because
101
is
done.
A
What
I
can
now
do
is
go
back
and
bring
that
one
on
I'm
still
waiting
for
the
shutdown
to
finish,
and
if
you
see
here
you
do
the
refresh,
you
should
see
that
100
is
now
the
master.
101
is
actually
done.
If
I
click
on
the
status,
it
will
save
this
down.
So
now
I'm
going
to
bring
back
101
and
as
soon
as
I
bring
up
101
I
can
go
to
orchestrator.
A
It
will
say:
hey
101
is
back
up
and
it
looks
like
everything
is
fine.
I'm
going
to
now
point
him
back
at
the
new
master,
so
the
way
orchestrator
works
is
it
works
in
this
thing
called
the
desired
state.
Any
component
is
not
in
the
correct
state,
it
goes
and
fixes
it.
So
it
makes
this
entire
cluster
self-healing,
even
even
but
then
it's
beyond
just
looking
at
the
state.
It's
also
looking
at
whether
something
is
able
to
serve
traffic
or
not.