Alexi1952 <alexi1...@yandex.ru> writes:
Hi Alexi! Sorry for the delay in answering, things have been quite busy...
> With WL36 and WL40 we have:
> mysqlbinlog options:
> --database=db
> --rewrite-db=db_from->db_to
> --do-table=db.tbl
> --ignore-table=db.tbl
> --wild-do-table=pattern.pattern
> --wild-ignore-table=pattern.pattern
>
> replication options:
> --replicate-rewrite-db=db_from->db_to
> --replicate-do-db=db
> --replicate-ignore-db=db
> --replicate-do-table=tbl
> --replicate-ignore-table=tbl
> --replicate-wild-do-table=db.tbl
> --replicate-wild-ignore-table=db.tbl
>
> 1. In mysqlbinlog we do not have --do_db and --ignore_db options.
> Does it mean that instead it is supposed to use:
>
> --replicate-wild-do-table=db.%
> --replicate-wild-ignore-table=db.%
>
> respectively?
I think the --database option of mysqlbinlog is supposed to be similar to
mysqldump of a particular database, rather than similar to replication.
>
> Compared with other options, --database option looks like
> a "foreign body" :
>
> - contrary to other options, it allows to specify only one
> database (with multiple --database's only the last one is
> used);
>
> - having with --database an analog of do_db, we have no
> similar analog of ignore_db.
>
> 2. In replication two functions are used for filtering databases:
>
> - db_ok(const char* db) which matches db only with do-db and
> ignore-db rules;
>
> - db_ok_with_wild_table(const char* db) which matches db only
> with wild-do-table=db.% and wild-ignore-table=db.% rules.
> This function is applied only to CREATE DB, DROP DB, and
> ALTER DATABASE statements.
>
> In mysqlbinlog, should we follow the same scheme, namely:
>
> - db_ok() for matching db with --database option only;
> - db_ok_with_wild_table() for statements listed above?
It is a bit of a complex issue, but your suggestion sounds reasonable.
>
> 3. According to replication filtering rules, --replicate-rewrite_db
> is always done _before_ other --replicate-* rules are tested;
> see explanation for --replicate-rewrite-db in RefMan (16.1.3.3.
> Replication Slave Options and Variables), or the following piece
> of code in og_event.cc:
>
> int Table_map_log_event::do_apply_event(Relay_log_info const* rli)
> {
> RPL_TABLE_LIST* table_list;
> ...
> strmov(table_list->db, rpl_filter->get_rewrite_db(m_dbnam,
> &dummy_len));
> ...
> if (...!rpl_filter->db_ok(table_list->db) ...)
> ...
> }
>
> And what about --database + rewrite-db for mysqlbinlog? If we mean to
> output only database xxx with renaming it to yyy, should we use
>
> (1) mysqlbinlog --database=xxx --rewrite-db=xxx->yyy
> or
> (2) mysqlbinlog --database=yyy --rewrite-db=xxx->yyy
>
> In current WL36 design it is supposed that (1) should be used
> (surely, this can easily be redesigned). But this becomes confused
> with using of --wild-do-table + replication filtering rules,
> for which we should use:
>
> (3) --wild-do-table=yyy.% --rewrite-db=xxx->yyy
Personally, I think it makes more sense to apply the filter before the rewrite
in mysqlbinlog. Even though this is different from how replication works. (2)
and (3) appear quite confusing (to the user).
I think the difference is that with replication, the
--replicate-[wild-]{do,ignore}-table options concern how the binlog is
_applied_. So it makes sense (maybe) to rewrite the events first, and then
apply them (since the other way around is impossible).
But with mysqlbinlog we are not applying events, only filtering. So I think it
makes more sense for filtering rules to apply to the name before rewriting.
We can't change replication to do filtering before rewriting, which leaves it
inconsistent with mysqlbinlog according to this. But instead we could use
different names for the options, as I think the -do- implies actually applying
the events rather than filtering.
So maybe
--include-table
--exclude-table
--wild-include-table
--wild-exclude-table
and these (and --database) are done before rewrite. And the --wild-* forms
should be sufficient for more complex database filtering (so no need for
options similar to --replicate-{do,ignore}-db).
At least that's my immediate opinion.
Good analysis BTW!
- Kristian.
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
