Didn't want this to go unanswered, although I don't have any great info for you.
As long as you're running a 64-bit OS and a 64-bit version of MySQL,
there's no technical reason it would be limited to less than the
addressable space (that I know of). The main gain would be the ability
to set large
What error is shown by 'show slave status\G' on server C after you
issue that query?
There's all sorts of things that could break replication...
On Tue, Jan 20, 2009 at 7:21 AM, Krishna Chandra Prajapati
wrote:
> Hi Baron,
>
> In production we have three servers.
>
> A> B ---
If you're looking to load-balance the write requests... sorry, MySQL
replication won't help much (if at all).
Think about it... every insert/update/delete simply *has* to happen on
every server. You only *send* it to one of them, sure... but then it
replicates from that one to the other(s) and hap
on servers,
> once you have the slave practically you have online backups
>
> I will try to answer one by one.
>
> Jake Maul wrote:
>>
>> If you're making backups of the DB, it might be possible to use the
>> backup data as a replication snapshot for kickstarting
If you're making backups of the DB, it might be possible to use the
backup data as a replication snapshot for kickstarting the slave. You
would need to be recording the master log file and position at the
time the backups are made as well, however (usually easy to hack in if
you're not already reco
I few random things come to mind...
1) Try the query with IGNORE INDEX calldate_idx ... I can't see how
this could possibly be faster, but I always like to check anyway. In
your case this should result in a full table scan, given the
information you've given us.
2) If the performance problem come
There's a couple ways to go about this. The simplest thing (and what
we use in most of our simple monitoring cases) is a shell script that
checks the output of "show slave status\G" on the slave periodically.
If it reports that either thread isn't running, or there's something
in "Last error", or t
MySQL processes each request in a separate thread... hence, it is
*always* multi-core capable. Check the thread_concurrency setting in
my.cnf. Also, although not exactly related, check the size of
thread_cache.
Are you by chance running 1 long-running query at a time? A single
query runs in a sing
I don't have any links, but in general we don't do very much as far as
tuning is concerned.
Here's a few things I can think of off the top of my head that we
sometimes do if we're worried about performance:
blockdev --setra 2048 /dev/sda (substitute an appropriate readahead
amount and device name
I see that you've already decided on 64-bit anyway, but here's a more
explicit reason to do so: in 32-bit (PAE-mode), no single process can
allocate more than 4GB of memory- that's all the address space there
is. The *system* can see it all, but each process can only work with a
single 4GB chunk of
I have only 3 things worth mentioning:
You might want to lower max_connections... wouldn't want someone to
actually start *using* 100 connections on a desktop box that only has
256MB RAM to begin with... it'll be in swap instantly (if it isn't
already, before you've even started MySQL).
Why InnoD
>From dev.mysql.com:
myisam_max_sort_file_size :
The maximum size of the temporary file that MySQL is allowed to use
while re-creating a MyISAM index (during REPAIR TABLE, ALTER TABLE, or
LOAD DATA INFILE). If the file size would be larger than this value,
the index is created using the key cach
I've never had a lot of luck tracking down this sort of problem. One
thing I've found to be a good first step is to add each server
involved to the other server's /etc/hosts file (and restart MySQL so
it notices).
Don't have much more to offer other than the usual suspects: recent
versions, persis
Deleting the files from the command line is not considered the 'correct' way:
http://dev.mysql.com/doc/refman/5.0/en/purge-master-logs.html
There should be a 'log-bin' line in your my.cnf just comment it if
you don't want binary logs. Yes, they're mostly just used for
master/slave replication,
14 matches
Mail list logo
