►
From YouTube: 2021 07 21 APAC Sharding Group Sync
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
B
B
B
Okay,
I
think
I'm
yeah
pat
pat,
wants
to
be
involved.
I
think
okay,
should
we
start
chances,
does
shouting
plan
to
take
care
of
ci
issues,
or
do
we
want
yeah
to
take
care
of
it?
C
Yeah,
I
think
it's
not
feasible
that
we
take
care
of
basically
all
issues
that
come
out
of
this
there's
just
gonna
be
too
much
work.
I
think.
A
I
think
there's
also
the
importance
of
education
too,
because
if
we
just
tackle
too
many
things
ourselves,
then
the
other
teams
may
not
actually
understand
what
we're
doing
and
they
may
be
making
concurrent
changes
that
cause
problems
for
us
and
in
general,
they
just
need
to
understand
the
architecture,
especially
the
ci
team
is
going
to
need
to
understand
the
architecture.
D
I'm
actually,
I
talked
like
with
zagos
recently
about
like
the
ci
issues
and
basically
like
our
plan
is
like.
Let's
see,
I
think,
gonna
be
doing
most
of
them
with
us,
helping
in
some
cases
and
kind
of
learning
as
well
like
how
to
do
it,
and
maybe
like
really
like
our
effort.
There
would
be
more
about
helping
and
documenting
how
to
solve
that,
because
this
is,
I
think,
pretty
important
for
the
rest
of
the
team
for
the
rest
of
the
github.
A
Should
we
have
a
place
where
we
have
start
documenting
patterns
because
there's
a
bunch
of
them
from
issues
that
I've
already
done
where
it's
like?
Okay,
the
pattern
here
is
out
of
project
id
column
and
denormalize.
The
data
with
a
migration
and
the
pattern
here
is
remove
this
joint
because
it's
actually
a
redundant
joint
and
so
on.
What
would
be
a
good
place
to
put
these
patterns
down
just
in
dots?
We
could
put
it
in
the
handbook,
but
maybe
that'll
be
too
slow
to
update
compared
to
an
issue.
D
D
I
mean
like
because,
like
for
example,
we
still
have
these
like
ones
about
like,
if
you
fetch
ideas,
how
many
you
fetch
them.
I
think
we
didn't
resolve
that
yet
how
to
solve
that.
But
maybe
I
don't
know
like
just
getting
having
like
the
issue
or
just
like
putting
like
example
of
the
problem.
Maybe
we
don't
yet
like
how
to
solve
that
or
like
proposing
some
solution
for
that,
because,
like
I
think
we
have
like
a
different
class
of
the
problems,
one
like
on
breaking
cross
noise.
D
Second,
one
gonna
be
related
to
handling
many
databases
from
the
migration
point
of
view
and
like
just
connecting
things
so
basically
and
like
dealing
with
my
database.
So
this
is
also
kind
of
like
what
you
are
weak
now
focusing
on
and
the
third
one
is
the
third
one.
D
D
Second,
one
is
how
to
deal
like
with
many
databases
supported
in
the
application
and
like
what
the
consequences
it
has,
and
the
third
part
is
really
like
how
to
deal
with
the
foreign
keys
and
relations
and
and
removal
of
the
entries.
This,
I
think,
like
the
three
main
aspects
that
we
need
to
document.
A
Okay,
so
I
think
we
just
extend
the
docs,
the
tong
added
then,
and
we
just
add
headings
for
the
different
topics
you
talked
about.
Foreign
keys,
I
think,
was
there's
already
an
issue
that
somebody
in
the
team
will
pick
up
at
some
point
to
do
that,
and
I
can
probably
add
the
cross-joint
examples
that
I
have
some
real
examples.
B
B
Okay,
fabian
is
the
next
point.
I
think
lots
of
responded
to
that
already
so.
D
Yes,
I'm
kind
of
like
wondering
like
there
is
like
a
lot
of
confused
stuff
that
we're
working
on
what
is
like
your
perception
of
like
how
we
are
doing
on.
Unlike
on
this
complex
project,
like
anything.
C
I
can
start
I
mean
I
think,
overall,
we're
sort
of
slowly
ramping
up.
I
I
think
my
main
concern
is
that
from
sort
of
happen,
management
like
we
started
shouting
then
became
decomposition
now,
there's
these
concerns
about.
Oh,
what
about
shopify
parts?
What
about
regions?
Basically,
all
these
extra
concerns
are
added
and
it
is
somewhat
understandable,
but
at
the
same
time
you
basically
end
up
with
like
a
a
always
growing
scope
that
you
have
to
take
into
account.
C
It
just
becomes
a
little,
I
think,
confusing
and
difficult
to
turn
like
okay.
What
what
are
we
actually
eventually
supposed
to
deliver
at
this
point,
because
it
seems
the,
I
would
say,
the
desires
sort
of
keep
changing.
A
One
of
the
things
I
was
starting
to
notice
is
maybe
that,
as
a
team,
we're
being
forced
to
be
very
agreeable
with
each
other
in
order
to
present
like
a
unified
front
towards
senior
leadership
with
the
company,
because,
like
we're
trying
to
convince
them
of
a
particular
path
that
we
want
to
go
down
and
so
we're
working
to
like
constantly
have
a
unified
narrative,
and
this
may
be
creating
the
impression
that
we
don't
have
enough
disagreement
in
our
team.
Are
we
not
challenging
each
other
enough
in
the
team?
A
D
A
I
can
I
can
write
this
down
myself,
but
one
of
the
things
that
I
observe
is
that
when
you
have
the
senior
leadership
at
the
company
saying
we
want
to
do
one
thing
and
all
of
us
as
a
team
kind
of
thinking.
That's
not
the
right
way
to
go,
then
we're
being
asked
by
managers
to
present
like
a
unified
front.
All
of
us
have
to
present.
This
is
how
we
believe
we
should
go
forward.
We
all
have
to
agree
on
it
to
senior
leadership
so
that
they
can
see
that
this.
D
D
I
think
this
is
pretty
like
apparent
to
me
and
like
I
was
really
like
frustrated
because
of
that
at
some
point
that,
like
we
keep
discussing
about
child
ingredients
and
all
of
that,
but
I
think
what
I
learned
recently
is
like
that.
This
is
something
to
be
fought
concurrently
as
a
direction,
but
it
doesn't
change
our
world
like
we
still
like
do
the
composition.
We
focus
on
that.
D
It
may
be
slightly
the
focusing
for
us
like
to
like
even
be
joined
into
this
conversation,
but
like
the
the
direction
that
we
decided
some
time
ago,
under
the
composition
of
the
ci,
it's
been
like
something
that
we
are
executing.
There
are
just
concurrent
discussions
about
like
the
next
steps
or
like
concurrent
steps,
depending
on
how
you
look
at
that
and
charting.
D
D
So
I
think
right
now
we
are
like
we
are
kind
of
facing
these
questions
and
they
are
kind
of
distracting,
but
like
our
the
compositional
points
feel
like
like
fully
supported,
is
fully
valid
to
do
it's
like
it's
distracting
because
we
keep
like
changing
the
focus
to
think
about.
I
guess
maybe
the
next
certain
human
stuff.
D
I
think
craig
that,
like
we
continue
with
the
direction
of
the
decomposition,
there
are
like
some
some
concerns
about,
like
whether
we
can
do
starting
how
we
would
do
regions,
but
it
still
doesn't
change
like
what
we
decided.
We
still
continue
the
composition
and
we're
gonna
kind
of
iterate
on
these
problems
at
the
appropriate
time.
A
Yeah
we
we're
definitely
being
consistently
asked
the
same
question
that
we've
already
answered
three
months
ago
and
then
six
months
before
that
and
it's
it
is
kind
of
getting
annoying.
But
at
least
at
least
the
messaging
is
clear
that
we
should
just
keep
working
while
concurrently
answering
the
same
question.
We've
already
answered
multiple
times,
but
we're
not
getting
results
with
our
answers.
So
there
is
something
something
going
wrong
with
how
we're
communicating
right
now.
B
Yeah,
I'm
I
I'm
sensing
that
there
is
a
little
bit
of
a
translation
like
translation,
slash
relay
problem
here,
like
I
see
where
it's
like.
Let's
look
at
the
second
point:
there's
considerable
consent
from
seed
like
I
don't
know
how
true
it
is
like
what
is
considerable.
B
C
C
Basically,
you
know
we
want
you
to
do
sharding
and
we
have
determined
that
you
know
that
is
necessary
and
then
we
came
in
and
basically
were
like
well,
not
really,
and
we
had
this
sort
of
big,
let's
say
struggle
to
have
that
changed,
and
then
we
ended
up
with
this
decomposition
idea,
and
now
it's
like,
oh,
but
what
about
regions?
What
about
shopify
parts?
What
about
this?
You
know
this
concerns
that.
C
C
Of
course
I
know
the
answer
as
to
why,
but
it's
it's
a
bit
worrying
that
what
two
two
months
in
italy
still
creates
this
feeling
that
when
we
say
hey,
we
do
or
don't
need
this
people
keep
second
guessing
it,
and
it's
also
starting
to
feel
a
bit
like
a
case
of
term
what
about
ism?
Basically,
it's
like
we
do
this
yeah,
oh!
But
what
about
this?
Oh,
what
about
that?
What,
if
you
know
we
do
this
yeah?
I
I.
A
B
There
to
me,
I
spent
initially
a
lot
of
time
thinking
about
it,
but
now
I'm
just
ignoring
so
I
don't
know
my
concern.
Is
that
we're
probably
at
the
kind
of
a
critical
junction
where
we're
starting
to
fend
out
things,
but
we
don't
have
a
stable
kind
of
list.
B
We
don't
have
a
stable
set
of
features
that
the
teams
or
people
who
are
not
going
to
try
things
out.
So
I
think
this
is
related
to
your
question
about
documentation.
B
So
I
think
that
documentation
will
be
enormously
helpful
in
the
absence
of
say,
a
development
guide
to
setting
something
locally
or
even
watching
ci
to
test
out
multiple
databases.
So
that's
sort
of
where
that
moves.
A
Yeah,
I
I
think
in
similar
to
that
point
what
we
don't
have
a
branch
for
people
to
validate
that
their
change
fixes
problems
either.
So
we're
fanning
our
work.
We,
the
validation
people,
will
get
that
that
changes.
Actually
work
will
be
from
us
reviewing
their
code
and
saying
yeah,
that's
right,
but
that's
probably
not
as
satisfying
to
a
developer
as
actually
saying.
Okay,
I
see
a
test
fail
and
now
I
see
a
test
pass
and
we
don't
have
that
environment
for
people.
A
So
what
I
think
we
probably
want
to
do
soon
to
get
that
kind
of
product
that
that
environment
people
would
be
that
we
actually
have
like.
You
know,
a
test
that
you
can
run
locally.
You
can
set
an
environment
variable
for
aspect
and
you
can
see
the
same
failures
we're
seeing
in
our
poc
branch
or
what.
However,
we
want
to
organize
that.
A
But
we
see
the
test
fail
in
the
poc
branch,
but
it
won't
be
failing
in
masters,
so
farming
that
out
to
people
it's
hard
for
them
to
actually
validate
their
fixed
problems,
but
yeah
documentation
can
help
them
examples
how
to
fix
problems.
But
it's
not
quite
the
same
as
concrete
test
failing
or
passing.
A
B
A
My
general
sentiment
for
how
we're
doing
the
other
other
point
to
respond
to
your
question.
Camille
is
that
I
feel
like
it
is
taking
us
quite
a
while
to
get
we're
still
not
at
the
point
where
it's
obvious.
What
the
first
thing
we're
going
to
deliver
is,
and
it's
a
little
bit
stressful
thinking
about
how
long
the
time
horizons
are
for
this
project
before
we
can
actually
deliver
something.
A
D
So
then,
my
question
would
be:
how
will
approach
that
to
exactly
know
what
to
deliver?
First,
because,
like
I
think
like
right
now
like
we
are
in
this
tricky
phase
that,
like
we,
do
kind
of
have
poc
in
pretty
decent
shape,
we're
kind
of
doing
small
things,
but
now
like
we
need
to
figure
out
exactly
the
ordering
of
the
things
and
like
what
to
do
and
like
what
to
start
managing,
because
I
think,
like
it's
becoming
pretty
important,
that
we
keep
managing
challenges.
D
D
C
C
Because
I
I
wonder
if
having
maybe
just
one
or
two
tables
isolated,
might
help
ease
the
concerns
from
management
standards.
This
is
what
it
would
look
like.
Here's
how
we
would
use
it,
and
I
think
that
it's
it's
ultimately
more
useful
in
in
determining.
Is
this
idea
good
or
not
than
sort
of
speculating
about
it
in
google
docs
kind
of
similar
to
the
classic?
You
know
people
discussing
some
feature
and
getting
locked,
and
then
somebody
coming
it's
like
hey.
You
know,
here's
a
patch,
it
does
it
and
people
go.
Oh
okay.
C
You
know
this
with
that,
but
I
I
suspect
that
even
that
empty
table
is
probably
gonna.
Take
us.
You
know
from
today,
let's
say
probably
a
month
or
two
at
least
because
it's
just,
I
think,
just
the
fact
of
getting
the
infrastructure
site
set
up
and
coordinating
that
yeah
can
easily
take
quite
some
time.
D
Yeah,
it's
like,
like
the
main
blocker
for
even
trying
out
this
table
right
now.
It's
like
omnibus
configuration,
but
actually
like
we
kind
of
moved
that
forward
and
like
it's
actually
right
now
being
worked
on
by
the
distribution.
C
So
is
it
possible
that
we
perhaps
bypass
all
of
the
distribution
stuff
as
in
we,
so
the
approach
we're
taking
now
is
that
we
sort
of
take
a,
I
would
say,
top-down
approach
like
we
start
with
the
application
code,
then
we
do
you
know
distribution,
gdk
et
cetera.
Then
we
go
to
infrastructure.
C
What
if
we
flip
it
around,
where
we
basically
ask
whoever
will
be
in
charge
of
this
like
hey,
give
us
an
extra
database
cluster,
you
know,
call
it
ci,
it
needs
one
primary
and,
let's
say
for
start
just
one
secondary
keep.
It
simple
set
that
up
your
pg
bouncer
everything,
and
then
we
would
basically
manually
make
it
like
move
tables
over
yeah.
We
have
to
find
a
way
that
we
can
bypass
the
change
request
process
because
that
will
easily
add
days
to
even
the
most
trivial
tasks,
but
the
end
goal.
Is
there
hey?
C
We
probably
have
to
get
more
people
involved,
and
at
that
point
you
know
it
might
take
a
month
at
least
whereas
in
this
approach
we
can
say
hey,
you
know
it
is
a
hack
as
to
how
we
have
set
things
up.
It
is
not
something
you
can
run
with
customers,
it's
perhaps
not
even
something
you
can
do
easily
in
development,
but
here's
what
it
would
look
like,
and
I
think
especially
if
you
start
with
empty
tables
or
small
tables,
we
we
don't
necessarily
even
need
to
keep
them
in
sync.
C
C
So,
in
other
words,
I'm
essentially
advocating
for
let's
take
a
slightly
more
cowboy
coding
approach
to
the
infrastructure
side,
so
that
we
can
get
something
up
and
running
that
we
can
actually
show.
D
D
A
Yeah,
I
think
they're
working
on
actually
creating
better
automated
tooling
to
deploy
database
clusters
but
yeah.
I
we
discussed
the
ci
instance
variables
in
a
call
like
a
couple
of
weeks
ago,
and
I
don't
know
if
we
made
a
firm
decision
on
it.
A
That's
how
we're
going
to
do
the
migration,
because,
when
you're
moving
50
of
the
data,
it's
easier
to
move
100
of
the
data
using
postgres
stream
replication,
and
so
we
don't
actually
have
a
plan
to
migrate
table
by
table
and
then
so
we
kind
of
were
talking
about
this
the
other
day.
If
we
do
ci
instance
variables,
whatever
work,
we
do
for
that.
It's
going
to
be
partly
unbound
when
we
go
down
this
migration
route
and
and
and
it's
it's
kind
of
hard
to
see
the
trade-off
here.
A
If
we
actually
want
to
do
ci
instance
variables,
we
really
have
to
be
clear
what
the
what
the
benefit
of
that
is.
The
benefit
is
not
performance,
but
the
benefit
may
be
helping
us
remain
productive
in
the
short
term
like
there
could
be
other
benefits,
but
yeah.
D
I
I
mean
like
for
me
the
benefit
of
just
deploying
something
and
using
20
databases.
It's
like
butter
testing,
many
databases,
software
and
like
there
is
like
a
bunch
of
the
associated
problems.
That's
like
the
pulling
size
we
recover
management
of
the
configuration
monitoring
of
the
support
resistances,
and
this
is
something
that
could
be
really.
Then
we
work
on
by
us
and
the
infra
imparting
to
anticipate
like
this
kind
of
full-fledged
migration.
So
it's
not
really
like
performance,
and
I
can
be
careful
with
that.
D
A
And
that's
fine,
if
we're
going
to
do
that,
I
think
it's
still.
Okay,
just
recognizing
we'll
be
rolling
back
some
of
that
stuff.
We'll
still
get
a
lot
of
the
configuration
benefits
and
whatever
we
learn
through
out
of
that,
but
we'll
be
rolling
back
the
actual
migration
of
it
so
that
we
can
migrate
it
properly.
Alongside
all
the
other
ci
tables.
D
Yeah,
so
I
I
think,
like
what
is
gosha
right
now,
like,
let's
kind
of
like
sprint
later
today,
on
deciding
on
the
what
we
do
with
the
structures
and
schemas,
because
if
we
log
on
this
decision,
I
think
this
will
also
kind
of
make
it
easier
to
figure
out
how
useful,
if
we
run
another
database
will
be
because
we
may
kind
of
have,
I
don't
know
the
single
table
or
many
tables
and
structures,
because
there's
like
this
whole
process
about
also
running
migrations
in
manual
databases.
D
So
like
this
whole
process
of
the
migrations
and
rollbacks
managing
them
and
like
we
still
haven't
figure
out
exactly
how
we
want
to
deal
with
these
structures,
consistency,
foreign
keys,
schemas,
and
if
we
can
somehow
like
decide
on
that
today,
I
think
it
will
kind
of
give
us
a
stream
of
the
work
related
to
the
database
structure
and
how
to
deal
with
that
and
how
we're
gonna
deal
that
with
the
daddy
from
the
delivery
side
of
things
as
well.
C
A
Yeah
that
I
think
the
how
you
restore
your
database
initially
would
result
in
like
would
impact
how
what
kind
of
bloat
you
carry
over
and
in
terms
of
so
how
do
you
restore
the
ci
tables
from
a
point,
a
snapshot
in
time?
If
you
want
to
restore
the
exact
file
system
of
all
of
postgres,
then
you'll
get
all
of
the
tables.
A
You
could
still
use
logical
replication
from
there
on
to
only
replicate
the
updates
to
the
ci
tables,
but
if
you
did
it
that
way,
you
would
get
the
same
bloat
that
you
had
that
you
were
from
the
database
that
you
stored
from,
because
you
were
storing
from
like
the
file
system
level.
A
If
you
were
to
restore
record
by
record,
that
would
be
a
very,
very
complicated
process
and,
like
a
very
time,
consuming
process.
I
think,
in
order
for
us
to
get
the
clean
database,
but
that's
still
orthogonal,
to
logical
replication.
We
would
have
to
use
logical
replication
from
then
on
out.
If
we
did
that,
but
the
we
did
discuss
logical
replication,
we
basically
ruled
it
out
because
yeah
it's
more
complicated
to
implement
it's
new
new
infrastructure
and
new
tooling.
A
We
need
to
understand
logical
replication
can
replicate
the
ddl
statements,
but
it
can't
replicate
schema
changes,
so
we
need
to
be
very
deliberate
and
careful
about
how
long
we're
running
logical
replication
for
because,
if
we're
running
logical
replication,
while
schema
changes
are
ongoing,
you
can
end
up
with
data
inconsistencies
yeah
and
it's
also
possibly
too
slow
for
us
to
actually
use.
We
haven't
actually
proven
that
we
can
use
it
at
the
scale
of
all
of
our
ci
tables.
A
Being
replicated
record
by
record
it'll,
put
considerably
more
pressure
on
the
primary
doing
that
anyway,
when
we
decode
it
on
the
primary,
so
we
basically
just
ruled
it
out
and
said,
like
we
know,
stream
replication
works,
we
know
how
it
works.
It'll
just
be
another
replica
that
we're
creating
in
production
and
we'll
just
fail
over
to
that
replica
for
ci
connections.
Only
so
it'll
look
a
lot
like
our
normal
failover
process
that
we've
tested
the
replication
will
be
based
on
patronus
configuration
the
same
way
we've
tested
and
used
in
the
past.
D
I
will,
I
will
add
one
more
thing
to
that:
we
actually
have
database
the
procedure
in
the
infrastructure
that
allows
you
to
completely
fork
the
whole
cluster
of
your
current
database
like
fairly
easy
from
the
snapshot
so
technically
from
the
infrastructure
sites.
I
think
another
cluster
that
is
like
replicated
from
the
main
it
appears
to
be
like
a
well
figured
out
process
and
it's
already
automated
to
some
extent.
D
B
Yeah,
have
you
read
the
migration
plan?
Uric
see
number
five.
C
I
think
I
initially
looked
at
it
a
while
ago.
I
haven't
looked
at
it
recently,
but
the
there
that
comes
from
dylan
about
the
replication.
They
make
sense.
C
I
I
do
think
if
we
use
streaming
replication
migrating
an
empty
table,
at
least
is
sorry
it's
easy,
but
also
that
you
kind
of
each
put
like
okay.
What's
the
benefit,
it's
an
empty
table
yeah
so.
B
Like
like
migrating,
I
feel,
like
the
migration
plan,
describes
an
end
state,
there's
nothing
that
says
that
we
can't
have
like
an
intermediate
thing
where
we
migrate:
the
ci
instant
service
and
that's
that's
a
temporary
state
just
purely
for
the
business
so
that
we
can
better
test
it
and
run
all
those
things
that
can
be
discussed.
I
feel
like
that's
something
that
we
discussed
a
month
back
and
would
have
stopped,
probably
because
we're
waiting
on
structure.
So
so
the
question
is:
do
we
actually
still
want
that
test
or
not.
A
It's
not
clear
that
it's
not
clear
to
me
that
infrastructure
is
prioritizing
giving
us
a
new
database
cluster
right
now,
or
at
least
jose
at
the
moment,
is
prioritizing
benchmarking
work
for
us
to
figure
out
how
this
streaming
replication
is
going
to
work
and
how
long
it's
going
to
take
and
what
kind
of
downtime
we
should
expect
so,
but
yeah.
If
we
want
the
ci
instance
variables
moved
over
and
we
just
want
a
database
cluster
with
one
replica
and
it
doesn't
really
matter
configured
today.
D
So
can
we
kind
of,
let's
say
expect
that
in
the
14.3
we
would
connect
another
database
to
staging,
and
this
is
where
we
would
need
the
infrastructure
help
and
maybe
up
to
that
moment,
how's
the
actually
like
the
team
finishes
what
they
are
doing.
Now
we
have
the
proper
configuration
and
we
can
start
kind
of
like
using
many
databases
to
not
like
change
too
many
things
at
once
and
like
for
like
somewhere
in
the
14.3.
We
would
kind
of
connect.
D
I
don't
know
whatever
we
have
at
that
point.
Is
it
instance
variable
or
is
it
more
or
is
it
just
another
database
configuration
we
would
just
connect
stating
to
another
database
and
we
will
just
model
on
the
application.
To
what
extent
is
that
connection
actually
used.
B
D
It
has
to
go
through
staging
so
anyway,
so
if,
if,
if
that's
a,
if
this
is
like
the
approach
for
the
infrastructure
team
to
start
providing
production,
I'm
even
fine
saying
that,
like
okay,
we're
just
not
gonna
use
this
another
database
for
storing
actual
data.
We're
just
gonna
feature
a
plug,
but
we
kind
of
now
configure
demonstrating
feel
that
intended.
This
is
good
enough
to
run
it
in
the
production,
but
we
will
not
store
any
data
on
the
production
databases.
C
Would
it
would
it
be
an
option,
if
perhaps
as
a
sort
of
anybody,
call
it
temporary
testing
approach
whatever
we
set
up
a
different
database
name
on
the
same
database
host
as
we
have
now,
because,
as
far
as
I
remember,
our
database
migrations
do
have
the
permissions
to
create
new
databases,
because
we
use
that
for
geo.
C
C
Well,
actually,
I
think
the
pros
will
be
manual
because
we
can't
replicate
the
entire
database
onto
the
same
host
because
we
probably
run
out
of
disk
space,
but
for
that
particular
case
you
know
we
could
do
manually
or
something
along
those
lines,
because
that
way
we
have
something
to
show,
but
we're
not
bound
by.
C
A
I
think
it's
all
an
option.
I
I'm
not
sold
on
the
objectives,
though,
like
I'm
not
sold
that
if
we
go
down
this
route,
we
will
have
learnt
so
much
that
it
was
a
worthwhile
exercise,
given
that
it's
not
our
long-term
plan
and
I'm
also
not
sold
on
it
being
something
that
will
be
visible
to
stakeholders
in
alleviating
their
concerns.
I
mean
it
might,
but
I
also
kind
of
think
well
they're
going
to
rightly
challenge
us
and
say,
but
why
are
you
doing
this?
A
What
is
it
accomplished
and
then
we'll
say
well
we're
doing
it
to
show
that
we
can
and
it
hasn't
accomplished
anything.
I
don't
know,
that's
me
being
skeptical,
but
we
might
learn
things
from
it.
B
D
I'm
I'm
kind
of
worried
that,
like
if
we
even
aim
on
like
a
single
database,
it's
actually
it's
not
that
easier
than
like
setting
separate
databases
because
of
the
very
slight
amount
of
the
connections.
Probably
we
need
separate
pg
bouncers
configurations
with
the
separate
connection
pools
anyway,
so
there
is
like
also
the
potential
performance
impact
on
the
postgres
master
that
we
saw
the
postgres
main
that
we
have
today.
D
D
Given
also
like
the
the
amount
of
the
effort
that
we
need
to
spend
to
actually
make
it
happen,
and
I
I
mean
it
kind
of
really
depends
how
how
how
infrastructure
team
can
iterate
on
creating
database
clusters
if
it's
like
three
months.
D
This
is
something
I
think
that
we
should
figure
out
how
to
speed
up,
because
if
it's
actually
three
months,
then
it's
gonna
be
probably
gonna
start
become
blocked
pretty
soon,
and
I
know
there
are
that
you
started
working
on
some
this
monitoring
changes.
A
That
I
agree
with,
we
can
actually
test
and
see
that
we
can
test
logging
and
performance
bar
and
various
other
things.
We
can
test
dashboards
and
grafana
and
see
that
they're
all
wired
up
correctly,
because
that's
all
stuff,
that's
going
to
need
to
be
added
for
this
second
database.
So
I'm
fine
with
that
part
of
the
plan
for
moving
instance
through
ci
instance
variables.
I
think
it's
reasonable.
A
The
the
alternative
with
our
streaming
replication
is
that
we
could
configure
the
ci
connections
to
go
through
separate
pg
bounces
and
to
go
to
our
read-only
connections
to
go
to
the
ci
cluster
directly,
because
it'll
already
be
a
streaming
replica
of
the
original
cluster
like
we
can.
We
can
actually
move
connections
around
topologically
so
that
we
still
writes
are
all
still
going
to
the
same
place,
but
they're
going
through
different
pg,
bounces
and
so
on.
A
B
B
B
One
day
I
want
to
go,
I
think,
charts,
it's
probably
gonna
be
a
little
bit
harder,
but
it
should
be
all.
B
D
Let's
keep
that,
let's
finish
it's
already
like,
we
are
overdue.
Thank
you.