The beta cluster currently (May 2021) has a pair of MariaDB instances in a fairly standard master-replica setup running Buster and MariaDB 10.4.
Creating new instances
Derived from Setting up a MySQL replica and lessons learned from task T216067, slightly adjusted from task T276968. Still may be out of date, the last phabricator ticket may be useful.
- Create a new
g3.cores8.ram16.disk20instance in horizon named deployment-dbNN where NN is an unused number, add a large enough Cinder volume and mount it to /srv, get its puppet certs signed, etc.
- TODO: determine if the VM needs that many resources. We used cores8.ram16 on g2 since we needed the extra disk, Cinder is now a thing.
On New Replica
mariadb::config::basedir: /opt/wmf-mariadb104in hiera, adjust the version number based on the used MariaDB version
- ensure puppet runs cleanly
/opt/wmf-mariadb104/scripts/mysql_install_db --user=mysql --basedir=/opt/wmf-mariadb104 --datadir=/srv/sqldata
nc -l -p 9210 | mbstream -x
On Existing DB
mariabackup --innobackupex --stream=xbstream /srv/sqldata --user=root --host=127.0.0.1 --slave-info | nc NEW-SERVER 9210
On New replica, After mariabackup
Do this before starting mysql!
mariabackup --innobackupex --apply-log --use-memory=10G /srv/sqldata
chown -R mysql: /srv
systemctl start mariadb
- tail the error log in /srv/sqldata and check for any errors
- If this is newer version of MariaDB, run
/opt/wmf-mariadb104/bin/mysql_upgrade --host=127.0.0.1to ensure compatibility.
- Check /srv/sqldata/xtrabackup_slave_info on the new host, it provides a partial CHANGE MASTER statement based on whichever host the target was replicating from. If this is correct, use this, adding MASTER_HOST and the repl account/password portions that are missing.
CHANGE MASTER to MASTER_USER='repl', MASTER_PASSWORD='...', MASTER_PORT=3306, MASTER_HOST='deployment-db1', MASTER_LOG_FILE='deployment-db1-bin.000026', MASTER_LOG_POS=191406295;
- The master repl password should be in the file /var/lib/git/labs/private/modules/secret/secrets/mysql/repl_password on the deployment-puppetmaster (currently
- If you ran the hot backup from the master, use the information in /srv/sqldata/xtrabackup_binlog_info as slave_info won't exists.
- If you copied from the secondary master, xtrabackup_slave_info will point to the active master; use xtrabackup_binlog_info instead.
Per phab:T110115 all database servers default to read only when they start. This is expected for the replicas, but the primary server needs to be set to read-write after making sure it is ok (nothing worrying in logs, replication looks fine). This can be performed by sshing into the current primary which can be found from mediawiki-config repo.
Remember to !log any actions on #wikimedia-releng connect and check before setting it to read only if someone is doing maintenance which expects it to be read only, on the same IRC channel.
taavi@deployment-db07:~$ sudo -i mysql Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 329 Server version: 10.4.18-MariaDB-log MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. root@BETA[(none)]> select @@read_only; +-------------+ | @@read_only | +-------------+ | 1 | +-------------+ 1 row in set (0.000 sec) root@BETA[(none)]> set global read_only = false; Query OK, 0 rows affected (0.000 sec) root@BETA[(none)]> select @@read_only; +-------------+ | @@read_only | +-------------+ | 0 | +-------------+ 1 row in set (0.000 sec)