in an unpleasant situation.
current danger state: db3_leader and db4_replica
original correct state: db3_replica and db4_leader
orchestrator switched/promoted db3 to leader.
I'll try to get dump from db3 and load it on db4
But idk how is it doing? Because db3 is a production DB (I think use mysqldump with options) and it's 2Tb of size
Could you please advice me manual or howto or just help with article, thanks!
not enough info. you definetely use some kind of arbiter to make a failover. and it seems a failover has happened. ain't nothing wrong with that
Yes, orchestrator - is an arbiter, it's just did failover (no more questions to it) Main question is - how to get valid dump db.<all_tables> and restore it on current replica? mysqldump is logical backup, but db has 2Tb size, it's too much for mysqldump percona xtrabackup... is physical, but idk how to use it on production db without affect on users
if i remember correctly, it doesn't block readers or writers. so the only thing you have to worry about is disk and network io. which usually is not a problem. but in case it is, you can pipe this stuff into pv and call it a day.
You don't have a choice in this situation. 1. mysqldump a few files, different tables in the different files with data 2. mysqldump, a single file with all tables and data 3. perconaxtrabackup. Percona XtraBackup will use Backup locks where available as a lightweight alternative to FLUSH TABLES WITH READ LOCK. This feature is available in Percona Server for MySQL 5.6+. Percona XtraBackup uses this automatically to copy non-InnoDB data to avoid blocking DML queries that modify InnoDB tables. When backup locks are supported by the server, xtrabackup will first copy InnoDB data, run the LOCK TABLES FOR BACKUP and copy the MyISAM tables and .frm files. Once this is done, the backup of the files will begin. It will backup .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, and .opt files.
Обсуждают сегодня