►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Vitess - Sugu Sougoumarane & Deepthi Sigireddi, PlanetScale
This session will cover a high level overview of all the Vitess features. Following this, we'll go over a tutorial on how to bring up a fully functional Vitess cluster in Kubernetes. Once up, we'll go through the steps to reshard the database while it's serving live traffic. Following this, we'll demonstrate the newest and most exciting feature of Vitess: VReplication, which allows you to materialize sharded views and rollups in real-time.
https://sched.co/MPiq
A
Good
morning
second
day
of
cube
con
how's
it
going
so
far
cool
alright,
so
just
to
introduce
myself,
my
name
is
subbu
I'm,
the
co-creator
of
Vitesse,
which
I
started
in
2010
at
YouTube
to
solve
its
scalability
problems
and
over
the
years
the
community
took
interest
in
with
us.
So
in
2018
we
ended
up
donating
the
test
to
the
CN
CF
and
around
the
same
time,
I
left
YouTube
to
start
planet-scale,
mainly
to
provide
dedicated
support
for
this
project
that
was
gaining
traction
and
community
excitement.
A
Deepti
here
is
a
software
engineer
at
Planet
scale.
She
has
quickly
ramped
up.
She
is
now
one
of
the
top
contributors
of
the
tests
and
also
has
elite
role
of
being
a
maintainer.
As
you
know,
one
does
not
simply
become
a
retest
maintainer,
so
without
further
ado,
so
with
DT
is
going
to
give
you
a
good
intro
about
with
tests
and
then
I'll
come
back
and
give
you
a
demo
that
will
hopefully
blow
your
minds
all
right
here.
You
go.
B
Witness
is
a
shouting
middleware
for
my
sequel:
it
sits
between
the
application
layer
and
the
database,
and
it's
massively
scalable.
There
is
actually
no
known
limit
to
how
big
a
witters
deployment
can
be,
which
means
that
we
haven't
still
pushed
it
to
its
limits.
It's
highly
available.
There
are
several
deployments
which
are
running
with
five
nines
of
availability.
Right
now,
witness
is
also
cloud
native
and
as
we
go
along,
the
talk
will
explore
what
makes
it
cloud
native.
B
B
This
is
what
the
community
for
witness
looks
like,
and
these
are
just
the
companies
that
have
given
us
permission
to
use
their
logos.
There
are
a
lot
more
adopters
of
witters,
which
are
not
listed
here,
and
many
of
these
companies
have
engineers
that
have
contributed
significantly,
to
wit
us-
and
there
is
a
very
vibrant
group
of
people
that
are
active
in
the
community.
B
B
Guess
Kelsey
Hightower's
tweets
are
going
to
be
quite
popular
at
this
conference.
We
are
not
the
only
ones
using
them
and
he's
absolutely
right
when
he
says
that
running
stateful
workloads
on
kubernetes
is
not
a
decision
to
be
taken
lightly.
It
requires
a
lot
of
work
to
get
that
working
and
we
will
see
what
we'll
see
what
has
been
done
in
with
us
to
actually
make
stateful
workloads
a
possibility
in
kubernetes.
B
This
is
what
the
witness
architecture
looks
like.
The
the
main
thing
to
notice
here
is
that
there
is
a
clear
separation
between
the
application
layer
and
the
database
layer,
and
the
interface
between
the
two
is
what
we
call
wedi
gate.
This
is
a
gateway
through
which
applications
connectivities
applications
can
connect
to
whit
us
as
if
it
is
a
single
database,
because
Witter
speaks
the
my
sequel
protocol
and
we
T
gate
exposes
an
endpoint
to
which
applications
can
connect
using
the
my
sequel
protocol.
B
B
So,
given
this
rket
sure,
how
does
it
enable
us
to
run
a
stateful
workload
in
kubernetes?
Typically
in
a
witness
witness
deployment,
you
will
be
running
my
sequel
or
the
variants
Maria
percona,
which
we
also
support.
You
will
be
running
them
in
a
master
replicas
configuration,
so
you
have
one
master
and
two
or
more
replicas
which
are
replicating
from
the
master,
and
there
are
two
things
that
two
problems
that
have
to
be
solved.
In
order
for
this
to
work
correctly
in
a
kubernetes
deployment.
B
There's
the
availability,
you
never
want
your
database
to
become
unavailable
and
you
never
want
to
lose
the
data.
How
does
wit
us
provide
availability?
Let's
say
you
were
just
running
my
sequel
without
kubernetes
and
you
have
a
master
replicas
configuration
if
the
master
goes
down,
it
requires
manual
intervention
to
either
bring
it
back
up
or
to
make
one
of
the
existing
replicas
a
master,
and
the
same
thing
applies
in
kubernetes.
B
B
What
we
do
in
witters
is
that
we
have
the
ability
to
take
backups
and
restore
from
backups,
and
you
backup
regularly.
So
if
a
master
goes
down,
you
fail
over
to
a
replica
and
you
bring
the
old
master
back
up
from
restore
it
from
a
backup
which
might
be
a
little
bit
behind
the
replicas
in
terms
of
what
transactions
have
been
applied
to
it,
but
it
will
connect
to
the
new
master
and
then
catch
up.
So
now
you
are
back
to
your
original
configuration
with
a
master
and
multiple
replicas
and
you
haven't
lost
any
data.
B
How
would
one
start
with
with
us?
Let's
say
you
already
have
an
existing
application
and
a
database
you
could
just
plug
with
us
in
and
put
it
in
front
of
the
database
between
the
application
and
the
database
and
without
even
sharding,
even
if
scalability
is
not
an
issue,
even
if
you
are
just
starting
out
and
your
traffic
is
not
a
lot.
Your
data
size
is
not
big.
You
still
get
a
whole
bunch
of
features
with
witters.
B
As
your
traffic
and/or
data
size
increases
you,
you
might
discover
that
all
of
your
data
doesn't
fit
into
one
instance
anymore,
and
now
you
have
to
start
splitting
it,
and
initially
you
might
want
to
actually
split
the
data
by
table.
So
you
want
to
move
some
of
your
tables
into
a
different
instance,
and
this
can
be
done
transparently
to
the
application.
The
application
never
needs
to
know.
What
is
the
physical
database,
where
the
data
resides,
everything
is
mediated
through
Vitti
gate
and
wheatie.
B
Eventually,
hopefully,
you
will
reach
a
point
where,
even
with
vertical
sharding,
some
of
your
tables
are
so
huge
that
either
they
don't
fit
into
and
optimally
sized
my
sequel
instance
or
you
start
noticing
performance
degradation
and
at
that
point,
it's
time
to
do
what
we
call
horizontal
shouting
and
horizontal
shouting
is
really
the
the
core
component
of
witters.
That
gives
you
the
near
in
finite
scalability
and
what
you
do.
B
What
happens
in
horizontal
shouting
is
that
the
same
table
is
split
across
multiple
instances
of
the
database
and
the
application
doesn't
need
to
know
that
vt
gate
will
route
queries
to
the
appropriate
shard
and,
if
necessary,
it
will
actually
do
a
scatter
gather.
It
will
route
queries
to
all
necessary
shards
and
combine
the
results
and
then
return
them
to
the
application.
B
B
A
All
right,
okay,
so
how
many
of
you
have
used
the
Vitesse
sharding
scheme
or
seen
the
Vitesse
lee
sharding
demo,
okay,
one
or
two
okay
then
be
ready
to
get
your
mind,
blown
so
I'm
going
to
go.
Actually
the
the
original
I
gave
a
tutorial
last
cube
con
about
the
full,
a
full
sharding
skier
sharding
thing
today,
I'm
going
to
show
you
an
improvement
that
you
made
to
Vitesse.
So
that's
what
I'm
going
to
talk
about.
So
this
new
feature
is
like
totally
bleeding-edge.
A
It's
like
about
90%
done,
which
means
that
in
the
next
10
years
we'll
get
the
other
10%
so
Oh.
As
we
deeply
explain.
There
are
basically
two
workflows
that
we
have
in
with
tests.
One
is
you
do
vertical
sharding,
where
you
split
move
tables
from
one
key
space
to
a
brand
new
one
and
the
other
one
is
horizontal
sharding,
where
you
split
a
key
space
into
multiple
parts.
But
then
people
have
come
and
asked
me:
hey
yeah!
A
This
is
all
great,
but
what,
if
I've
already
shard
it
and
then
there's
one
table
in
my
uncharted
key
space
and
I
want
to
move
it
to
my
sharded
key
space.
I
know
you
can't
do
that.
How
about
uncharted
2
uncharted?
Oh
sorry,
no
I
can't
do
how
about
sharded
to
Uncharted.
Why
would
I
even
want
to
do
that
right
and
my
personal
favorite
is
I
have
charted
my
database,
but
I
chose
the
wrong
key,
so
we
call
it.
The
regret
feature
regret
charting
it.
This
way,
I
wanted
to
do
it
the
other
way.
A
So
all
these
features
are
now
possible
in
with
us
using
V
replication,
but
we
actually
chose
a
different
approach
instead
of
actually,
instead
of
building
all
these
1015
workflows
that
can
possibly
exist.
What
we
have
done
is
componentized
the
portions
that
we
used
for
recharging
and
made
it
basically
scriptable
by
just
you
as
a
person,
so
which
is
what
I'm
going
to
demo,
but
we
actually
went
one
step
further,
so
this
V
replication
feature
is
not
only
usable
for
sharding,
it's
also
usable
for
multiple
other
things
that
people
haven't
even
thought
of.
A
So,
at
the
core,
what
we
replication
does
is,
it
can
materialize
anything
anything
means
a
group
of
tables,
because
my
sequel
has
only
tables
anywhere,
which
means
that
you
can
choose
any
source
key
space
into
any
Genki
space,
and
even
the
target
key
space
can
be
the
source
itself.
If
that
we
saw
your
desire
and
finally,
anyway,
this
is
the
part
where
the
coolest
thing
about
this
feature
is,
which
is
that
anyway,
means
that
you
can
specify
transformations,
which
means
that
I
can
say:
I
want
to
replicate.
Only
these
rows
or
I
want
to
replicate.
A
Only
these
columns
I
want
to
replicate
these
columns,
but
I
want
to
apply
the
following
transformation
expression,
and
how
do
you
specify
it
is
what
makes
it
powerful?
You
specify
that,
just
by
giving
a
select
statement,
which
is
the
representation
of
the
table
that
you
want
to
materialize,
which
is
why
we
call
it
materialized
views,
and
this
select
statement
can
be
basically
any
sequel
statement.
A
It
can
even
be
aggregations,
you
can
do
sums
and
counts,
and
with
this
will
materialize
your
table
aggregated
in
your
target
key
space,
which
means
that
there
are
many
analytics
for
clothes
now
that
you
can
efficiently
create
views
for
and
directly
hit
those
tables.
Unfortunately,
I
don't
have
time
to
show
all
those
features.
I
am
only
going
to
show
the
part
of
your
application
that
is
going
to
help
you
create
new
reshoring
workflows
as
you
desire.
Ok.
A
So
this
is
the
classic
demo
that
we
have.
This
tutorial
exists
in
witness.
If
you
go
to
the
Vita's
documentation,
it
walks
you
through
this
tutorial.
This
is
an
e-commerce
application
where
there
is
a
product
and
there
are
customers
placing
orders.
You
start
with
one
database,
the
commerce
databases,
product,
customer
and
order,
and
in
this
one
database
and
then
you
do
vertical
split,
move
customer
and
order
into
an
uncharted
customer
database,
and
then
you
reach
out
the
customer,
which
is
what
the
tutorial
does
its
most
people
have
gone
to
that
tutorial.
A
Nobody
has
seen
a
problem
and
if
you
need
help,
you
can
also
see
my
last
Q
con
presentation
about
this
today.
What
we
are
going
to
do
is
do
this
as
one
step
and
not
just
as
one
as
one
step.
We
are
not
going
to
use
any
pre-existing
workflows
that
we
test
has.
We
are
just
going
to
craft
this
with
our
own
bare
hands
and
make
this
reshoring
work.
Okay,
and
so
here
is
where
this
here's
our
starting
point-
that
is
the
Commerce
database
that
has
these
three
product
customer
and
order
table.
A
Don't
worry
about
those
sequence
tables?
Those
are
not
relevant
for
this
demo
assume
that
they
help
you
generate
IDs
and
the
magic
is
in
the
vita
gate.
There
is
metadata
in
vita
gate
for
vita
gate.
We
call
it
the
V
schema
or
the
Vita
schema
the
sharding
schema,
and
that
basically
says
product
customer
and
order
are
in
the
Commerce
database.
So
when
the
app
server
sends
a
query
to
vita
gate,
VD
gate
knows
I'll,
send
it
to
commerce,
because
that's
where
those
tables
are
so.
A
The
next
step
we
are
going
to
do
is
create
our
target
key
space,
pre
shard
it
we
are
going
to
create
a
user
database
user
key
space
which
is
chartered
80
and
80.
8
is
hexadecimal
it's
right
in
the
middle,
so
as
soon
as
you
create
this
key
space
and
you
create
customer
and
order
tables,
it's
called
see
order
because
order
is
a
key
word
in
my
sequel.
A
It
does
not
like
it
so
I
put
a
C
in
front
to
stand
for
customer
order,
so
you
create
these
tables
and
once
you
create
them,
vt
gate
is
going
to
get
confused
because
you
say
select
star
from
customer.
It
says
there
are
two
customer
tables:
there's
one
in
commerce
and
one
in
user.
What
do
I
do
with
it?
So
this
is
the
first
feature
of
free
sharding,
which
is
called
the
routing
rule
where,
if
you
see
at
the
bottom,
you
see
that
I'm
saying
customer.
A
A
The
next
step
is
the
magic
step
which
is
create
a
V
replication,
using
select
statements
and
basically
say
materialized,
customer
and
order.
Half
of
them
80
and
the
other
half
80
using
Vitas
sharding
scheme,
and
all
this
is
expressible
as
the
sequel
statement
and
I
will
show
you.
What
that
statement
is
nothing
else.
Changes
rules
are
remaining
the
same,
which
means
that
app
servers
queries
continue
to
go
to
commerce.
Eventually,
what
we
replication
is
going
to
do
is
catch
up
on
replication
and
all
the
data
in
commerce
is
going
to
be
present
in
user.
A
Also
for
customer
and
order,
and
the
last
step
is
the
cutover.
We
it's
actually
a
three-step
process.
We
go
blacklist
the
source
tables,
which
means
that
stop
accepting,
writes
and
then
wait
for.
The
second
step
is
wait
for
replication
to
catch
up
and
after
it
has
caught
up.
You
tell
me
to
gate.
Ok
now
you
can
start
sending
rights
to
the
new
key
space,
which
is
basically
an
update
of
the
routing
rules.
You'll
say
customer
now
goes
to
customer
customer
and
order
goes
to
customer
lured
order.
A
So
this
makes
sense
cool,
so
three
steps
and
the
best
part
of
it
is
you
can
craft
your
own
recharging
steps
using
just
these
three
basic
tools.
I
am
now
going
to
jump
into
the
demo
and
before
jumping
into
the
demo,
DT
was
nice
enough
to
build.
Build
me
a
we
test
cluster
here
using
the
planet-scale
operator.
A
You
can
bring
up
with
tests
using
help
charts
there
are
hand
charts.
There
is
a
width
s
operator,
that's
in
alpha
in
with
us
and
on
the
commercial
side
right
now
there
is
only
the
planet-scale
operator.
I
think
there
are
some
other
people
who
may
be
working
I.
Think
Rancher
Labs
may
be
working
on
something.
So
here
you
can
now
see
that
I
have
brought
up.
A
So
what
I've
done
is
in
the
interest
of
time,
because
parts
take
time
to
come
up,
I've
brought
up
all
the
parts
and
key
spaces
and
I'm
just
going
to
show
you
the
three
steps,
the
last
three
steps
that
are
involved
in
the
sharding.
So
here
is
the
Commerce
key
space
it
has.
Actually
it
has
actually
the
all
the
three
tables.
But
if
you
look
at
the
customer
key
space,
it
is
completely
empty.
A
It
has
nothing
I
just
created
shots,
and
if
you
look
in
VT
gate
this
is
the
V
schema
that
I
talked
about,
and
you
can
see
that
in
the
key
spaces.
Customer
is
not
even
listed
here,
because
it
has
nothing
and
you
can
see
that
see
order,
C
order
order,
product
and
customer
are
here.
Those
just
ignore
those
order
increments.
For
now
they
are
not
relevant
for
this
demo.
So
this
is
so.
This
basically
means
that
if
I
send
queries,
they
will
all
go
to
customer.
A
So
this
is
the
and
we
will
watch
this
VC
much
change
as
we
progress
forward
in
the
demo,
and
at
this
point
that
is,
let
me
see
if
somebody,
oh
somebody
so
I
did
send
the
queries
myself.
Okay,
so
here
is
our
awesome.
Ecommerce
app
awesome
UI,
but
we
all
have
to
pretend
this
is
basically
you
have
to
imagine.
If
you
want
to
create
a
product,
you
go
here
to
the
left
and
then
enter
your
SKU.
If
you
want
customers,
you
just
enter
your
name
in
there
and
you
can
enter
this
order
info.
A
So
this
website
is
publicly
available.
You
go
to
recharging
dot.
Planet-Scale
labs,
calm
and
you
are
allowed
to
spam.
It
let's
see
if
we
can
take
it
down
and
while
you
spam
it
I'm
going
to
do
the
Rashard
and
we'll
see
if
we
lose
any
data
or
whether
we
shouting
falls
apart.
Alright,
so
go
ahead
and
start
generating
load
no
load
yet
okay.
So
while
we
do
this,
I
am
going
to
show
you
my
scripts
303,
oh
yeah,
restarting
dot,
planet-scale
labs
calm.
A
So
here
is
my
script
number
one,
which
is:
do
we
going
to
do
this
step,
which
is
this
one?
Create
those
V
schemas
and
the
routing
rule
set
up
the
routing
rules
right
so
I
copy
first
I
copy
the
schema
from
the
source
to
the
target,
and
you
can
see
the
routing
rules.
We
says
I'm
going
to
say:
customer
goes
to
commerce
store,
customer
and
order
goes
to
commerce
or
a
lot
order
and
then
I
apply.
The
V
schema
so
I'm
going
to
run
the
script.
A
The
script
has
been
run
and
now,
if
you
go
see
the
schema
here,
you
can
see
that
customer
has
appeared,
but,
more
importantly,
at
the
top,
you
see
the
routing
rules,
just
as
we
explained,
and
now,
let's
see
what
happens
here.
Oh
somebody
actually
has
so
now,
so
this
has
not
changed
because
the
queries
are
continuing
to
go
to
commerce.
So
if
you
look
at
the
query
plans,
you
can
see
that
this
select
statement
still
going
to
commerce.
A
Basically,
all
your
queries
are
going
to
commerce
database.
So
VT
gate
shows
you
on
the
fly.
You
can
look
at
mitigate,
show
me
your
the
queries,
you're
executing
and
how
you
are
executing
them.
So
this
is
a
debug
query
plans
page,
and
so
let's
see
if
somebody
has
entered
anything
ooh
someone's
spamming
awesome.
So
the
next
step
is:
do
the
V
replication
part,
which
is
where
is
this
the
next
step
here,
the
V
replication?
So
that
is
actually
it's
a
very
simple
script:
I
type
it
myself.
C
A
Actually,
it's
actually
very
hard.
The
reason
why
this
script
looks
very
complicated
is
because
it
is
complicated.
It
is
actually
a
batch
script
that
has
a
SQL
statement
inside
that
SQL
statement.
There
is
a
proto
buff
and
inside
the
Prada,
but
there
is
another
SQL
statement.
So
how
do
you
represent
that
in
in
bash?
In
more
importantly,
how
do
I
create
a
command
like
this?
Well
fear,
not
the
result.
A
What
I
have
is
a
program
called
V
represent,
go,
and
what
this
does
is
allow
you
to
just
put
your
parameters
in
and
run
this
program,
and
it
will
generate
you
command
for
you.
So
you
can
see
the
select
statements
here,
select
star
from
customer
where
the
customer
isn't
Kirin,
so
you
basically
specify
your
recharging
workload
using
these
select
statements
and
then
run
go
run
this
and
it
generates
this
code.
A
He
does
run
and,
as
you
can
see,
nothing
would
change,
because
this
is
basically
an
offline
process.
The
original
database
is
still
accepting,
writes
and
nothing
has
changed.
Okay,
the
last
step,
which
is
the
cutover.
So
this
is
where
everything
will
change
and
we'll
see
what
that
is
305,
and
this
is
actually
you
can
actually
manually
do
this
do
this,
but
you
you
have
to
do
this
very
fast
because
you
are
going
to
stop,
writes
on
the
source
and
then
wait
for
application
to
catch
up
and
then
enable
writes
on
the
target.
A
So
you
don't,
you
want
minimal
downtime,
so
I
wrote
a
quick
script
internally
in
with
test
what
what
I'm
planning
to
do
is
actually
make
it
available
in
a
customizable
way
for
anyone
to
use
as
a
cut
over.
So
if
you
run
this
command,
306
I
believe
what
is
it
three
or
five
three
or
five
boom?
It's
over.
You
have
cut
over
now
to
the
new
traffic.
Let's
see
if
site
still
works,
okay,
it
works
and
what's
the
proof
that
we
have
even
cut
over
right,
I
may
be
lying.
A
So,
let's
see
what
VD
gate
has
to
say
about
the
plants
the
select
is
now
going
to
customer.
It
was
going
to
commerce
before
now.
It's
going
to
customer,
you
can
see
that
the
customer
queries
are
now
going
to
customer
product.
Query
will
continue
to
go
to
commerce
and
everything
else,
so
we
have
now
actually
officially
cut
over,
which
concludes
the
demo.
The
best
part
of
this
is
you
can
use
these
to
recharge
from
anything
to
anything.
There
are
actually
a
lot
more
workflows
that
you
can
do
with
this.
A
You
can
actually,
if
you
go
to
the
Vitesse
documentation,
click
on
documentation,
scroll
down
here
in
advance,
which
is
there's
a
real
application
operators
guide-
and
here
it
talks
about
all
the
other
things
you
can
do.
You
can
do
materialized
views.
You
can
do
real
time
roll-ups,
you
can
do
back
filling
of
look
of
indexes
schema
deployment.
There
is
a
whole
bunch
of
workflows
that
you
can
now
implement
and
use
within
with
this.
So
that
concludes
our
demo
and
you
have
any
questions.
A
A
A
Correct
so
the
question
is:
when
you,
when
you
do
the
recharging,
do
you
require
twice
the
storage
and
the
answer
is
yes,
so
while
you
are
doing
the
recharging
process,
you
will
have
to
allocate
space
for
your
target
key
space.
At
that
time,
you
pay
for
twice
the
storage.
Typically,
a
recharging
may
take
you,
depending
on
your
data
size.
It
can
take
your
day
or
it
can
take
you
a
week.
So
during
that
time
you
pay
for
the
added
storage.
A
A
A
A
So
the
question
is
how
much
downtime
is
involved
in
recharging
practically
zero,
because
the
entire
recharging
process,
as
you
saw
like
when
I,
was
doing
the
demo.
You
are
all
spamming,
the
the
website
and
was
still
accepting,
writes
this,
because
the
whole
recharging
process
is
actually
offline.
The
only
time
when
you
would
see
downtime
is
with
during
the
cutover
which
I,
which
in
this
case
happened
instantly,
but
typically
it
happens
in
a
few
seconds,
so
that
is
so
for
a
recharging.
A
Essentially,
the
downtime
you
see
is
for
five
seconds,
maybe
and
it's
also
extremely
safe,
which
means
that
if
halfway
through
the
recharging
fails,
you
can
say,
oh,
let's
go
back
to
where
we,
where
you
can
do
that
after
you
have
done
the
recharging.
You
say,
I
may
change
my
mind.
I
may
have
to
go
back
after
a
day,
in
which
case
you
can
reverse
the
veer,
application
and
rewrite
the
what
you
write
in
the
target
back
to
the
source.
A
A
Oh
yes,
so
the
question
is:
when
you
are
doing
a
short
merge,
is
it
possible
to
have
the
same
data
on
multiple
charts,
and
in
that
case
your
merge
will
fail.
So
it
is
your
responsibility
to
make
sure
that
the
shards
have
distinct
data
and
there
are
actually
indexes
in
the
tests
that
allow
you
to
specify
and
enforce
them.
A
If
you,
if
you
so
desire,
you
can,
for
example,
if
you
make
the
primary
windaq
same
as
the
primary
key,
then
uniqueness
is
enforced
or
you
can
create
a
unique
lookup
index
which
can
enforce
uniqueness
of
at
least
one
of
the
columns
in
those
rows
which
ensures
that
the
rows
are
all
distinct,
distinct,
in
which
case
the
merge
will
succeed.
Yeah,
yes,.
B
Have
two
ways
of
doing
backups:
one
is
where
we
just
copy
all
the
files,
and
that
requires
downtime
on
whichever
instance
you
are
using
to
do
the
backup,
so
that's
only
a
loved
on
replica
type
instances.
You
don't
allow
it
on
master.
Unless
it's
an
emergency
situation,
we
also
support
perkiness
extra
backup,
so
you
can
do
an
online
backup
using
extra
backup.
B
A
B
So
we
don't
actually
have
a
coordinated
back
up
across
shards.
You
can
back
up
a
specific
instance
or
you
can
back
up
a
shard,
but
this
logic
of
doing
a
coordinated
back
up
across
shots
doesn't
exist
in
with
us
today.
I
think
we
are
out
of
time.
I
will
be
at
the
CN
CF
answer
bar
this
afternoon
at
1:30.
If
people
would
like
to
come
by
and
ask
questions-
and
we
are
also
available
after
the
talk.