I checked roles/dbserver-mysql/mysql-server/files/conf.d/server.cnf
and found innodb_buffer_pool_size hardcoded to 410M. T1130 asks to
bump it to 2G, computed from Ysul's InnoDB data/index size with the
sizing query given in the task.
Before just swapping the value, I noticed this same server.cnf is
shared by every node running the dbserver-mysql role: ysul, windriver
and db-b-001 (see top.sls). 2G was only computed for Ysul, so I ran
the same query on windriver to check: its InnoDB tables hold about
32KB of data, basically unused (Postgres is the real DB there), and
windriver already runs a lot of other services (Grafana, Prometheus,
Redis, Nextcloud, webserver-alkane...). Hardcoding 2G everywhere would
have wasted RAM on windriver for nothing. I don't have access to check
db-b-001, so I'm leaving it on the current default too.
So instead of a one-line hardcode, I made the value configurable per
node through pillar, following the same pattern cnf.sls already uses
for nodename/listen_ip/use_zfs:
- pillar/dbserver/ysul.sls: new pillar file setting dbserver_mysql:server:innodb_buffer_pool_size to 2G, wired into pillar/top.sls under ysul (it had no dbserver.* pillar before).
- cnf.sls: pass innodb_buffer_pool_size into the template context via pillar.get, defaulting to 410M when unset.
- server.cnf: use the templated value instead of the hardcoded one.
windriver and db-b-001 keep 410M (current behavior, unchanged) since
neither has this pillar key set. Whoever has access to db-b-001 can
run the T1130 query there and add pillar/dbserver/db-b-001.sls the
same way if a bump turns out to be justified.
Refs T1130