----- "Sajith T S" sajith@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
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
-----Original Message----- From: users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Stanislaw Pitucha Sent: Thursday, July 17, 2008 5:40 AM To: users@lists.openser.org Subject: Re: [OpenSER-Users] openser + mysql clusters
----- "Sajith T S" sajith@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.
I actually use Linux-HA + LVS + ldirectord, though your suggestion is a less complicated alternative that should work fine.
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.
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
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:
-----Original Message----- From: users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Stanislaw Pitucha Sent: Thursday, July 17, 2008 5:40 AM To: users@lists.openser.org Subject: Re: [OpenSER-Users] openser + mysql clusters
----- "Sajith T S" sajith@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.
I actually use Linux-HA + LVS + ldirectord, though your suggestion is a less complicated alternative that should work fine.
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.
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
"Watkins, Bradley" Bradley.Watkins@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.
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
Juha Heinanen jh@tutpro.com wrote:
try leaving out (128) from the key.
That worked. Thank you!
Stanisław Pitucha stanis@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.
-----Original Message----- From: users-bounces@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@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
-
Henning Westerholt -
jh＠tutpro.com -
Peter P GMX -
Sajith T S -
Stanisław Pitucha -
Watkins, Bradley