[erlang-questions] upgrading erlang servers

Param Jyothi Reddy paramr@REDACTED
Fri Feb 11 23:20:02 CET 2011


Thanks for the info on compatibility.

"Other problems are incompatible changes of funs from another node that
are stored.
Mnesia database schemas/format can also be a problem, but there is
support for converting tables."

Would it be fair to say funs and DB schema/format will also be
compatible for 2 versions? Are they auto converted on version updgrade
or does one usually run a batch process to upgrade the db?

Also curious if these data are versioned i.e. there is version number
associated with the blob which tells if it makes sense to read it with
current readers or not? Are conversions supported for 2 versions or
arbitrary versions?

Pointers to docs will help me not ask too many questions on the list :)

Param

On Fri, Feb 11, 2011 at 1:47 PM, Kenneth Lundin
<kenneth.lundin@REDACTED> wrote:
> In practice it works to do an upgrade node by node in a cluster of Erlang nodes.
> We always keep the runtime system including the distribution protocol compatible
> 2 major releases back.
> Of course you can create troubles by changing some protocol of your own that you
> use between nodes.
> You have to handle both old and new behaviour in that case.
> Other problems are incompatible changes of funs from another node that
> are stored.
> Mnesia database schemas/format can also be a problem, but there is
> support for converting tables.
>
> All in all it is in practice possible to do a rolling upgrade of the
> Erlang modules
> and/or  the Erlang VM if you plan the changes beforehand.
>
> /Kenneth , Erlang/OTP Ericsson
>
> On Fri, Feb 11, 2011 at 3:35 PM, David Mercer <dmercer@REDACTED> wrote:
>> On Wednesday, February 09, 2011, Param Jyothi Reddy wrote:
>>
>>> I am new to erlang and was reading "Programming Erlang" by Joe
>>> Armstrong and one remark in the book surprised me.
>>>
>>> Pg 173: "And same version of erlang [on all nodes]. If you dont do
>>> this, you'll get serious and mysterious errors.". Not sure how true
>>> this is currently, however if it is, how do you upgrade cluster of
>>> nodes running X version of erlang to Y without disrupting service? I
>>> would have assumed that one can upgrade subset at a time which would
>>> also provide a vehicle to test version Y on small subset before
>>> committing the full cluster. But if this comment is true then one
>>> would have to upgrade cluster of nodes in an all or nothing fashion.
>>>
>>> There are other ways to upgrade by having two clusters and switching
>>> load between them using some protocol. Is that how it is meant to be
>>> used? Am i missing something obvious?
>>
>> This is a good question, which relates not only to upgrades of the Erlang
>> runtime system, but also of any code that changes its data structures: How
>> do you upgrade a distributed system when the interface changes?  I asked a
>> similar question in October of '07
>> (http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:30311:200710:fanenpeabclnldcl
>> aikd), but your question is even more intractable than mine, since yours
>> cannot be solved by code tricks.  If you need simultaneous upgrade of all
>> 3,000 nodes, especially when confounded by some of the geopolitical
>> considerations described in
>> <http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:30338:fanenpeabclnldclaikd>,
>> then I'm not sure there is a practical solution, which is why ten years from
>> now "Pan-Global Worldwide Consolidated" will still be running Erlang R3A1.
>>
>> Cheers,
>>
>> DBM
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>


More information about the erlang-questions mailing list