BTW, same problems occur on the slave side with replicate-do and
replicate-ignore. They seem to go away with row-based replications - that's
our big hope, anyway. It appears to work so far in test.
On Sat, Mar 7, 2009 at 12:41 PM, Baron Schwartz wrote:
> Sure. Set binlog-do-db to "foo" and se
Sure. Set binlog-do-db to "foo" and set up a slave, and then try this:
create database foo;
create database bar;
use bar;
create table foo.table1(a int);
use foo;
insert into table1(a) values(1);
Now go to the slave and check replication. It's broken:
Last_Error: Error 'Table 'foo.table1' d
Hi, care to elaborate on the pit-falls of binlog-do-db?
Thanks,
Atle
On Wed, 4 Mar 2009, Baron Schwartz wrote:
No. But I would recommend removing binlog-do-db and using
replicate-wild-do-table=.% on the slave instead. The
binlog-do-db approach has many pitfalls anyway, and is likely to burn
Hi,
On Wed, Mar 4, 2009 at 7:25 AM, Thomas Spahni wrote:
> Hi
>
> I'm stuck with the following problem:
>
> SLAVE has a bunch of databases of which one or two are replicated from
> MASTER.
>
> I'm writing a shell script to be run by an ordinary user on SLAVE. This
> script should know which of th
Hi
I'm stuck with the following problem:
SLAVE has a bunch of databases of which one or two are replicated from
MASTER.
I'm writing a shell script to be run by an ordinary user on SLAVE. This
script should know which of the databases on SLAVE are replicated.
Configuration: MASTER has --bin
