On Sat, Mar 26, 2016 at 6:44 AM, David G <lsmb...@sbts.com.au> wrote:

> Hi Michael,
>
> At the moment I don't believe we support having multiple LedgerSMB
> servers accessing the same company database, which is roughly what you
> are referring to.
>

Multiple ledgersmb servers can access the same company database with no
problem.  There isn't really a difference between multiple service
processes and multiple servers from the database perspective.  It *is*
possible to configure LedgerSMB to allow different versions of LedgerSMB to
access the same database, but this isn't recommended for any extended
period (it is designed for 0-downtime upgrades where worker processes might
be recycled after the db upgrade is complete).


> Having said that, I also don't think it would take too much in the way
> of changes to make that possible (most state and consistency is in the
> database already)
>
> But Be Warned, it may not be possible before the last of the legacy code
> has been rewritten.
> Also there would need to be a fair investment in testing before you
> would say it's production ready.
>

I think the only think one would note would be that some of our caching
improvements are server-local.  I think there are actually some 1.3 users
who use multiple web servers against the same db server.

>
> Chris and Erik may well contradict me on this, as they should if I'm
> incorrect.
>
> It's certainly a direction I'd like to be able to move towards,
> especially if a robust and reliable bidirectional postgres replication
> solution could be used (which it can't at the moment. a) it doesn't
> exist. b) there are challenges that would need solving within our code
> to do with data integrity eg: assignment of unique consecutive invoice
> numbers across multiple DB backends)
>

I think it is impossible to guarantee unique consecutive invoice numbers
across multiple db backends if you want to handle databases being off-line
(this is a CAP problem).  One possibility would be for each location to
have its own series of unique consecutive invoice numbers......

As for bidirectional postgresql replication solutions, there are several
including Bucardo and Postgres-bdr which provide different solutions to
these problems, but they are not perfect and setting up something like this
is rather advanced territory right now (at present we are not even sure
what local requirements regarding things like invoice numbers are for such
a solution).

>
> Regardless of that use case, it solves some current issues running under
> apache directly, and provides performance gains due to the way Starman
> handles perl processes, and nginx as a reverse proxy caches static content
>
> Oh, just a note, We are not proposing to prevent LedgerSMB from being
> directly served by Apache etc. just making the primary method (ie: the
> way it gets installed) be to run via Starman and a reverse proxy
>

Ok that is worth noting, and we *do* need better tooling in this corner.

>
> Regards
> David G
>
> On 26/03/16 02:56, Michael Richardson wrote:
> >     > 1 Only ever run LedgerSMB using Starman (High-performance
> >     > preforking PSGI/Plack web server)
> >     > 2 Only ever bind Starman to localhost
> >
> > I'll all for this.
> >
> > (In bigger installations, one binds starman to a backend network, and
> uses
> > nginx or apache or maybe varnish to spread load.  Is there any local
> state in
> > LedgerSMB that would prevent this...?)
> >
> > --
> > ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> > ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> > ]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
> >
> >
> >
> ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> > _______________________________________________
> > Ledger-smb-devel mailing list
> > Ledger-smb-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Ledger-smb-devel mailing list
> Ledger-smb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>



-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Reply via email to