Which MySQL version best to use and with/without linux threads?

Hi,

I've got a MySQL 4.0.16 DB running with several DB instances
in it. So 
far, so good, but I'm looking for a bit of advice.

I've got a few small questions:

Firstly: is it (for a webserver) better to compile MySQL
with 
linux-threads or without? I seem to recall having read that
Linux uses a 
better threading mechanism, and that MySQL really benefits
from this... 
What do you all think?

Then, I'm currently configuring a second beast, eehhhh,
server. 
Being an AMD-64 19" server, running FreeBSD 5.4-Release
AMD64. On it, I 
instinctively installed the latest MySQL 4.0.x version
(being 4.0.26) 
and it works flawlessly with the data from my current
production machine.

Still so far, so good. 

However... I was wondering what the advantages (and
potential 
disadvantages!) may be of using a newer line of the MySQL
DB.

Can anyone tell me what the advantages/pitfalls may be of
using v4.1.x 
or even v5, over using 4.0.x ?

A year or two ago I installed a 4.1.x version and there were
some issues 
then with using the passwords, coming from a 3.23.x or 4.0.x
one. I 
don't remember the details, but it had something to do with
that...

Any advice is more than welcome, as this is the moment for
me to make 
this sort of decicion, and I'd like to do so based on real
user's 
experiences...

Thank you kindly in advance, and with kind regards,
Olaf Greve
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On 9/30/05, Olaf Greve <o.greveaxis.nl> wrote:
> Hi,
>
> I've got a MySQL 4.0.16 DB running with several DB
instances in it. So
> far, so good, but I'm looking for a bit of advice.
>
> I've got a few small questions:
>
> Firstly: is it (for a webserver) better to compile
MySQL with
> linux-threads or without? I seem to recall having read
that Linux uses a
> better threading mechanism, and that MySQL really
benefits from this...
> What do you all think?
>
> Then, I'm currently configuring a second beast, eehhhh,
server. 
> Being an AMD-64 19" server, running FreeBSD
5.4-Release AMD64. On it, I
> instinctively installed the latest MySQL 4.0.x version
(being 4.0.26)
> and it works flawlessly with the data from my current
production machine.
>
> Still so far, so good. 
>
> However... I was wondering what the advantages (and
potential
> disadvantages!) may be of using a newer line of the
MySQL DB.
>
> Can anyone tell me what the advantages/pitfalls may be
of using v4.1.x
> or even v5, over using 4.0.x ?
>
> A year or two ago I installed a 4.1.x version and there
were some issues
> then with using the passwords, coming from a 3.23.x or
4.0.x one. I
> don't remember the details, but it had something to do
with that...
>
> Any advice is more than welcome, as this is the moment
for me to make
> this sort of decicion, and I'd like to do so based on
real user's
> experiences...
>
> Thank you kindly in advance, and with kind regards,
> Olaf Greve
> _______________________________________________
> freebsd-questionsfreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
> To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"
>

I'm not a very experienced MySQL user, but in
the absence of a better reply, here it goes.

linuxthreads were only important on FreeBSD 4.x.
Starting with 5.x we have a more efficient threading
model. Extensive testing did not reveal any significant
performance increase with MySQL compiled with
linuxthreads on FreeBSD 5.x. You'd better forget
about linuxthreads for good.

As for the MySQL version (branch) - the only
difference you should care about is feature set.
If you feel comfortable without triggers and
stored procedures (their absence makes
many professional MSSQL/Oracle/Postgres
users frown upon MySQL) you shouldn't be
looking at MySQL 5.0 for at least another
half a year. As for 4.1/4.0 - you should probably
stick to 4.0 on your mission-critical servers,
but certainly try 4.1 on your production, but
not so critical servers.


Cheerz,
Andrew P.
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Hello,

On Fri, Sep 30, 2005 at 08:08:32PM +0400 or thereabouts,
Andrew P. wrote:
> As for the MySQL version (branch) - the only
> difference you should care about is feature set.
> If you feel comfortable without triggers and
> stored procedures (their absence makes
> many professional MSSQL/Oracle/Postgres
> users frown upon MySQL) you shouldn't be
> looking at MySQL 5.0 for at least another
> half a year. As for 4.1/4.0 - you should probably
> stick to 4.0 on your mission-critical servers,
> but certainly try 4.1 on your production, but
> not so critical servers.

  4.1 has collations, ndb clustering.. I am currently
deploying these
  features to our.. mission critical servers.. and I am
playing with
  idea to use 5.0.13 for this - after very intensive testing
of course
  ..

  If one has no need for collations and clustering, then
your advice to
  stay with 4.0 is good.. one might experience slight
difficulties while
  migrating databases with utf8 data (length of keys etc.).

-- 
martin hudec


   * 421 907 303 393
   * corwinaeternal.net
   * http://www.aeternal.net

"Nothing travels faster than the speed of light with
the possible 
exception of bad news, which obeys its own special
laws."

   Douglas Adams, "The Hitchhiker's Guide to the
Galaxy"

On 10/01/05 00:08 Andrew P. said the following:
> linuxthreads were only important on FreeBSD 4.x.
> Starting with 5.x we have a more efficient threading
> model. Extensive testing did not reveal any significant

is this definitive, i.e. that on 5.x linuxthreads are worse
off than native 
freebsd threads ? i'm not trying to be a troll, but over on
the asterisk 
mailing lists, we're in the midst of discussing if
/usr/ports/net/asterisk 
should be using linuxthreads or pthreads by default. on 4.x
(which i'm 
still on), linuxthreads has oodles better performance than
native pthreads, 
but i havent really done any testing on 5.x or 6.x.

any advice here would be much appreciated.

-- 
Regards,                           /_/   "All dogs go
to heaven."
dineshalphaque.com                (0 0)    http://www.alphaque.com/
+==========================----oOO--(_)--OOo----============
==============+
| for a in past present future; do                          
             |
|   for b in clients employers associates relatives
neighbours pets; do   |
|   echo "The opinions here in no way reflect the
opinions of my $a $b."  |
| done; done                                                
             |
+===========================================================
==============+
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On 10/3/05, Dinesh Nair <dineshalphaque.com> wrote:
> On 10/01/05 00:08 Andrew P. said the following:
> > linuxthreads were only important on FreeBSD 4.x.
> > Starting with 5.x we have a more efficient
threading
> > model. Extensive testing did not reveal any
significant
>
> is this definitive, i.e. that on 5.x linuxthreads are
worse off than native
> freebsd threads ? i'm not trying to be a troll, but
over on the asterisk
> mailing lists, we're in the midst of discussing if
/usr/ports/net/asterisk
> should be using linuxthreads or pthreads by default. on
4.x (which i'm
> still on), linuxthreads has oodles better performance
than native pthreads,
> but i havent really done any testing on 5.x or 6.x.
>
> any advice here would be much appreciated.
>
> --
> Regards,                           /_/   "All
dogs go to heaven."
> dineshalphaque.com                (0 0)    http://www.alphaque.com/
>
+==========================----oOO--(_)--OOo----============
==============+
> | for a in past present future; do                     
                  |
> |   for b in clients employers associates relatives
neighbours pets; do   |
> |   echo "The opinions here in no way reflect the
opinions of my $a $b."  |
> | done; done                                           
                  |
>
+===========================================================
==============+
>

Yes, it's definitely so. Google for a few minutes and
you'll see it for yourself. Stick with native threads.
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Friday 30 September 2005 06:22 am, Olaf Greve wrote:

> Then, I'm currently configuring a second beast, eehhhh,
server. 
> Being an AMD-64 19" server, running FreeBSD
5.4-Release AMD64. On it,
> I instinctively installed the latest MySQL 4.0.x
version (being
> 4.0.26) and it works flawlessly with the data from my
current
> production machine.

The only problem is that linuxthreads doesn't exist on
FreeBSD/amd64. 
You have to use one of the native thread libraries.

Your choices on 5.4 are not that great.  I'd suggest libthr
on 6.0 as 
the closest match to linuxthreads, but I don't recall if it
is 
available on 5.4.  I have a feeling it isn't.  I have a
feeling your 
choices are libc_r or libpthread (kse).  libpthread should
smoke libc_r 
for disk IO performance in general.  But modern libthr (on
6.0+) should 
give it a serious run for its money.

-- 
Peter Wemm - peterwemm.org; peterFreeBSD.org; peteryahoo-inc.com
"All of this is for nothing if we don't go to the
stars" - JMS/B5
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Am Mittwoch, 5. Oktober 2005 02:17 CEST schrieb Peter Wemm:
> On Friday 30 September 2005 06:22 am, Olaf Greve wrote:
> > Then, I'm currently configuring a second beast,
eehhhh, server. 
> > Being an AMD-64 19" server, running FreeBSD
5.4-Release AMD64. On it,
> > I instinctively installed the latest MySQL 4.0.x
version (being
> > 4.0.26) and it works flawlessly with the data from
my current
> > production machine.
>
> The only problem is that linuxthreads doesn't exist on
FreeBSD/amd64.
> You have to use one of the native thread libraries.
>
> Your choices on 5.4 are not that great.  I'd suggest
libthr on 6.0 as
> the closest match to linuxthreads, but I don't recall
if it is
> available on 5.4.  I have a feeling it isn't.  I have a
feeling your
> choices are libc_r or libpthread (kse).  libpthread
should smoke libc_r

Smoke of brakes or smoke of the engine?

> for disk IO performance in general.  But modern libthr
(on 6.0+) should
> give it a serious run for its money.

Please! Not all readers are native enlish speaking, it
sounds nice but it 
doesn't help clarifying anything. I guess libthr is the
favourite choice 
but I only guess since I never heard of smoking thread
libraries nor of 
"run for money". I'm suffering from the list's
english enough, please 
don't use phrases... 

-Harry

On 10/5/05, Emanuel Strobl <Emanuel.stroblgmx.net> wrote:
> Am Mittwoch, 5. Oktober 2005 02:17 CEST schrieb Peter
Wemm:
> > On Friday 30 September 2005 06:22 am, Olaf Greve
wrote:
> > > Then, I'm currently configuring a second
beast, eehhhh, server. 
> > > Being an AMD-64 19" server, running
FreeBSD 5.4-Release AMD64. On it,
> > > I instinctively installed the latest MySQL
4.0.x version (being
> > > 4.0.26) and it works flawlessly with the data
from my current
> > > production machine.
> >
> > The only problem is that linuxthreads doesn't
exist on FreeBSD/amd64.
> > You have to use one of the native thread
libraries.
> >
> > Your choices on 5.4 are not that great.  I'd
suggest libthr on 6.0 as
> > the closest match to linuxthreads, but I don't
recall if it is
> > available on 5.4.  I have a feeling it isn't.  I
have a feeling your
> > choices are libc_r or libpthread (kse). 
libpthread should smoke libc_r
>
> Smoke of brakes or smoke of the engine?
>
> > for disk IO performance in general.  But modern
libthr (on 6.0+) should
> > give it a serious run for its money.
>
> Please! Not all readers are native enlish speaking, it
sounds nice but it
> doesn't help clarifying anything. I guess libthr is the
favourite choice
> but I only guess since I never heard of smoking thread
libraries nor of
> "run for money". I'm suffering from the
list's english enough, please
> don't use phrases... 
>
> -Harry
>
>
>

Oh, come on

http://dictionary.com/
http:/
/dictionary.reference.com/search?q=smoke
http://dictionary.reference.com/search?q=for%20one
%27s%20money

Spend some time looking words up. It's worth it.
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Hi,

At present I'm in the last stages of configuring my new
(primary) web 
server. As soon as I'm done with it, I want to place the
machine at the 
server farm, connect it to the present live server, take the
later one 
off-line for an hour or so, hook it up via local network to
the new 
primary server, rsync the necessary files, and update the
MySQL DB.

Once that's done, I'll simply swap the external (i.e.
"world") IP 
addresses of both machines, and then the new primary server
should be 
pretty much up and running.

Now, what I'd like to do, is: make the current live server a
fall-back 
machine (connected to the outside world, but normally never
mapped via 
DNS entries, unless the primary server goes down, and I
assign the IP 
address of the live machine to the fall-back machine).

What I'd like to do as a strategy is the following:

Primary server:
- Runs FreeBSD 5.4-Release AMD64
- Connected to outside world via NIC 1  a real
IP address; say 
123.45.67.89, publicly available as webserver incl. DNS
mappings, etc.
- Connected via a cross-wire cable to fall-back machine via
NIC 2 ; 
using address 192.168.1.1

Fall-back server:
- Runs FreeBSD 5.2.1-Release i386
- Connected to outside world via NIC 1  a real
IP address; say 
123.45.67.88, "privately" available by IP address
only (mainly for SSH 
access, serves as fall-back and staging machine)
- Connected via a cross-wire cable to primary server machine
via NIC 2 ; 
using address 192.168.1.2


Now, the machines are (obviously) not the same hardware
wise, nor OS 
wise. I may (or may not) decide to install FreeBSD
5.4-release i386 on 
the fall-back server, or I may just leave that "as
is".

The things I'm wondering about are the following:
-How can I best set-up such a dual network configuration,
such that one 
network will not interfere with the other?
-Can I somehow 'force' the machines to automatically
interpret anything 
in the 192.168.1.x range to be local, and hence
automatically use NIC 2, 
instead of using the NIC 1 adapter (which handles my outside
world traffic)?
-Is it sufficient to set-up the Rsync daemon on the primary
machine to 
only allow connections from 192.168.1.2, and to run as root,
such that I 
can easily use the cross-wire as a kind of direct tunnel to
perform the 
syncing?
-What is the nicest MySQL replication mechanism? Presently I
use a 
mechanism that dumps the MySQL DB instances, and will then
push them 
over an SSH tunnel to the fall-back machine, directly
loading them into 
the MySQL DB on that machine. Is MySQL's master-slave
syncing perhaps a 
better choice?

Cheers, and thank in advance for any and all replies!
Olafo
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

> 
> Am Mittwoch, 5. Oktober 2005 02:17 CEST schrieb Peter
Wemm:
> > On Friday 30 September 2005 06:22 am, Olaf Greve
wrote:
> > > Then, I'm currently configuring a second
beast, eehhhh, server. 
> > > Being an AMD-64 19" server, running
FreeBSD 5.4-Release AMD64. On it,
> > > I instinctively installed the latest MySQL
4.0.x version (being
> > > 4.0.26) and it works flawlessly with the data
from my current
> > > production machine.
> >
> > The only problem is that linuxthreads doesn't
exist on FreeBSD/amd64.
> > You have to use one of the native thread
libraries.
> >
> > Your choices on 5.4 are not that great.  I'd
suggest libthr on 6.0 as
> > the closest match to linuxthreads, but I don't
recall if it is
> > available on 5.4.  I have a feeling it isn't.  I
have a feeling your
> > choices are libc_r or libpthread (kse). 
libpthread should smoke libc_r
> 
> Smoke of brakes or smoke of the engine?
> 
> > for disk IO performance in general.  But modern
libthr (on 6.0+) should
> > give it a serious run for its money.
> 
> Please! Not all readers are native enlish speaking, it
sounds nice but it=20
> doesn't help clarifying anything. I guess libthr is the
favourite choice=20
> but I only guess since I never heard of smoking thread
libraries nor of=20
> "run for money". I'm suffering from the
list's english enough, please=20
> don't use phrases... 
> Harry

You are right of course.   Slang and idiomatic expressions
generally
do not help communications across cultures or language
backgrouns.
But, I would add that English is a very 'subjective'
language (no pun
intended) and as such is highly context based.   Many
expressions, 
including many standard expressions can only be understood
from the
context in which they are used.   

This can make things difficult, but it can also make it easy
because you 
can usually guess the meaning from the context, even if you
do not know 
the phrase or the word.  I have seen stories told in which
one word 
(a nonsense sylable) was used to substitute for every verb
and noun and 
most of the adjectives and adverbs and it was still possible
to understand 
the story with a little guessing.   In fact there used to be
a kids TV 
cartoon that did essentially that called the Smurfs.

So, although it is better to use clear language, don't panic
when 
you see something.   Take a good guess and you will probably
be right.

As for MySQL version, pick one.   It will work.

////jerry

> 
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"