►
From YouTube: 2022-02-28 Database Scalability WG Weekly
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
it's
the
time,
so,
let's
get
started.
Welcome.
Everyone
today
is
february
28th.
This
is
the
database
scalability
working
group,
weekly
update
and
I'll
get
started
from
the
again.
The
first
item
is
a
significant
update
since
the
last
meeting
and
first
one
is
first
bullet
number.
Eight
is
from
the
update
from
the
sharding
group,
so
very
excited
to
to
acknowledge
that
the
decomposition
run
a
fully
decomposed
pipeline
and
it
turned
green.
This
is
actually
a
precursor
of
the
phase,
seven,
the
last
phase
of
rollout
success.
A
So
this
is
a
precursor
we're
still
not
there
yet,
but
it's
really
great
to
see
that
we
can
run
the
fully
decompose
the
pipeline,
and
this
is
essentially
demonstrates
that
we
can
already
run
gitlab
with
two
completely
different
databases
and
our
solution
works
as
design,
so
the
imr
is
now
merged,
although
it's
just
a
couple
lines
change,
but
there's
tons
of
work
behind
it.
So
so
good
news
to
share
any
questions.
A
Okay,
then
move
on
to
next
a
few
items
from
the
starting
group
so
phase
four.
The
next
step
is
documented
and
we
are
planning
to
tackle
this
in
a
staging
environment.
First,
that's
the
first
road
rod
of
this
phase.
Four,
however,
we're
yielding
the
priority
to
fix
reproduction
deployment
right
now,
because
we'll
mention
that
later
then,
we
need
to
think
about
disaster
recovery.
The
mechanisms
and
the
strategy
and
task
force
was
formed
for
this
brainstorming.
A
The
task
force
is
consists
of
camino,
fabian,
jose
raphael
and
gonzalo,
and
then
last
item
for
from
the
shutting
group
is
performance.
Concerns
surfaced
for
a
fixed
physics
issue
actually
and
the
the
viability
of
the
the
current
approach.
A
So
the
problem
is,
is
the
deep
hierarchy
of
groups
that
caused
the
performance
problem
and
progress
is
being
made
and
now
targeting
14.9
any
questions.
B
Jen,
let
me
the
disaster
recovery
issue
geos
being
talked
about
in
there.
I
didn't
see
it
mentioned
explicitly
in
the
issue.
B
A
Field,
this
is
more
about
operation
or
how
we
have
a
strategy
and
a
mechanism
to
to
react
to
some
disaster
in
the
in
the
production
environment
like
how
we
can
restore
the
service
and
how
we
can
recover
the
data.
If
something
happens,.
C
C
You
know
that
should
be
fairly
quick,
but
we
have
to
establish
you
know
if
something
goes
wrong
in
that
process.
What
do
we
do?
You
know
to
go
back,
you
know:
how
do
we
recover
from
this.
B
D
Yes,
the
the
idea
is
like
when
we're
gonna
be
deploying
we're,
definitely
gonna,
be
doing
some
kind
of
validation,
phase
with
testing,
but
us,
but
we
also
gonna
open
a
doors.
D
So
if
I
we
split
databases,
mainly
the
ci
and
we
we
see
error
or
in
fifth
minute
after
the
deployment,
but
our
rollback
window
is
defined
by
30
minutes
the
week,
the
rollback.
Now,
if
we
know
about
what
type
of
data
we
lose,
probably
some
kind
of
ci
traces,
some
some
other
machine
generated
data
and
the
question
gonna
be
like
I
mean
before
when
we
define
this
disaster
recovery
plan.
D
How
are
we
are
willing
to
lose
data
to
speed
up
iteration
of
rolling
out
changes,
because
we're
gonna
be
deploying
that,
probably
in
that
time,
there
is
like
there
is
amount
of
the
traffic
we're
gonna
be
defining
the
times
the
windows
for
this,
so
we're
gonna
be
actually
evaluating
risk
versus
benefit
versus
the
cost
associated
and
the
likelihood
of
this
occurring
to
figure
out
actually
like,
basically
our
willingness.
D
If
we
are
finally
flew
some
amount
of
the
machine
generated
data
or
if
we
are
not
fine
and
what
is
the
criteria
that
would
trigger
the
rollback?
What
kind
of
metrics
to
look
at
this
is
exactly
the
type
of
the
disaster
recovery.
It's
right
after
the
deployment
of
the
axe
for
the
composition
to
the
production.
B
Yeah
I
like
defining
all
that
stuff
ahead
of
time.
That's
that's
really
smart
and
if
you
need,
if
you
need
a
you
generate
a
plan
and
you
want
someone
to
kind
of
look
at
and
punch
holes
in
it.
I
recommend
jerry,
I
think,
is
on
the
call
to
you
know
kind
of
see
if
he
sees
any
potential
gaps.
D
Yes,
because,
like
I
think
in
the
end,
we
definitely
gonna
give
our
recommendation,
but
it's
really
like
probably
product
slash,
diary,
slash
executive
decision,
what
we
actually,
how
you
want
to
tackle
that
given,
given
the
anticipated
likelihood
scenario
occurring
and
the
risk
associated
with
it.
So
we
definitely
gonna
be
extensively
discussing
that,
to
figure
out
the
best
approach
for
all
of
us.
E
Yeah
there
is
an
issue
in
in
the
infrastructure
queue
that
we
opened
to
participate
in
this
as
well.
I
don't
have
it
handy.
I've
been
looking
for
it,
ken
is
driving
that,
but
yes
do
add
me
to
that
workforce.
E
C
E
Yeah,
the
difficult
part
of
this
conversation
is
going
to
be
deciding.
What
are
the
acceptable
risks
right,
so
we
can
think
of
strange
things
that
can
happen,
but
just
throw
in
the
lines
of
when
we
the
decision
to
move
forward
or
roll
back.
We
need
to
figure
out
what
those
stressfuls
are,
and
those
are
the
really
important
ones.
Luckily,
we've
done
this
in
the
past
with
the
gtp
migration,
so
we
have
some
prior
art
to
go
back
to
to
at
least
guide
how
we're
gonna
think
about
this
problem.
C
Yeah,
I
think
my
my
preference
would
be
you
know
we
think
about
all
of
the
possibilities
ahead
of
time,
that
we
make
a
recommendation
so
like
this
is,
I
think
what
we
should
do,
but
there's
always
going
to
be
risk
associated
with
it,
and
this
is
what
eric
can
sit
at
some
point
and
other
executive
stakeholders
need
to
understand
and
then
say
like.
Yes,
this
is
acceptable
or
we
need
to
actually
do
something.
B
Different
right
and
the
the
risk
is
the
severity
of
something
were
to
happen
by
the
multiplied,
by
the
likelihood
that
it's
going
to
happen.
It
can
give
us
both
those
things.
It's
easier
process.
A
As
far
as
I
know,
there
is
just
one
more
issue
remaining
for
for
phase
four
from
the
for
the
ops
team,
so
they're
working
on
that
and
on
the
dev
team,
all
the
facebook
issues
were
resolved,
so
there
are
still
physics
issues
outstanding
in
both
ups
and
the
depth,
but
we
can
wait
a
four
bit
time
a
bit
more
time
and
is
steve
here
for
infrastructure,
update,
nope,
okay,
I'll
follow
up
offline
with
steve,
but
we
do
have
a
few
items
below
here.
A
Moving
on
to
the
review
roll
out
of
pro
pro
progress,
our
confidence
level
of
the
timeline
still
remains
like
fifty
percent,
I
have
two
bullets
here:
development
outstanding
issues
continue
trending
down
and
the
confidence
level
is
high.
On
the
other
hand,
the
deployment
is
behind
so
I'll
see
the
risks
below
in
bullet
four,
but
overall,
our
confidence
level
remains
unchanged
at
fifty
percent.
A
Okay,
then
the
chart
is
here
showing
our
issues
burn
up
or
you
can
see
the
green
line.
The
the
green
line
is
actually
the
the
remaining
outstanding
issues,
so
it
continues
to
drop
from
development
perspective.
A
Okay,
then,
the
risk
section
really.
We
have
two
risks
here.
The
first
one
is
the
primary
pg
cluster
reboot,
that
is
a
blocker
to
our
phase
three
production
deployment
and
the
deployment
already
was
a
two
weeks
already.
So
I'm
asking
if
there
is
a
new
eta
of
the
reboot
so
that
we
can
move
forward
with
to
the
production
deployment.
E
Yeah,
our
follow-up
with
ken
actually
was
the
squad
lead
for
the
database,
and
I
know
that
there
was
a
change
issue
submitted
for
last
thursday
to
do
this
and
for
some
reason
it
was
cancelled.
I
I
don't
have
the
details
so,
but
the
ken
should
know
when
this
is
going
to
happen.
Yeah.
A
Thank
you.
Thank
you
gary
also,
thank
you
for
being
ken
and
the
next
one
actually
is
a
request,
so
jose
actually
suggested
having
a
dedicated
sre
moving
forward,
because
there
is
a
load
in
backlog
now,
and
there
is
plenty
of
deployment
tasks
we
can
work
on
and
that
will
be
a
lightly
sustainable
workload
moving
forward,
so
it's
better
to
have
a
dedicated
sre
to
ride,
along
with
the
dvres,
so
I'll
also
raise
to
stephen
ken
on
this.
Thank
you
jerry
for
your
suggestion.
A
Okay,
moving
on
to
the
last
bullet
is
the
end
of
the
month,
so
review
the
timelines,
basically
repeat
what
we
are
looking
for:
help
from
infrastructure
the
phase
three
production
deployment
is
behind
the
schedule,
so
we'll
continue
to
work
on
that
and
also
phase
four
staging
deployment
is
basically
we
can
start
now.
There
is
just
one
two
more
outstanding
issues,
but
those
are
the
corner
cases
if
we
can
and
it
will
will
not
slow
down
the
phase
three
production
deployment.
A
We
can
start
to
work
on
that
now
so
fabian
you
want
to
verbalize
your
your
comment.
C
Yeah,
it's
minor.
We
still
have
a
few
outstanding
or
like
two
or
three
issues
in
review
they're,
going
to
close
very
soon
we're
also
already
deploying
the
phase
450k
reference
architecture.
So
it's
looking
pretty
good.
We
are
we're
quite
happy
about
the
progress
that
the
team
has
made.