Hello, everybody, Kristian.
1. Take note of @@global.gtid_binlog_state 2. Ensure that all slaves are past the last event of being deleted domain 'd'
3. PURGE BINARY LOGS DELETE DELETE 'd'
While I was selecting between two candidates where to settle the new option to discard the obsolete domain from Gtid_list of the most recent binlog file, another candidate popped out. And really why not 3. SET @@GLOBAL.gtid_binlog_state=list-without-d; where `list-without-d' sublists the p.1 SELECT @@global.gtid_binlog_state with the obsolete domain discarded? The docs currently say The main usage of @@gtid_binlog_state is to restore the state of the binlog after RESET MASTER (or equivalently if the binlog files are lost). Now when we've defined what the domain-id purge should be, I find RESET-MASTER requirement can be refined/relaxed to the following one: the new state value must cover (include as a math set) all gtids in the current list of binlog files. (Naturally I consider [presume] Gtid_list header of a binlog file assumes there are no gaps or out-of-order in the preceding files. That is it provides the right-hand-side of gtid seqno range for each domain-server pair). Specifically to the obsolete domain case, `list-without-d' new value would reflect gtids from files remained after a user PURGE files containing 'd'. Naturally we would leave the backward compatible behavior in case of the list of binlog files is empty (as after RESET MASTER). As an example: Let binlog consists of two files b.1 /* contains one event from domain 0 */ b.2 /* does not contain domain 0 */ with their header Gtid_lists as b.1.Gtid_list=\empty b.2.Gtid_list={0-1-1} and we would like to forget the domain 0 ('d'). So we conduct the 1-3 procedure. Pseudo-sql would go like mysql> /* 1. */ SELECT @@global.gtid_binlog_state into @pre_purge_state; mysql> /* 2. */ PURGE LOGS to 'b.2' mysql> /* 3. */ SET @@global.gtid_binlog_state="REPLACE"(@pre_purge_state, '0-1-1', ''); At the 3rd step the SET handler would implicitly execute FLUSH LOGS to rotate binlog to b.3 where the new value gets adopted only when the refined check succeeds. Otherwise the SET errors out. The check technically is a comparison between Gtid_list.d term in the oldest file and @pre_purge_state.d one. If they are equal the current binlog files are proven not to contain events from 'd'. I find the SET method as fitting to the matter. Backward compatibility is in place. No new options is required. The burden of PURGE may not necessarily be left to the user though. The proposed new 'delete domain_id' option can be implemented (now, later?). Your feedback is welcome! Cheers, Andrei