Fwd: Gmane is unable to post your message

[Howard-11]

 

Hi, All:

Recently I was thinking about load sharing HA solution using BDB replication.
Since BDB Env is one master and multiple slaves within a replication group
(Db_ENV), it is obvious that multiple DB_ENVs need to be set up for load
sharing? right?

2. Consider that we have two node A and Node B, with Application App1 run on
both nodes for load sharing.

Have anybody investigated the approach based on BDB replication?
What is the frame work about this?

What about dynamic load distribution based on traffic rather than
static load distribution. Does the application has to maintain some
kinds of routing table? it seem to me.

1. Session # --> DB_ENV ??

Consdier there are multiple messages to process/follow within each client
session.

Session 1 - Node A (DB_ENVA - master)
Session 2 - Node B (DB_ENVB - master)
...

Session 1 - message 2 , (DB_ENVA)
Session 1 - message 3 , (DB_ENVA)
session 2 - message 2 , (DB_ENVB)
session 1 - message 4 , (DB_ENVA)

Remeber each node can run either one master DB_ENV or both in case of failure.

Therefore a mapping of DB_ENV (master) to NODE is also required, right?

2. DB_ENV -> NODE


Besides above of my thoughts, are there any other better approaches to use
BDB replication for HA load sharing ?

Thanks a lot and happpy New Year!

---

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

[Susan LoVerso]

Hello Howard,

> Recently I was thinking about load sharing HA solution using BDB replication.
> Since BDB Env is one master and multiple slaves within a replication group
> (Db_ENV), it is obvious that multiple DB_ENVs need to be set up for load
> sharing? right?

Yes, this is correct.

> 2. Consider that we have two node A and Node B, with Application App1 run on
> both nodes for load sharing.
>
> Have anybody investigated the approach based on BDB replication?
> What is the frame work about this?

I do not know if anyone has implemented multiple environments with
multiple masters within one application.  However, as long as the
application correctly maintains what messages go where and make API
calls with the proper DB_ENV handle, it should work.

> What about dynamic load distribution based on traffic rather than
> static load distribution. Does the application has to maintain some
> kinds of routing table? it seem to me.

That would be an application level distribution and it would be up to
the application to determine where to send traffic as well as know
where it is when it wants to read it.

> Session 1 - Node A (DB_ENVA - master)
> Session 2 - Node B (DB_ENVB - master)
> ...
>
> Session 1 - message 2 , (DB_ENVA)
> Session 1 - message 3 , (DB_ENVA)
> session 2 - message 2 , (DB_ENVB)
> session 1 - message 4 , (DB_ENVA)
>
> Remeber each node can run either one master DB_ENV or both in case of failure.
> Therefore a mapping of DB_ENV (master) to NODE is also required, right?

Yes.  Also you want to make sure that each session is self-contained
in terms of transactions.  Trying to manage a GTM as well in there would
make the application extremely complex.

> 2. DB_ENV -> NODE
>
> Besides above of my thoughts, are there any other better approaches to use
> BDB replication for HA load sharing ?

That is a difficult question to answer because the approach that works
best for you is very heavily dependent on the needs of the application.
However, what you have outlined above is reasonable.

        Sue LoVerso
        Sleepycat Software

---------------------------------------------------------------------
To unsubscribe, e-mail: bdbha-unsubscribe@...
For additional commands, e-mail: bdbha-help@...

[Howard-11]

Hi, Susan:

 

Thanks for your comments. Please find my comments below.

 

2.

 

a). One alternative I believe is with one db_env on two nodes (one master/slave)

but updation can be forwarded to master node and be replicated back to the

slave side, however I feel this cause extra (unnecessary forward and replication

 traffic) and delay, I do feel it is not a good solution due to this. the advantage

is we do not need to manage multiple master db_envs.

 

Is this the proposed load sharing schema for BDB?

 

b) when one node failed, so two master db_env run on a single node, these two

db_env actually has the different data sets, but similar application data,

is there a better approach to merge them into one db_env via BDB? I feel there is no

good way without deletion and insertion.

I feel typical HA load sharing could be application oriented, but management of the

multiple db_envs and distribution among them approriately with balancing is very complex, and not easy to scalable?

 

c> any typical load sharing use case based BDB?

 

d> I asked before, if the DB store in memory (not disk file), since there is no name, so there is only one DB, is this still the case in current release? is the limitation per db_env or per application?

 

Best Regards,

 

Howard

Susan LoVerso <sue@...> wrote:

> 2. Consider that we have two node A and Node B, with Application App1 run on
> both nodes for load sharing.
>
> Have anybody investigated the approach based on BDB replication?
> What is the frame work about this?

I do not know if anyone has implemented multiple environments with
multiple masters within one application. However, as long as the
application correctly maintains what messages go where and make API
calls with the proper DB_ENV handle, it should work.

> What about dynamic load distribution based on traffic rather than
> static load distribution. Does the application has to maintain some
> kinds of routing table? it seem to me.

That would be an application level distribution and it would be up to
the application to determine where to send traffic as well as know
where it is when it wants to read it.

> Session 1 - Node A (DB_ENVA - master)
> Session 2 - Node B (DB_ENVB - master)
> ...
>
> Session 1 - message 2 , (DB_ENVA)
> Session 1 - message 3 , (DB_ENVA)
> session 2 - message 2 , (DB_ENVB)
> session 1 - message 4 , (DB_ENVA)
>
> Remeber each node can run either one master DB_ENV or both in case of failure.
> Therefore a mapping of DB_ENV (master) to NODE is also required, right?

Yes. Also you want to make sure that each session is self-contained
in terms of transactions. Trying to manage a GTM as well in there would
make the application extremely complex.

> 2. DB_ENV -> NODE
>
> Besides above of my thoughts, are there any other better approaches to use
> BDB replication for HA load sharing ?

That is a difficult question to answer because the approach that works
best for you is very heavily dependent on the needs of the application.
However, what you have outlined above is reasonable.

Sue LoVerso
Sleepycat Software

---------------------------------------------------------------------
To unsubscribe, e-mail: bdbha-unsubscribe@...
For additional commands, e-mail: bdbha-help@...

---

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

[Susan LoVerso]

> a). One alternative I believe is with one db_env on two nodes
> (one master/slave)
> but updation can be forwarded to master node and be replicated back to the
> slave side, however I feel this cause extra
> (unnecessary forward and replication traffic) and delay, I do feel it
> is not a good solution due to this. the advantage
>   is we do not need to manage multiple master db_envs.
>    
>   Is this the proposed load sharing schema for BDB?

Since BDB does not directly support load sharing or non-master updates,
we do not recommend one method over another in the application.  All
of that decision is very dependent on the application comm structure,
the data management in the application, etc.
   
> b) when one node failed, so two master db_env run on a single node, these two
>   db_env actually has the different data sets, but similar application data,
>   is there a better approach to merge them into one db_env via BDB?
> I feel there is no
>   good way without deletion and insertion.

You are correct, there is no good way other than delete/insert.

>   I feel typical HA load sharing could be application oriented,
> but management of the
>   multiple db_envs and distribution among them approriately with balancing is
>      very complex, and not easy to scalable?

I agree.  
   
>   c> any typical load sharing use case based BDB?

I am not aware of any load sharing non-master update implementations.

>   d> I asked before, if the DB store in memory (not disk file), since
> there is no name, so there is only one DB, is this still the case
> in current release? is the limitation per db_env or per application?

In un-named in-memory databases, the access limitation is through the
one DB handle referencing that database.  In our current 4.4 release
we now have named in-memory databases that are accessible by the
name given and can be used by multiple db handles.

        Sue LoVerso
        Sleepycat Software

---------------------------------------------------------------------
To unsubscribe, e-mail: bdbha-unsubscribe@...
For additional commands, e-mail: bdbha-help@...

[Howard-11]

Hi, Susan:

 

MySQL has a synchronous replication - mySQL cluster, that can be used to achieve

load balancing at the backend. and mySQL is based on Berkeley DB.

 

So, do you happen to know, is there a existing cluster framework for in-memory-BDB HA cluster proposal/solution? (I guess probably no, appplication developer need design

that)

 

Thanks a lot.

 

Howard.

Susan LoVerso <sue@...> wrote:

> a). One alternative I believe is with one db_env on two nodes
> (one master/slave)
> but updation can be forwarded to master node and be replicated back to the
> slave side, however I feel this cause extra
> (unnecessary forward and replication traffic) and delay, I do feel it
> is not a good solution due to this. the advantage
> is we do not need to manage multiple master db_envs.
>
> Is this the proposed load sharing schema for BDB?

Since BDB does not directly support load sharing or non-master updates,
we do not recommend one method over another in the application. All
of that decision is very dependent on the application comm structure,
the data management in the application, etc.

> b) when one node failed, so two master db_env run on a single node, these two
> db_env actually has the different data sets, but similar application data,
> is there a better approach to merge them into one db_env via BDB?
> I feel there is no
> good way without deletion and insertion.

You are correct, there is no good way other than delete/insert.

> I feel typical HA load sharing could be application oriented,
> but management of the
> multiple db_envs and distribution among them approriately with balancing is
> very complex, and not easy to scalable?

I agree.

> c> any typical load sharing use case based BDB?

I am not aware of any load sharing non-master update implementations.

> d> I asked before, if the DB store in memory (not disk file), since
> there is no name, so there is only one DB, is this still the case
> in current release? is the limitation per db_env or per application?

In un-named in-memory databases, the access limitation is through the
one DB handle referencing that database. In our current 4.4 release
we now have named in-memory databases that are accessible by the
name given and can be used by multiple db handles.

Sue LoVerso
Sleepycat Software

---------------------------------------------------------------------
To unsubscribe, e-mail: bdbha-unsubscribe@...
For additional commands, e-mail: bdbha-help@...

---

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.