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
> On Sat, Mar 7, 2009 at 12:10 PM, 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
>>>
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 a
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, wrote:
> Thanks Baron...
>
> Also, curious question.. as you might have used what is called GOOD hw
> configurarion with RAID 5/10 .. so whats the
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
On Sat, Mar 7, 2009 at 12:10 PM, 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 the
>> 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 t
