Change XtraDB variables in 5.5

Basically, you should explain reasons.
I don't accept wrong constitute names and cheating user names.

> INNODB_AUTO_LRU_DUMP
> to
> innodb_enable_fast_warmup

fast? warmup?
I don't like to cheat users. It is really not concrete name.
The name should express the effect cleanly.

> INNODB_EXPAND_IMPORT
> to
> innodb_enable_import_tables

"IMPORT TABLE" is supported basically. It is wrong name.

> INNODB_OVERWRITE_RELAY_LOG_INFO
> to
> innodb_provide_replication_position

I don't like to cheat users. It is really not concrete name.
The name should express the effect cleanly.

> INNODB_PASS_CORRUPT_TABLE
> Rename to innodb_stop_on_corrupt_table=0|1 ( default is 1)

The user should understand passing corrupt table is abnormal for RDBMS...
It may not the problem only about the table.
,as I described before.

InnoDB should abort for all corruption detections.

You should explain the abnormal name for me, again.
You didn't explain any at the previous report.
I don't accept one-side intrusion...

> 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

I intended that
values about checkpoint
"age", "max age" and "target age".

In addition, for example,
I regret I should not accept the name "adaptive_checkpoint" at the time when implemented, you suggested.
It was wrong constitute name. And it was already renamed currently.
I should not accept careless suggestions.

My comments are inline. In general, I propose names that users will
understand, which express the behavior of the server. I think that
this is better than names that developers who know the InnoDB source
will understand, or names which express an operation on an internal
data structure.

>> INNODB_AUTO_LRU_DUMP
>> to
>> innodb_enable_fast_warmup
>
> fast? warmup?
> I don't like to cheat users. It is really not concrete name.
> The name should express the effect cleanly.

Users will not understand auto_lru_dump. The effect of the variable
is that the server becomes ready to answer queries more quickly after
starting. This is what users will understand and care about.
However, I think you are correct. There could be many different ways
to make the server warm up more quickly, and we should name them
specifically. I think that we might consider a name such as
"innodb_buffer_pool_save_restore". It is also a bad name, but
"buffer_pool" is much better than "lru" for users. (We should also
not use "dump" because it has a slightly different and unprofessional
meaning in English, and the behavior is not only to save the LRU, it
is also to restore it from the saved information.)

>> INNODB_EXPAND_IMPORT
>> to
>> innodb_enable_import_tables
>
> "IMPORT TABLE" is supported basically. It is wrong name.

I agree. But I do not have a better suggestion. The current variable
name is very cryptic. It does not explain what the change in server
behavior is. Maybe we need a variable that explains "when importing a
tablespace, also do ________" ? What, exactly, does the variable
change? I think it renames the tablespace ID, right? I do not know
this feature's behavior very well.

>> INNODB_OVERWRITE_RELAY_LOG_INFO
>> to
>> innodb_provide_replication_position
>
> I don't like to cheat users. It is really not concrete name.
> The name should express the effect cleanly.

The behavior of the server is that after a crash, replication gets its
position information from the storage engine, not the relay log file.
The word "overwrite" sounds like something bad in English. It means
that some data is being destroyed. I propose
"innodb_recovery_update_relay_log". This does not seem perfect, but
it is better.

>> INNODB_PASS_CORRUPT_TABLE
>> Rename to innodb_stop_on_corrupt_table=0|1 ( default is 1)
>
> The user should understand passing corrupt table is abnormal for RDBMS...
> It may not the problem only about the table.
> ,as I described before.
>
> InnoDB should abort for all corruption detections.
>
> You should explain the abnormal name for me, again.
> You didn't explain any at the previous report.
> I don't accept one-side intrusion...

I do not propose to change the behavior. By default, InnoDB should
abort, as you say. But the word "pass" is very ambiguous in English,
and the meaning will not be clear to users. I propose
"innodb_abort_on_corrupt_table=0|1", with a default of 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
>
> I intended that
> values about checkpoint
> "ag...

> In addition, for example,
> I regret I should not accept the name "adaptive_checkpoint" at the time when implemented, you suggested.
> It was wrong constitute name. And it was already renamed currently.

I am not sure what you mean. I do not remember suggesting a name for
this when you implemented the feature.

Baron,

My naming policy is
describe by the name of "component" and "method" to eliminate suspicious and subjective.
Never by "effect", "purpose".

I know the such kind of complain is often from less-understanding about InnoDB.
I don't assume the less-understanding users.
I think all users who want to use InnoDB effectively should understand InnoDB.
As deeper understand, he should obtain better setting.

The good example of past about it is about "adaptive_checkpoint".
I named it as "adaptive_flush(ing)" at first I implemented.
Because it controls the amount of flushing blocks by background thread
to make small the impact and possibility that the checkpoint effect affects to performance.

But, Peter and Vadim forced to change the name for "adaptive_checkpoint".
I think it is name for the purpose. Bad name for describe the function.
Though it was attractive and catchy, it was wrong and made misunderstanding.
I think such wrong and misunderstanding
should obstruct the next step to improve InnoDB more.

I'd like to be sincere for all MySQL/InnoDB users.
If don't understanding, please study.
I believe "don't understanding" is much better than "misunderstand"
for MySQL/InnoDB ecosystem.

If the "don't understand" is from wrong expression of English language,
I will try to fix.
But from less understanding, I never accept it.

That's why I need the your reason.
The your reason should explain the what cause the "don't understand".

>>> INNODB_AUTO_LRU_DUMP
>>> to
>>> innodb_enable_fast_warmup
>>
>> fast? warmup?
>> I don't like to cheat users. It is really not concrete name.
>> The name should express the effect cleanly.
>
> Users will not understand auto_lru_dump. The effect of the variable
> is that the server becomes ready to answer queries more quickly after
> starting. This is what users will understand and care about.
> However, I think you are correct. There could be many different ways
> to make the server warm up more quickly, and we should name them
> specifically. I think that we might consider a name such as
> "innodb_buffer_pool_save_restore". It is also a bad name, but
> "buffer_pool" is much better than "lru" for users. (We should also
> not use "dump" because it has a slightly different and unprofessional
> meaning in English, and the behavior is not only to save the LRU, it
> is also to restore it from the saved information.)

The relation between method and effect should be studied.
If you don't imagine the effect from the method name,
I don't recommend not to use it, because you should mistake about using.
The name should be sincere as I described above.

And users should know the option cause the new file to be used by it.
So the verb should be used to associate accessing another file.

The method name candidates are
"dump" (auto periodical)
"save" (auto periodical)
"preload_at_startup"
"restore_at_startup"

The component name candidates are
"lru"
"buffer_pool"
"list of cached_data_pages"

The exactly what is saved in the file is
list of the pairs of space_id and page_no.
So, "lru_list of buffer pool" is best component to be described.
Only "buffer pool" may cause misunderstanding to store also
the component of the pages li...

>>>> INNODB_AUTO_LRU_DUMP

I think we should consider the following candidate:
  innodb_buffer_pool_restore_at_startup
This seems best to me because:
- Although the file contains the space_id and page_no pairs, the
buffer pool is what is restored.
- Although the feature both saves the pairs and restores the buffer
pool, the important part is restoring. (Saving the pairs is useless
without the restore.) And naming with both "save" and "restore" is
too long and awkward.

>>>> INNODB_EXPAND_IMPORT

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?

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 ?
>
> >>>> 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

Looking for MySQL Support ?
http://www.percona.com/support/

Peter, can you read back through Yasufumi's comments and see what you
can suggest? He had some well-supported opinions about some of the
things I suggested -- maybe we can come up with something that
satisfies all of us. Variable naming is hard.

Baron,

>>>>> INNODB_AUTO_LRU_DUMP
>
> I think we should consider the following candidate:
> innodb_buffer_pool_restore_at_startup
> This seems best to me because:
> - Although the file contains the space_id and page_no pairs, the
> buffer pool is what is restored.
> - Although the feature both saves the pairs and restores the buffer
> pool, the important part is restoring. (Saving the pairs is useless
> without the restore.) And naming with both "save" and "restore" is
> too long and awkward.

Hmm... I may have to compromise....

>
>>>>> INNODB_EXPAND_IMPORT
>
> Maybe we can use innodb_import_table_(rewrite|convert)_identifiers ?

Yes, it seems more clear than innodb_expand_import.
But... in more concretely,
export is done by xtrabackup
XtraDB can import it by this option.

I have came to...
It may be better to describe based on the usage than describe behavior as it is.

How about like the direction like
"innodb_import_table_from_xtrabackup" ?

>>>>> 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?
>

"permit" seems little strange for me.

What permitted is...
"continue to work"
not
"corrupt table"

The corrupt table is marked as "corrupt" and reply to mysqld "corrupted" always.
not permitted, I think.

Baron,

Yes I read through comments.

I think something like innodb_use_xtrabackup_table_import is good enough

For table I think it should be something like

innodb_corrupt_table_action=assert|block etc

On Sun, Feb 27, 2011 at 1:58 PM, Xaprb <email address hidden> wrote:

> Peter, can you read back through Yasufumi's comments and see what you
> can suggest? He had some well-supported opinions about some of the
> things I suggested -- maybe we can come up with something that
> satisfies all of us. Variable naming is hard.
>
> --
> 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

Looking for MySQL Support ?
http://www.percona.com/support/

We need to finalize this bug. This is single show-stopper for next release.

I see current suggestions are:

INNODB_AUTO_LRU_DUMP
to
innodb_buffer_pool_restore_at_startup

INNODB_EXPAND_IMPORT
to
innodb_use_xtrabackup_table_import (?)

INNODB_OVERWRITE_RELAY_LOG_INFO
to
innodb_recovery_update_relay_log

INNODB_PASS_CORRUPT_TABLE
to
innodb_corrupt_table_action=assert|block (?)

Is it acceptable for everyone ?

Here are my final suggestions. After this I can only say "see my many
previous suggestions and my reasons for them" :-)

Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
  (NOTE this is different from Peter's suggestion, which I think is confusing)
Change INNODB_OVERWRITE_RELAY_LOG_INFO to innodb_recovery_update_relay_log
Change INNODB_PASS_CORRUPT_TABLE to innodb_corrupt_table_action=assert|warn
  (NOTE: standard InnoDB's behavior is "assert" and this should be the default)

Baron, Vadim

BTW what exactly happens now when you use "pass_corrupt_table" ? Do we
abort given query with error message ?
Does table become inaccessible until MySQL restart or does itbecome read
only ?

On Sun, Mar 6, 2011 at 11:59 AM, Xaprb <email address hidden> wrote:

> Here are my final suggestions. After this I can only say "see my many
> previous suggestions and my reasons for them" :-)
>
> Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
> Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
> (NOTE this is different from Peter's suggestion, which I think is
> confusing)
> Change INNODB_OVERWRITE_RELAY_LOG_INFO to innodb_recovery_update_relay_log
> Change INNODB_PASS_CORRUPT_TABLE to innodb_corrupt_table_action=assert|warn
> (NOTE: standard InnoDB's behavior is "assert" and this should be the
> default)
>
> --
> 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:
> Confirmed
>
> Bug description:
> After discussion with Baron, we should change names of following
> variables in 5.5:
>
> INNODB_AUTO_LRU_DUMP
> to
> innodb_buffer_pool_restore_at_startup
>
> INNODB_EXPAND_IMPORT
> to
> innodb_use_xtrabackup_table_import (?)
>
> INNODB_OVERWRITE_RELAY_LOG_INFO
> to
> innodb_recovery_update_relay_log
>
> INNODB_PASS_CORRUPT_TABLE
> to
> innodb_corrupt_table_action=assert|block (?)
>
> 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

Looking for MySQL Support ?
http://www.percona.com/support/

Peter

Idea is that table is inaccessible and query just returns error.

On Sun, Mar 6, 2011 at 4:54 PM, Peter Zaitsev <email address hidden> wrote:
> Baron, Vadim
>
> BTW what exactly happens now when you use "pass_corrupt_table"  ?  Do we
> abort given query with error message ?
> Does table become inaccessible until MySQL restart or does itbecome read
> only ?
>
> On Sun, Mar 6, 2011 at 11:59 AM, Xaprb <email address hidden> wrote:
>
>> Here are my final suggestions.  After this I can only say "see my many
>> previous suggestions and my reasons for them" :-)
>>
>> Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
>> Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
>>  (NOTE this is different from Peter's suggestion, which I think is
>> confusing)
>> Change INNODB_OVERWRITE_RELAY_LOG_INFO to innodb_recovery_update_relay_log
>> Change INNODB_PASS_CORRUPT_TABLE to innodb_corrupt_table_action=assert|warn
>>  (NOTE: standard InnoDB's behavior is "assert" and this should be the
>> default)
>>
>> --
>> 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:
>>  Confirmed
>>
>> Bug description:
>>  After discussion with Baron, we should change names of following
>>  variables in 5.5:
>>
>>  INNODB_AUTO_LRU_DUMP
>>  to
>>  innodb_buffer_pool_restore_at_startup
>>
>>  INNODB_EXPAND_IMPORT
>>  to
>>  innodb_use_xtrabackup_table_import (?)
>>
>>  INNODB_OVERWRITE_RELAY_LOG_INFO
>>  to
>>  innodb_recovery_update_relay_log
>>
>>  INNODB_PASS_CORRUPT_TABLE
>>  to
>>  innodb_corrupt_table_action=assert|block (?)
>>
>>  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
>
> Looking for MySQL Support ?
> http://www.percona.com/support/
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> 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:
>  Confirmed
>
> Bug description:
>  After discussion with Baron, we should change names of following
>  variables in 5.5:
>
>  INNODB_AUTO_LRU_DUMP
>  to
>  innodb_buffer_pool_restore_at_startup
>
>  INNODB_EXPAND_IMPORT
>  to
>  innodb_use_xtrabackup_table_import (?)
>
>  INNODB_OVERWRITE_RELAY_LOG_INFO
>  to
>  innodb_recovery_update_relay_log
>
>  INNODB_PASS_CORRUPT_TABLE
>  to
>  innodb_corrupt_table_action=assert|block (?)
>
>  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
>
...

Is error printed in error log in this case ?

I'm trying to figure out if "warn" is appropritate or do we need something
else ?

On Sun, Mar 6, 2011 at 5:04 PM, Vadim Tkachenko <email address hidden> wrote:

> Peter
>
> Idea is that table is inaccessible and query just returns error.
>
>
> On Sun, Mar 6, 2011 at 4:54 PM, Peter Zaitsev <email address hidden> wrote:
> > Baron, Vadim
> >
> > BTW what exactly happens now when you use "pass_corrupt_table" ? Do we
> > abort given query with error message ?
> > Does table become inaccessible until MySQL restart or does itbecome read
> > only ?
> >
> > On Sun, Mar 6, 2011 at 11:59 AM, Xaprb <email address hidden> wrote:
> >
> >> Here are my final suggestions. After this I can only say "see my many
> >> previous suggestions and my reasons for them" :-)
> >>
> >> Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
> >> Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
> >> (NOTE this is different from Peter's suggestion, which I think is
> >> confusing)
> >> Change INNODB_OVERWRITE_RELAY_LOG_INFO to
> innodb_recovery_update_relay_log
> >> Change INNODB_PASS_CORRUPT_TABLE to
> innodb_corrupt_table_action=assert|warn
> >> (NOTE: standard InnoDB's behavior is "assert" and this should be the
> >> default)
> >>
> >> --
> >> 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:
> >> Confirmed
> >>
> >> Bug description:
> >> After discussion with Baron, we should change names of following
> >> variables in 5.5:
> >>
> >> INNODB_AUTO_LRU_DUMP
> >> to
> >> innodb_buffer_pool_restore_at_startup
> >>
> >> INNODB_EXPAND_IMPORT
> >> to
> >> innodb_use_xtrabackup_table_import (?)
> >>
> >> INNODB_OVERWRITE_RELAY_LOG_INFO
> >> to
> >> innodb_recovery_update_relay_log
> >>
> >> INNODB_PASS_CORRUPT_TABLE
> >> to
> >> innodb_corrupt_table_action=assert|block (?)
> >>
> >> 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
> >
> > Looking for MySQL Support ?
> > http://www.percona.com/support/
> >
> > --
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> > 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:
> > Confirmed
> >
> > Bug description:
> > After discussion with Baron, we should change names of following
> > variables in 5.5:
> >
> > INNODB_AUTO_LRU_DUMP
> > to
> > innodb_buffer_pool_restore_at_startup
> >
> > INNODB_EXPAND_IMPORT
> > to
> > innodb_use_xtraba...

Yes, There should be corresponding error in error log.

On Sun, Mar 6, 2011 at 5:52 PM, Peter Zaitsev <email address hidden> wrote:
> Is error printed in error log in this case ?
>
> I'm trying to figure out if "warn" is appropritate or do we need something
> else ?
>
> On Sun, Mar 6, 2011 at 5:04 PM, Vadim Tkachenko <email address hidden> wrote:
>>
>> Peter
>>
>> Idea is that table is inaccessible and query just returns error.
>>
>>
>> On Sun, Mar 6, 2011 at 4:54 PM, Peter Zaitsev <email address hidden> wrote:
>> > Baron, Vadim
>> >
>> > BTW what exactly happens now when you use "pass_corrupt_table"  ?  Do we
>> > abort given query with error message ?
>> > Does table become inaccessible until MySQL restart or does itbecome read
>> > only ?
>> >
>> > On Sun, Mar 6, 2011 at 11:59 AM, Xaprb <email address hidden> wrote:
>> >
>> >> Here are my final suggestions.  After this I can only say "see my many
>> >> previous suggestions and my reasons for them" :-)
>> >>
>> >> Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
>> >> Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
>> >>  (NOTE this is different from Peter's suggestion, which I think is
>> >> confusing)
>> >> Change INNODB_OVERWRITE_RELAY_LOG_INFO to
>> >> innodb_recovery_update_relay_log
>> >> Change INNODB_PASS_CORRUPT_TABLE to
>> >> innodb_corrupt_table_action=assert|warn
>> >>  (NOTE: standard InnoDB's behavior is "assert" and this should be the
>> >> default)
>> >>
>> >> --
>> >> 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:
>> >>  Confirmed
>> >>
>> >> Bug description:
>> >>  After discussion with Baron, we should change names of following
>> >>  variables in 5.5:
>> >>
>> >>  INNODB_AUTO_LRU_DUMP
>> >>  to
>> >>  innodb_buffer_pool_restore_at_startup
>> >>
>> >>  INNODB_EXPAND_IMPORT
>> >>  to
>> >>  innodb_use_xtrabackup_table_import (?)
>> >>
>> >>  INNODB_OVERWRITE_RELAY_LOG_INFO
>> >>  to
>> >>  innodb_recovery_update_relay_log
>> >>
>> >>  INNODB_PASS_CORRUPT_TABLE
>> >>  to
>> >>  innodb_corrupt_table_action=assert|block (?)
>> >>
>> >>  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
>> >
>> > Looking for MySQL Support ?
>> > http://www.percona.com/support/
>> >
>> > --
>> > You received this bug notification because you are a direct subscriber
>> > of the bug.
>> > 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:
>> >  Confirmed
>> >
>> > Bug descri...

Then Warn is good :)

On Sun, Mar 6, 2011 at 5:53 PM, Vadim Tkachenko <email address hidden> wrote:

> Yes, There should be corresponding error in error log.
>
>
> On Sun, Mar 6, 2011 at 5:52 PM, Peter Zaitsev <email address hidden> wrote:
> > Is error printed in error log in this case ?
> >
> > I'm trying to figure out if "warn" is appropritate or do we need
> something
> > else ?
> >
> > On Sun, Mar 6, 2011 at 5:04 PM, Vadim Tkachenko <email address hidden>
> wrote:
> >>
> >> Peter
> >>
> >> Idea is that table is inaccessible and query just returns error.
> >>
> >>
> >> On Sun, Mar 6, 2011 at 4:54 PM, Peter Zaitsev <email address hidden> wrote:
> >> > Baron, Vadim
> >> >
> >> > BTW what exactly happens now when you use "pass_corrupt_table" ? Do
> we
> >> > abort given query with error message ?
> >> > Does table become inaccessible until MySQL restart or does itbecome
> read
> >> > only ?
> >> >
> >> > On Sun, Mar 6, 2011 at 11:59 AM, Xaprb <email address hidden> wrote:
> >> >
> >> >> Here are my final suggestions. After this I can only say "see my
> many
> >> >> previous suggestions and my reasons for them" :-)
> >> >>
> >> >> Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
> >> >> Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
> >> >> (NOTE this is different from Peter's suggestion, which I think is
> >> >> confusing)
> >> >> Change INNODB_OVERWRITE_RELAY_LOG_INFO to
> >> >> innodb_recovery_update_relay_log
> >> >> Change INNODB_PASS_CORRUPT_TABLE to
> >> >> innodb_corrupt_table_action=assert|warn
> >> >> (NOTE: standard InnoDB's behavior is "assert" and this should be the
> >> >> default)
> >> >>
> >> >> --
> >> >> 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:
> >> >> Confirmed
> >> >>
> >> >> Bug description:
> >> >> After discussion with Baron, we should change names of following
> >> >> variables in 5.5:
> >> >>
> >> >> INNODB_AUTO_LRU_DUMP
> >> >> to
> >> >> innodb_buffer_pool_restore_at_startup
> >> >>
> >> >> INNODB_EXPAND_IMPORT
> >> >> to
> >> >> innodb_use_xtrabackup_table_import (?)
> >> >>
> >> >> INNODB_OVERWRITE_RELAY_LOG_INFO
> >> >> to
> >> >> innodb_recovery_update_relay_log
> >> >>
> >> >> INNODB_PASS_CORRUPT_TABLE
> >> >> to
> >> >> innodb_corrupt_table_action=assert|block (?)
> >> >>
> >> >> 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
> >> >
> >> > Looking for MySQL Support ?
> >> > http://www.percona.com/support/
> >> >
> >> > --
> >> > You received this bug notifica...

Thank you, Baron.

They are also OK for me.
I will fix soon.

Xaprb wrote:
> Here are my final suggestions. After this I can only say "see my many
> previous suggestions and my reasons for them" :-)
>
> Change INNODB_AUTO_LRU_DUMP to innodb_buffer_pool_restore_at_startup
> Change INNODB_EXPAND_IMPORT to innodb_import_table_from_xtrabackup
> (NOTE this is different from Peter's suggestion, which I think is confusing)
> Change INNODB_OVERWRITE_RELAY_LOG_INFO to innodb_recovery_update_relay_log
> Change INNODB_PASS_CORRUPT_TABLE to innodb_corrupt_table_action=assert|warn
> (NOTE: standard InnoDB's behavior is "assert" and this should be the default)
>

Documentation changes:

Pages changed:
http://www.percona.com/docs/wiki/percona-server:features:innodb_expand_import
http://www.percona.com/docs/wiki/percona-server:features:innodb_lru_dump_restore
http://www.percona.com/docs/wiki/percona-server:features:innodb_overwrite_relay_log_info
http://www.percona.com/docs/wiki/percona-server:features:innodb_pass_corrupt_table

Indexes updated (added 4 system variables):
http://www.percona.com/docs/wiki/percona-server:features:indexes:index_system_variables
http://www.percona.com/docs/wiki/percona-server:features:indexes:variable_reference

Fred,

Do we really want to have page named "innod_pass_corrupt_table" if option
was renamed ?

Should not we redirect the page to the one with new name and explain it was
the old name ?

On Wed, Mar 9, 2011 at 8:07 AM, Fred Linhoss <email address hidden>wrote:

> Documentation changes:
>
> Pages changed:
>
> http://www.percona.com/docs/wiki/percona-server:features:innodb_expand_import
>
> http://www.percona.com/docs/wiki/percona-server:features:innodb_lru_dump_restore
>
> http://www.percona.com/docs/wiki/percona-server:features:innodb_overwrite_relay_log_info
>
> http://www.percona.com/docs/wiki/percona-server:features:innodb_pass_corrupt_table
>
> Indexes updated (added 4 system variables):
>
> http://www.percona.com/docs/wiki/percona-server:features:indexes:index_system_variables
>
> http://www.percona.com/docs/wiki/percona-server:features:indexes:variable_reference
>
> --
> 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:
> Fix Committed
>
> Bug description:
> After discussion with Baron, we should change names of following
> variables in 5.5:
>
> INNODB_AUTO_LRU_DUMP
> to
> innodb_buffer_pool_restore_at_startup
>
> INNODB_EXPAND_IMPORT
> to
> innodb_use_xtrabackup_table_import (?)
>
> INNODB_OVERWRITE_RELAY_LOG_INFO
> to
> innodb_recovery_update_relay_log
>
> INNODB_PASS_CORRUPT_TABLE
> to
> innodb_corrupt_table_action=assert|block (?)
>
> 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

Looking for MySQL Support ?
http://www.percona.com/support/

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2610