Conversation
| out=$$(/cockroach/cockroach.sh init --insecure --host=db1.uss1.localutm 2>&1); | ||
| if [ $$? -eq 0 ]; then | ||
| echo "$$out"; | ||
| /cockroach/cockroach.sh sql --insecure --host=db1.uss1.localutm -e 'ALTER RANGE default CONFIGURE ZONE USING num_replicas = ${NUM_USS:?};'; |
There was a problem hiding this comment.
Do this work reliably, or there is a chance that migrations create database/tables before and use a different default?
There was a problem hiding this comment.
- migrations (from the (rid|scd|aux)_bootstrapper) explicitely wait for
crdb-initto be completed before being ran - even if this is applied after creation of the table, the setting is applied, as we apply it on the zone
| entrypoint: /db-entrypoint.sh | ||
| # 128MB limits allow larger numbers of nodes on a single machine | ||
| command: /cockroach/cockroach.sh start --insecure --join=db1.uss1.localutm --cache=128MiB --max-sql-memory=128MiB | ||
| command: /cockroach/cockroach.sh start --insecure --join=db1.uss1.localutm --cache=128MiB --max-sql-memory=128MiB --locality=uss=${USS_IDX:?} |
There was a problem hiding this comment.
Probably an open question to be validated, but going one level higher and having one locality per USS_IDX-USS_NODE_IDX may be better at the cost of being less realist.
There was a problem hiding this comment.
We could indeed have that. IIUC locality keys are hierarchical, i.e. if we have the localities uss=1,node=1-2 defined, CRDB will distribute first over the localities uss, and then over the localities node. So we could already set this in here without impact.
There was a problem hiding this comment.
Check out the new version.
|
I will do some test to validate that it's remove variations |
2 participants
We do this to produce more consistent results when testing performances of the DSS.
This should address interuss/dss#1559