►
From YouTube: GitLab 14.3 Kickoff - Enablement:Sharding
Description
Kickoff for the 14.3 release for the Sharding group.
Planning issue: https://gitlab.com/gitlab-org/sharding-group/group-tasks/-/issues/2
A
Before
I
go
into
the
specific
items,
I
would
like
to
call
out
that
I
issues
that
have
to
do
with
the
availability
and
performance
of
our
github.com,
offering
so
called
info.
Dev
issues
take
priority
in
this
milestone.
So
if
there
are
any
specific
reports
that
we
get
or
any
specific
corrective
actions
we
need
to
take,
then
those
will
be
addressed
as
soon
as
possible
to
ensure
that
gitlab.com
remains
stable.
A
A
We
are
no
longer
able
to
easily
scale
vertically
by
buying
larger
service,
and
so
we
need
strategies
to
scale
our
database.
Further
to
ensure
that
we
can
continue
to
grow
and
we're
not
experiencing
any
performance
related
degradations
and
so
as
a
first
step
to
to
this
we're
actually
decomposing
gitlab's
database.
So
this
is
on
the
way
to
sharding.
That's
not
really
sharding
itself.
So
when
I
say
decomposing,
what
we're
trying
to
achieve
is
we
are
taking
a
part
of
our
database.
A
First,
and
as
I
said,
you
know,
ci
actually
accounts
for
around
yeah
50
of
the
rights,
so
by
moving
them
we
can
really
reduce
the
overall
amount
of
rights
on
a
single
database
and
what
are
we
doing
in
14.3?
Let
me
just
collapse
this.
If
I
can
do
it
there,
we
are
so.
The
first
thing
to
know
is
like
if
you're
specifically
interested
in
a
holistic
overview,
go
check
out
this
epic
6168.
A
The
work
items
here
cover
a
wide
range
of
activities.
Not
all
of
them
are
being
pursued
by
the
shrine
group
themselves.
We
support
all
of
those
efforts
but,
for
example,
there's
work
to
fix
security
features
or
specific
features
in
enablement.
They
are
fanned
out
and
they're
all
in
this
epic.
You
can
see
here
so
there's
a
ton
of
work
that
is
actually
going
on.
That
is
not
to
do
directly
done
by
the
sharding
group
itself.
Our
work
is
primarily
focused
on
supporting
many
databases
and
the
decomposition
of
the
ci
tables.
A
A
A
A
I
left
it
in
because
it
is
one
of
the
things
that
we
discussed
earlier,
but
it
may
actually
be
something
that
we
may.
We
may
do
at
a
later
point
in
time
if
at
all,
but
I
wanted
to
highlight
it-
it's
it's
essentially
important
to
define
specific
boundaries
between
features
and
by
using
the
specific
structure
that
may
become
easier.
But
again
we
may
punt
on
that.
A
The
other
items
that
we
are
looking
into
is
sort
of
specific
to
the
ci
tables.
So
one
one
of
the
things
that
I
would
like
to
highlight
here
is
we
now
that
we
actually
will
have
a
separate
database
for
ci.
We
we
want
to
be
able
to
actually
create
that
database
in
our
continuous
integration
pipelines.
A
Another
thing
that
we
we
need
to
do
is
to
investigate
how
two-phase
commits
can
actually
like
work
or
like
how
we
how
we
handle
them,
because
we
may
want
to
forbid
this
entirely
and
there's
a
bit
of
discussion
on
how
we
can
actually
do
this
and
what
the
impact
of
that
is.
So
this
is
something
that
will
continue
in
14.3
as
well
yeah.
So,
on
a
high
level,
we
are
continuing
to
work
on
many
specific
items
for
supporting
many
databases
and
then
for
decomposing.