Just use XFS. it's a solve problem..
Kevin
On 3/8/07, Christopher A. Kantarjiev [EMAIL PROTECTED] wrote:
I'm setting up mysql on linux for the first time (have been using OpenBSD
and
NetBSD with UFS until now). The default file system is ext3fs, and I don't
mind
that, but it seems
On 3/8/07, abhishek jain [EMAIL PROTECTED] wrote:
On 3/6/07, abhishek jain [EMAIL PROTECTED] wrote:
On 3/6/07, Nils Meyer [EMAIL PROTECTED] wrote:
Hi,
abhishek jain wrote:
I am having a database with varchar(255) columns named title,
extra_info1,extra_info2,extra_info3 .
Here's what we did and still do :
Our 4.x tables and databases were/are in Latin-1 and all the 5.x tables
are/were in utf8. That means that the entire regiment of items (every column,
every table, every database) in the old system (4.1) was latin-1 and all the
destination items in 5.x were
Dear MySQL general list members,
I have a guest book on a small club web page that has been getting
regular spam in with
the legitimate replies.
I use MySQL and (I think) Apache-style PHP to run the database. I know
it is PHP and
am certain when I started these survey and guest book it was
Enabling journaling isn't going to halve your performance. Remember, a journal is a record of what happened. It is only added to,
not updated, so while there is overhead, performance is fairly good. ext3 also has a few different journaling optins.
Journaling is mainly for quick recovery and
When you say 70% iowait are you referring to vmstat results? There are a lot of things that can be causing iowait, the most
obvious being the disks are busy. In which case giving MySQL more memory won't really help, unless it's something that can be solved
with caching.
What does your context
On 9 Mar 2007, at 15:22, Brent Baisley wrote:
When you say 70% iowait are you referring to vmstat results?
There are a lot of things that can be causing iowait, the most
obvious being the disks are busy. In which case giving MySQL more
memory won't really help, unless it's something that
hi all
The mysql manual inform that:
EX. century int(4)
The result is that values in the century column usually are
displayed four digits wide. However, its important to undesrstand that the
display width is unrelated to the range of the datatype. The display
width specified for a column
Brent,
Thanks for your response.
Enabling journaling isn't going to halve your performance.
I was careful to say write speed, not performance.
I already have my data and index files on separate drives (raid
volumes, actually, each made up of complete drives). What I see
is that the index
Yes, the article did lack a lot of methodology information.
Since you already have things separated and it seems your data isn't ciritical, meaning losing it would be a pain as opposed to
life threatening, you can turn off journaling for those file systems. You may actually want to look at
Yes, the article did lack a lot of methodology information.
This one is *lots* better.
http://www.bullopensource.org/ext4/sqlbench/index.html
Losing data is always bad - that's why it's in a database, not a filesystem.
But these systems have been pretty reliable and are on UPS, etc. This
is a
Would using merge tables be an option? You would have to split your data, but
then each individual table could be within MySQL
memory limits. Divide and conquer. You would need a way to work around your
insert ignore requirement. But the end result could be
much faster.
The solution I use for
Merge tables aren't an easy option here. There's a higher level
data partitioning that we're putting into place, though, and it's
been shown to help a lot. But I also want to get as much out of the
file system as I can.
The solution I use for duplicate filtering is to to create a
load table
I built a new server at my server farm because the old one was corrupt. I had a
hunch it had to do with the new 500 GB hard drive I bought. I told them to
check it out. Apparently, they didn't. It zapped my database. I went to
deinstall and reinstall mysql from FBSD port, but when I run it I
Never mind. I forgot this command:
/usr/local/bin/mysql_install_db --user=mysql
Drew2
Drew Jenkins [EMAIL PROTECTED] wrote: I built a new server at my server farm
because the old one was corrupt. I had a hunch it had to do with the new 500 GB
hard drive I bought. I told them to check it out.
Hi;
I rebuilt mysql and injected the database which had user mysqluser and a root
user. Both got wiped out. It looks like the data is intact other than that.
Look at this:
mysql CREATE USER dev IDENTIFIED BY 'pass';
Query OK, 0 rows affected (0.04 sec)
mysql CREATE USER mysqluser IDENTIFIED BY
Problem solved:
/usr/local/bin/mysql_fix_privilege_tables2
Drew Jenkins [EMAIL PROTECTED] wrote: Hi;
I rebuilt mysql and injected the database which had user mysqluser and a root
user. Both got wiped out. It looks like the data is intact other than that.
Look at this:
mysql CREATE USER dev
On 3/9/07, Gloria McMillan [EMAIL PROTECTED] wrote:
Dear MySQL general list members,
I have a guest book on a small club web page that has been getting
regular spam in with
the legitimate replies.
I use MySQL and (I think) Apache-style PHP to run the database. I know
it is PHP and
am certain
18 matches
Mail list logo
