I think with import table it is practically new feature because
export/import was basically non workable
in normal Innodb because it is very hard to guaranty in production
conditions such as no insert buffer
entries or unpurged entries. This means for practical user you could not
export/import tables in
standard MySQL and you can in Percona Server
now for "pass corrupted table" I think permit corrupted table is confusing
as it looks as it makes
more prone to corruption. I would compare this to how file system (say
EXT3) allow to tune inconsistence
behavior. What we really tune here is the behavior on detected corruption.
The default behavior in
Innodb is "assert" What do we do with current behavior ? Do we make
table inaccessible until server restart ?
There could be other possibilities for example making table read only in the
future.
Maybe we can use innodb_import_table_(rewrite|convert)_identifiers ?
>
> >>>> INNODB_PASS_CORRUPT_TABLE
> > can we named using opposite and negative words like
> > "force", "ignore" or something?
> > (like same image for force_recovery. And it is more expandable in the
> future. e.g. add leveling)
> > and default is 0 and 0 means abort when meet corruption.
>
> Maybe innodb_permit_corrupt_table=<level> is a good name?
>
> --
> You received this bug notification because you are a member of Percona
> developers, which is the registrant for Percona Server.
> https://bugs.launchpad.net/bugs/721611
>
> Title:
> Change XtraDB variables in 5.5
>
> Status in Percona Server with XtraDB:
> Won't Fix
> Status in Percona Server 5.5 series:
> Won't Fix
>
> Bug description:
> After discussion with Baron, we should change names of following
> variables in 5.5:
>
> INNODB_AUTO_LRU_DUMP
> to
> innodb_enable_fast_warmup
>
> INNODB_EXPAND_IMPORT
> to
> innodb_enable_import_tables
>
> INNODB_OVERWRITE_RELAY_LOG_INFO
> to
> innodb_provide_replication_position
>
> INNODB_PASS_CORRUPT_TABLE
> Rename to innodb_stop_on_corrupt_table=0|1 ( default is 1)
>
> And next status variables:
> > INNODB_CHECKPOINT_AGE
> > INNODB_CHECKPOINT_MAX_AGE
> > INNODB_CHECKPOINT_TARGET_AGE
>
> Should be
> INNODB_CHECKPOINT_AGE
> INNODB_CHECKPOINT_AGE_MAX
> INNODB_CHECKPOINT_AGE_TARGET
>
--
Peter Zaitsev, CEO, Percona Inc.
Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev
24/7 Emergency Line +1 888 401 3401 ext 911
Baron,
I think with import table it is practically new feature because
export/import was basically non workable
in normal Innodb because it is very hard to guaranty in production
conditions such as no insert buffer
entries or unpurged entries. This means for practical user you could not
export/import tables in
standard MySQL and you can in Percona Server
now for "pass corrupted table" I think permit corrupted table is confusing
as it looks as it makes
more prone to corruption. I would compare this to how file system (say
EXT3) allow to tune inconsistence
behavior. What we really tune here is the behavior on detected corruption.
The default behavior in
Innodb is "assert" What do we do with current behavior ? Do we make
table inaccessible until server restart ?
There could be other possibilities for example making table read only in the
future.
Maybe we can use innodb_ import_ table_( rewrite| convert) _identifiers ? PASS_CORRUPT_ TABLE permit_ corrupt_ table=< level> is a good name? /bugs.launchpad .net/bugs/ 721611 AUTO_LRU_ DUMP enable_ fast_warmup EXPAND_ IMPORT enable_ import_ tables OVERWRITE_ RELAY_LOG_ INFO provide_ replication_ position PASS_CORRUPT_ TABLE stop_on_ corrupt_ table=0| 1 ( default is 1) CHECKPOINT_ AGE CHECKPOINT_ MAX_AGE CHECKPOINT_ TARGET_ AGE CHECKPOINT_ AGE CHECKPOINT_ AGE_MAX CHECKPOINT_ AGE_TARGET
>
> >>>> INNODB_
> > can we named using opposite and negative words like
> > "force", "ignore" or something?
> > (like same image for force_recovery. And it is more expandable in the
> future. e.g. add leveling)
> > and default is 0 and 0 means abort when meet corruption.
>
> Maybe innodb_
>
> --
> You received this bug notification because you are a member of Percona
> developers, which is the registrant for Percona Server.
> https:/
>
> Title:
> Change XtraDB variables in 5.5
>
> Status in Percona Server with XtraDB:
> Won't Fix
> Status in Percona Server 5.5 series:
> Won't Fix
>
> Bug description:
> After discussion with Baron, we should change names of following
> variables in 5.5:
>
> INNODB_
> to
> innodb_
>
> INNODB_
> to
> innodb_
>
> INNODB_
> to
> innodb_
>
> INNODB_
> Rename to innodb_
>
> And next status variables:
> > INNODB_
> > INNODB_
> > INNODB_
>
> Should be
> INNODB_
> INNODB_
> INNODB_
>
--
Peter Zaitsev, CEO, Percona Inc.
Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev
24/7 Emergency Line +1 888 401 3401 ext 911
Looking for MySQL Support ? www.percona. com/support/
http://