mylvmbackup-discuss team mailing list archive
Mailing list archive
Re: mylvmbackup -- handle flush table with read lock solution. script to share
Yes, I agree with you that default behavior should not change. Therefore, the ftwrl_mode was suggested to stay at 2 and the ftwrl_wait and ftwrl_trails can stay high number to mimic the current behavior.
Where there is a long run query exists, the current mylvmbackup will put FTWRL lock and wait until the long run query completed. That can be mimic by using ftwrl_mode = 2, ftwrl_wait=10 (check every 10 seconds) and ftwrl_trails stay high like 360 (360*10= 1 hour) or even higher.
From: Lenz Grimmer <lenz@xxxxxxxxxxx>
Sent: Sunday, September 27, 2015 11:11 PM
Subject: Re: [Mylvmbackup-discuss] mylvmbackup -- handle flush table with read lock solution. script to share
I've taken a first look at your changes, thanks again for proposing these. One question: I wonder if it would make sense that the default behaviour of mylvmbackup does not change. When a user updates mylvmbackup, he should not run into surprises. Therefore I would like to propose to change the defaults for wait_tmp_table_close and stop_replication to 0. What about ftwrl_mode? Which mode would be the best default if no change in behaviour should be observed?
On 09/25/2015 01:57 AM, Linda Xu wrote:
I put these options is because an experience DBA probably know their system and have choice to decide what they like to do.
Sometime, the backup has priority to run and ignore the open temp table on slave when temp table is not suggested to use by app but may used by ad-hoc query. In that case, DBA can rebuild slave by skip bin log has temp table involved etc.
Lenz Grimmer <lenz@xxxxxxxxxxx> - http://www.lenzg.net/
Mailing list: https://launchpad.net/~mylvmbackup-discuss
Post to : mylvmbackup-discuss@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~mylvmbackup-discuss
More help : https://help.launchpad.net/ListHelp