Is there a way I can restore the concurrent select feature to a working
state without having to shut down the server and rebuild the entire data
base?
Usually when concurrent insert is not permitted, it's because there
are holes in the table that cause inserts to go somewhere other than
at
On Sat, Mar 7, 2009 at 12:10 PM, buf...@biffco.net wrote:
Is there a way I can restore the concurrent select feature to a working
state without having to shut down the server and rebuild the entire data
base?
Usually when concurrent insert is not permitted, it's because there
are holes in
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'
Check the archives for the last couple of weeks, I posted some
benchmarks from a client's RAID10 4-disk array.
Baron
On Fri, Mar 6, 2009 at 8:21 PM, dbrb2002-...@yahoo.com wrote:
Thanks Baron...
Also, curious question.. as you might have used what is called GOOD hw
configurarion with RAID
It's not skipping any rows. When you select records from a database,
it gets them in the order that is quickest to retrieve them, not the
order they were entered. The natural order is how they are stored on
disk. As your database is updated over time, this order may change.
If you have an
On Sat, Mar 7, 2009 at 12:10 PM, buf...@biffco.net wrote:
Is there a way I can restore the concurrent select feature to a
working
state without having to shut down the server and rebuild the entire
data
base?
Usually when concurrent insert is not permitted, it's because there
are holes
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 ba...@xaprb.com wrote:
Sure. Set binlog-do-db
