17 Jul
2008
17 Jul
'08
7:39 p.m.
----- "Sajith T S" <sajith(a)gmail.com> wrote:
How is the overall experience like re. deploying
openser with mysql
clusters?
Good enough. Just setup A record pointing at 2 or more api nodes and set them up with
virtual ips (heartbeat works quite well...). Openser will recover if one of the nodes
fail.
Are there gotchas etc that need to be taken care of?
(For
example, a 2006 article [1] says that "The MySQL NDB engine currently
runs its database completely in memory. This means that you have to
be
able to fit your database in memory." But this is not documented as
a
limitation in mysql faq.)
It's a feature and it's in the first sentence of cluster overview: "...
enables clustering of in-memory databases" ;)
Gotchas:
- don't bother with 5.0 - it's got strange issues
- 5.1.23 was the last version of 5.1.X with ndb. Now you have to compile carrier grade
edition from source.
- ping database once in a while (every database in a cluster) by *writing* to some table.
ndb sometimes just locks itself, but allows selects (locks internally - I've never
used lock statements). Restarting api node is enough in that case.
- No schema change needed - it just works with standard tables.
- Inserts / updates will be slower - not much, but anyway.
- hang out in #mysql-ndb channel on freenode -> you'll learn some magic ndb-mgm
commands which are sometimes not documented.
Otherwise, it's not that different from a standard mysql database.
---
Stan
17 Jul
17 Jul
7:42 p.m.
New subject: [OpenSER-Users] openser + mysql clusters
On Thursday 17 July 2008, Stanisław Pitucha wrote:
[..]
Hi Stanisław,
thanks for the information.
- 5.1.23 was the last version of 5.1.X with ndb. Now
you have to compile
carrier grade edition from source.
well, at least its now only one tree (with several branches) instead of this
splitt between cluster edition and carrier grade edition..
Cheers,
Henning
8:42 p.m.
New subject: [OpenSER-Users] openser + mysql clusters
-----Original Message-----
From: users-bounces(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of
Stanislaw Pitucha
Sent: Thursday, July 17, 2008 5:40 AM
To: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] openser + mysql clusters
----- "Sajith T S" <sajith(a)gmail.com> wrote:
I actually use Linux-HA + LVS + ldirectord, though your suggestion is a less complicated
alternative that should work fine.
How is the overall experience like re. deploying
openser with mysql
clusters?
Good enough. Just setup A record pointing at 2 or more api
nodes and set them up with virtual ips (heartbeat works quite
well...). Openser will recover if one of the nodes fail.
Are there
gotchas etc that need to be taken care of? (For
example, a 2006 article [1] says that "The MySQL NDB engine
currently
runs its database completely in memory. This
means that you have to
be
able to fit your database in memory." But this is not documented as
a
limitation in mysql faq.)
It's a feature and it's in the first sentence of cluster
overview: "... enables clustering of in-memory databases" ;)
Gotchas:
- don't bother with 5.0 - it's got strange issues
- 5.1.23 was the last version of 5.1.X with ndb. Now you have
to compile carrier grade edition from source. 
18 Jul
18 Jul
3:57 a.m.
New subject: [OpenSER-Users] openser + mysql clusters
I also use HA and DRBD. As long as there are not too many write
operations, the performance is just fine (reads are always local to the
current machine, writes have to be committed first on the target machine).
Best regards
Peter
Watkins, Bradley schrieb:
You are correct that 5.1.23 is that last version that came with NDB built-in, but you do
not have to compile from source.
You can download the latest open-source version of NDB Cluster here:
http://dev.mysql.com/downloads/cluster/index.html
One of the new features in 5.1.X/NDB 6.2.x (might've been part of NDB 6.1.x too, I
forget) is the ability for VARCHAR columns to only use the memory required to store the
value rather than a fixed amount. Depending on your data, this can save a lot of memory.
Of course, as already mentioned, there is also the possibility to use on-disk tables now
though all indexes are stored in-memory. I will say from my experience that you should
spend some time ensuring that your queries use as few non-index columns in the WHERE
clause as possible if you go this route. This probably isn't a problem for the
standard OpenSER/CDRTool queries I expect, but just a caveat.
FWIW, I use MySQL Cluster with OpenSER as well as several other open-source applications
and can say I'm pretty happy with it.
Regards,
- Brad
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
-----Original Message-----
From: users-bounces(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of
Stanislaw Pitucha
Sent: Thursday, July 17, 2008 5:40 AM
To: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] openser + mysql clusters
----- "Sajith T S" <sajith(a)gmail.com> wrote:
I actually use Linux-HA + LVS + ldirectord, though your suggestion is a less complicated
alternative that should work fine.
How is the overall experience like re. deploying
openser with mysql
clusters?
Good enough. Just setup A record pointing at 2 or more api
nodes and set them up with virtual ips (heartbeat works quite
well...). Openser will recover if one of the nodes fail.
Are there
gotchas etc that need to be taken care of? (For
example, a 2006 article [1] says that "The MySQL NDB engine
currently
runs its database completely in memory. This
means that you have to
be
able to fit your database in memory." But this is not documented as
a
limitation in mysql faq.)
It's a feature and it's in the first sentence of cluster
overview: "... enables clustering of in-memory databases" ;)
Gotchas:
- don't bother with 5.0 - it's got strange issues
- 5.1.23 was the last version of 5.1.X with ndb. Now you have
to compile carrier grade edition from source.
22 Jul
22 Jul
9:28 p.m.
New subject: [OpenSER-Users] openser + mysql clusters
"Watkins, Bradley" <Bradley.Watkins(a)compuware.com> wrote:
One of the new features in 5.1.X/NDB 6.2.x
(might've been part of
NDB 6.1.x too, I forget) is the ability for VARCHAR columns to only
use the memory required to store the value rather than a fixed
amount. Depending on your data, this can save a lot of memory.
That sounds really good. I suspect that memory usage can be a pain if
we are to deal with large amount of accounting data etc, but I would
like to hear from experienced folks here.
There's an ndb_size.pl script that reports memory requirements for
databases you might want to import from a "non-clustered" mysql
instance. It reports 5.1.x as better in terms of memory usage.
However to get started, I had to use debian's stock mysql-server-5.0
package. (I will move to 5.1.x or mysql cluster 6.2.x later.
Installing 5.1.x, both from sources and from binary packages, was
fraught with various troubles, so that has to wait.)
FWIW, I use MySQL Cluster with OpenSER as well as
several other
open-source applications and can say I'm pretty happy with it.
I seem to have most of this working now, except for one thing: on
trying to import a radius database into ndbcluster, there's this
error:
# mysql -u root -p radius < radius.sql
Enter password:
ERROR 1089 (HY000) at line 41: Incorrect sub part key; the used
key part isn't a string, the used length is longer than the key
part, or the storage engine doesn't support unique sub keys
radius.sql is basically the standard schema for freeradius with mysql
backend. Apparently this column in radacct table is the problem:
UNIQUE KEY `sess_id` (`AcctSessionId`(128),`SipFromTag`,`SipToTag`),
Has anyone already solved this?
Thanks,
Sajith.
--
"the lyf so short, the craft so long to lerne."
-- Chaucer.
9:32 p.m.
New subject: [OpenSER-Users] openser + mysql clusters
Sajith T S writes:
radius.sql is basically the standard schema for
freeradius with mysql
backend. Apparently this column in radacct table is the problem:
UNIQUE KEY `sess_id`
(`AcctSessionId`(128),`SipFromTag`,`SipToTag`),
try leaving out (128) from the key.
-- juha
22 Jul
22 Jul
9 p.m.
New subject: [OpenSER-Users] openser + mysql clusters
Stanisław Pitucha <stanis(a)gradwell.net> wrote:
It's a feature and it's in the first sentence
of cluster overview:
"... enables clustering of in-memory databases" ;)
Gotchas:
- don't bother with 5.0 - it's got strange issues
- 5.1.23 was the last version of 5.1.X with ndb. Now you have to
compile carrier grade edition from source.
[..]
Thank you so much for these advises, they are so valuable. Another
"gotcha" (well, not really a gotcha...) is that you need to re-create
a schema on all other nodes in order to make it "visible" across the
cluster.
This is mentioned in mysql official documentation, but not in the
quickstart kind of guides I went through. Spent quite a bit of time
on this, pulling my hair... until I chanced upon the official
documentation and felt all embarassed.
Thanks,
Sajith.
--
"the lyf so short, the craft so long to lerne."
-- Chaucer.
9:53 p.m.
New subject: [OpenSER-Users] openser + mysql clusters
-----Original Message-----
From: users-bounces(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of Sajith T S
Sent: Tuesday, July 22, 2008 7:01 AM
To: Stanisław Pitucha
Cc: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] openser + mysql clusters
Thank you so much for these advises, they are so valuable. Another
"gotcha" (well, not really a gotcha...) is that you need to re-create
a schema on all other nodes in order to make it "visible" across the
cluster.
This is mentioned in mysql official documentation, but not in the
quickstart kind of guides I went through. Spent quite a bit of time
on this, pulling my hair... until I chanced upon the official
documentation and felt all embarassed.
I'm not sure about MySQL Cluster 5.0, but early versions of 5.1.x only required
creating the database ("create database ...") and not the entire schema.
However, a pleasant surprise to me when I recently upgraded to 5.1.23 NDB 6.2.15 was that
even the database creation was unnecessary. So it appears this frustration has been
resolved. I agree though that it was annoying, and that was with just having to create
the DB.
There is still the frustration that views and triggers have to be created invidually on
the MySQL nodes.
Regards,
- Brad
6035
days inactive
6042
days old
8 comments
6 participants
participants (6)
-
Henning Westerholt -
jh＠tutpro.com -
Peter P GMX -
Sajith T S -
Stanisław Pitucha -
Watkins, Bradley