►
From YouTube: GitLab 15.0 Kickoff - Enablement:Database
Description
Kickoff for the Database Group for the GitLab 15.0 release
Planning issue: https://gitlab.com/gitlab-org/database-team/team-tasks/-/issues/247
Database Group Past Kickoff Videos: https://youtube.com/playlist?list=PL05JrBw4t0KqP3MYrcoQHrqPUqn_jJZSN
Presentation by: Yannis Roussos, Sr. Product Manager, Memory and Database Groups
A
Okay,
so
before
we
continue,
let
me
give
you
a
very
high
level
overview
of
what
we
are
doing
on
the
database
group,
so
our
core
mission
is
to
build
the
application
code.
The
tools
and
frameworks
that
allow
every
gitlab
feature
to
interact
with
the
database
in
the
most
reliable
and
performant
way
possible.
A
We
also
build
tools
and
product
features
that
enable
any
gitlab
team
member
to
efficiently
develop
code.
Again
that
interacts
with
the
database
test
against
the
production
grade.
Data
sets
and
make
informed
data-driven
decisions
before
shipping
any
update
to
the
gitlab
product,
so
more
or
less
that's
it.
So
let
me
start
with
our
planning:
it's
gitlab
15.0,
it's
a
new
major
release.
We're
always
super
excited
at
gitlab
when
we
have
a
new
major
release.
Of
course,
the
work
of
the
database
group
is
behind
the
scenes.
A
So
as
long
as
we
are
doing
our
work
correctly,
all
github
instances
benefit
from
what
we
from
our
updates
without
having
to
do
anything.
But
before
I
start
with
our
top
priorities,
let
me
tell
you
about
the
one
thing
that
the
gitlab
insta:
some
administrators
must
be
aware
of.
So
in
15.0
we're
deprecating
postgres
12.,
so
we
are
going
to
keep
supporting
phosphorus
12
as
the
minimum
version
of
postgres
for
the
whole
15
hitler
15
cycle.
A
A
So,
let's
go
to
our
top
priorities
for
15.0.
First
of
all,
it's
bad
background,
migrations,
so
background
migrations
are
the
way
that
we're
executing
very
large
updates
in
gitlab.
So
if
you
want
to
update
a
few
thousands
of
records,
you
can
do
so
in
line.
So
during
an
upgrade
during
a
migration,
you
can
update
them
in
a
few
seconds
and
you're
done,
but
when
we
want
to
update
millions
or
even
billions
of
records,
we
do
so
in
the
background
by
run
background
migrations.
A
Those
are
asynchronous
jobs
that
run
the
background
and
update
perform
the
updates
as
secretly
without
affecting
the
git
resistance.
So
everybody
can
keep
on
using
gitlab
while
they
update
continues
and
we
have
done
so
in
the
past
we
have
extended
the
way
rails
works
with
data
migrations,
and
now
we
are
building
a
new
framework.
We
call
it
the
past
background
migrations
which,
more
or
less
adds
a
lot
of
new
features
towards
availability,
reliability
of
those
data
operations
of
those
background
migrations.
A
So
mainly,
what
we
are
doing
with
this
framework
is
that
this
is
a
framework
that
monitors
a
production
database,
cluster
and
dynamically
adapts
in
real
time
to
changes
changing
conditions.
That
means
that
we
can
see,
for
example,
that
there
is
low
traffic
and
what
we
can
increase.
How
many
records
we
update
per
minute?
We
have
seen,
for
example,
gitlab.com
migrations
during
during
very
low
traffic
times
to
go
up
and
update
up
to
a
million
records
per
minute.
A
In
contrast
in
contrary,
if
we
see
that
there
are,
there
is
a
lot
of
traffic
we
throatly
down.
So
instead
of
updating
a
million
go
to
500,
000,
100,
000
and
down
down
down,
it
also
offers
a
lot
of
additional
features
that
are
very
important
for
both
gitlab.com
and
self-managed
instances,
because
it's
a
framework
that
see
if
there
are
problems,
finds
failed
jobs
and
retries
them
breaks
them
to
make
them
easier
to
execute
and
much
more
so
in
15.0.
A
Our
big
target
is
are
the
general
availability
of
the
framework,
so
we
plan
to
release
it
in
internally
so
that
other
teams
can
start
using
it
as
the
primary
way
of
doing
background
migrations.
We're
going
to
deprecate
the
old
way
of
doing
those
migrations
and
work
towards
making
making
it
during
the
next
milestones.
The
only
way
of
performing
background
migrations.
A
A
Thing
if
we
wanted
that
adds
a
lot
of
monitoring
of
the
production
cluster,
so
we
are
going
to
monitor
everything
we
can
and
get
early
signals
that
will
warn
us
that
something
is
not
going
well
in
the
production
and
I'm
not
talking
about
high
draft.
Now,
I'm
not
talking
about
incidents
or
something
breaking
or
whatever.
A
In
those
cases.
We
have
seen
that
those
very
long,
very
large
migrations
can
work
against
us
because
we
have
the
incident,
we
have
problems
and
then
you
have
a
background
process
trying
to
update
the
records
and
things
get
worse
and
worse
or
worse.
So
in
15.0
we're
going
to
add
a
few
very
important
signals.
A
A
This
is
called
auto
vacuum
and
this
is
very
important
and
can
cause
problems,
because
when
postures
does
so,
if
you're
in
a
live
system-
and
you
have
inserts
and
queries-
and
you
have
autofocus
fixing
the
table
and
at
the
same
time
you
come
with
a
background.
Migration
start
updating
millions
of
records
that
can
cause
problems.
So
the
first
thing
for
us
is
to
monitor
whether
or
not
the
vacuum
is
running
and
if
it's
running
on
a
table,
stop
the
migration
wait
and
then
restart.
A
That
will
be
a
great
step
forward
for
reliability
in
gitlab.
A
second
thing
is
monitoring
the
patronia
objects.
Objects
is
the
way
we
we
monitor
the
health
of
the
system
in
general
as
a
at
the
whole.
So
we
monitor
our
objects
is
how
what
percentage
of
queries
are
up,
take
more
than
50
milliseconds,
with
100
milliseconds
as
an
acceptable
limit.
A
So
if
we
see
that
going
below
99,
that
means
that
something
is
happening
so
normally
in
gitlab.com.
We
we
have
that
at
99.9
percent,
so
99.9
percent
of
the
queries
executing
less
than
50
milliseconds.
So
if
we
see
this
going
below
99
percent,
that's
a
great
signal
that
level
tells
us.
You
know
what
that
production
database
has
issues,
stop
the
migration
and
wait.
A
A
A
B
A
So
the
the
final
thing
is
that
if
we
see
so
the
wall
rate,
the
right
ahead
load
rate
is
a
great
signal
to
to
see
how
many
updates
you
have
in
the
database.
This
is
the
easiest
way
to
see
it
and
we
track
that.
So
if
we
see
that
going
above
a
a
threshold,
that
means
that
even
if
we
don't
know
it
yet
as
an
early
indicator,
we
know
that
the
database
is
stressed
out.
A
So
so
we
know
that
if
we
see
the
right
ahead
low
rate
going
above
that
threshold,
we
we
can
throttle
down
the
migration
so
that
we
release
some
pressure
from
the
database
from
the
database
cluster.
It's
we
are
not
going
to
stop,
but
it's
an
early
indicator,
let's
back
off
a
little
bit
and
and
let
the
system
breathe.
A
Finally,
another
thing
that
we're
working
on
is
pausing
the
migration
when
the
rather
headlock
queue
that
is
pending
archival
crosses
the
threshold.
That
means
that
a
lot
of
logs
have
gathered
a
lot
of
lobe
segments
have
not
been
archived.
This
is
very
important.
That
means
that
something
is
not
working,
maybe
in
the
archive
process,
or
you
have
too
many
logs.
If
you
see
that
going
above
a
threshold,
this
is
a
an
availability
risk,
so
we
will
pause
the
migration
and
our
final
top
priority
is
the
automated
database
testing.
A
A
We
run
a
pipeline
that
tests
that
update
directly
against
the
production
server,
a
clone
of
the
production
server,
of
course,
but
it's
it's
it's
a
great
feature
for
us,
because
we
can
preemptively
find
difficult
to
test
problems
because
we
test
all
of
this
against
a
snapshot
of
the
database,
a
clone
that
has
that's
it's
no
more
than
a
few
hours
back,
so
we
have
done.
We
have
completed
our
support
for
regular
migration,
post
migrations,
and
now
we
are
adding
support
for
background
migrations.