[MonetDB-users] Funnel
We're looking at setting up the funnel. We've got 2 database servers that we're planning on using, and we simply want to balance the requests between the two. We don't want any of the multiplexing to take effect. I'm not seeing much as far as guides or how to set this up in the man pages. Does anyone have any good pointers on how to set things up this way? Thanks, Joseph Brower
Hi Joseph, On 02-04-2012 09:25:30 -0600, Joseph Brower wrote:
We're looking at setting up the funnel. We've got 2 database servers that we're planning on using, and we simply want to balance the requests between the two. We don't want any of the multiplexing to take effect. I'm not seeing much as far as guides or how to set this up in the man pages. Does anyone have any good pointers on how to set things up this way?
You don't need the funnel for this. monetdbd(1) does this automagically, as long as the database (or pattern to match the database, see TAGS) is the same/results in both systems as match. Remember, though, that this does connection-level balancing, not query-level balancing. Fabian
Yes. We're wanting connection level balancing. :-D I'm not seeing how to actually enable this or see how it's working, the documentation is rather sparse. Thanks, Joseph Brower On 04/02/2012 09:56 AM, Fabian Groffen wrote:
Hi Joseph,
On 02-04-2012 09:25:30 -0600, Joseph Brower wrote:
We're looking at setting up the funnel. We've got 2 database servers that we're planning on using, and we simply want to balance the requests between the two. We don't want any of the multiplexing to take effect. I'm not seeing much as far as guides or how to set this up in the man pages. Does anyone have any good pointers on how to set things up this way? You don't need the funnel for this. monetdbd(1) does this automagically, as long as the database (or pattern to match the database, see TAGS) is the same/results in both systems as match.
Remember, though, that this does connection-level balancing, not query-level balancing.
Fabian
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 02-04-2012 10:14:05 -0600, Joseph Brower wrote:
Yes. We're wanting connection level balancing. :-D I'm not seeing how to actually enable this or see how it's working, the documentation is rather sparse.
A default match has implicit `/*' added to the search, making more generic search strings match more specific ones. Hence, a connect with database dbX is the same as dbX/* and hence matches dbX/master/tableQ. Similar, a database connect for */master matches the same database as before. Note that the implicit `/*' is not added if that would cause no matches, such as for */master/tableQ which would return all masters for tableQ, which in our hypothetical example is only dbX. In con‐ trast, a database connect for */slave/tableQ matches with either dbY or dbZ. monetdbd returns the two options to the client in a round-robin fashion, such that subsequent connects for the same pattern result in a load-balanced connect to either of both databases. The above might be a bit scarce, I guess monetdbd's discovery and matching features are hardly used outside our group. Fabian
Fabian, I understand that, but I'm not seeing how to get one server to discover the other. Thanks, Joseph Browre On 04/02/2012 10:38 AM, Fabian Groffen wrote:
On 02-04-2012 10:14:05 -0600, Joseph Brower wrote:
Yes. We're wanting connection level balancing. :-D I'm not seeing how to actually enable this or see how it's working, the documentation is rather sparse. A default match has implicit `/*' added to the search, making more generic search strings match more specific ones. Hence, a connect with database dbX is the same as dbX/* and hence matches dbX/master/tableQ. Similar, a database connect for */master matches the same database as before. Note that the implicit `/*' is not added if that would cause no matches, such as for */master/tableQ which would return all masters for tableQ, which in our hypothetical example is only dbX. In con- trast, a database connect for */slave/tableQ matches with either dbY or dbZ. monetdbd returns the two options to the client in a round-robin fashion, such that subsequent connects for the same pattern result in a load-balanced connect to either of both databases.
The above might be a bit scarce, I guess monetdbd's discovery and matching features are hardly used outside our group.
Fabian
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 02-04-2012 10:40:43 -0600, Joseph Brower wrote:
Fabian,
I understand that, but I'm not seeing how to get one server to discover the other.
They should do so automatically by default. If `monetdb discover` doesn't list anything, your network configuration prevents it from working. The merovingian.log file might give clues in that case. Fabian
OK. We haven't set up the second one yet, I thought we had to do some sort of configuration. Knowing that, it looks like broadcast UDP is used, so as long as they are in the same subnet and can receive each other's broadcast traffic, we should be ok? We just continue to point to the first and it will automatically distribute the connections to the others? Thanks, Joseph Brower On 04/02/2012 10:44 AM, Fabian Groffen wrote:
On 02-04-2012 10:40:43 -0600, Joseph Brower wrote:
Fabian,
I understand that, but I'm not seeing how to get one server to discover the other. They should do so automatically by default. If `monetdb discover` doesn't list anything, your network configuration prevents it from working. The merovingian.log file might give clues in that case.
Fabian
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 02-04-2012 10:51:36 -0600, Joseph Brower wrote:
OK. We haven't set up the second one yet, I thought we had to do some sort of configuration. Knowing that, it looks like broadcast UDP is used, so as long as they are in the same subnet and can receive each other's broadcast traffic, we should be ok? We just continue to point to the first and it will automatically distribute the connections to the others?
Yes exactly. In addition, you can just point to the second, and the same should happen. mclient gives you the final uri it connected to, e.g.: % monetdb discover \*/demo location mapi:monetdb://budapest.ins.cwi.nl:50000/demo mapi:monetdb://sirius.ins.cwi.nl:50000/demo mapi:monetdb://vienna.ins.cwi.nl:50000/demo % mclient demo Welcome to mclient, the MonetDB/SQL interactive terminal (Apr2012-0474aa42f907+) Database: MonetDB v11.10.0 (unreleased), 'mapi:monetdb://vienna.ins.cwi.nl:50000/demo' Type \q to quit, \? for a list of available commands auto commit mode: on sql>\q % $INSTALL_DIR/bin/mclient demo Welcome to mclient, the MonetDB/SQL interactive terminal (Apr2012-0474aa42f907+) Database: MonetDB v5.21.0, 'mapi:monetdb://sirius.ins.cwi.nl:50000/demo' Type \q to quit, \? for a list of available commands auto commit mode: on sql>\q As you can see, it connects to vienna and sirius on successive connections for the same database. Fabian
participants (3)
-
Fabian Groffen -
Joseph Brower -
Joseph Brower