[ejabberd] SQL Export, ejabberd 17.04

James Tait james.tait at wyrddreams.org
Fri Jun 9 20:27:49 MSK 2017

On 09/06/17 17:43, Badlop wrote:

> On 9 June 2017 at 16:14, James Tait <james.tait at wyrddreams.org> wrote:
>> Many thanks for the clarification, this seems to have mostly worked. There
>> were a couple of problems with the exported SQL:
>> In privacy_list_data, the boolean values were provided as integers, which
>> PostgreSQL complained about. Wrapping the values in single quotes resolved
>> that issue.
> I confirm that behavior. Please submit an issue to github so it's checked.


>> In rostergroups, the INSERT statements were missing trailing semicolons.
> Yes, this got fixed recently:
> https://github.com/processone/ejabberd/commit/cd18d3d8a72a05b20c0f8a9396de8e6ae8bc6dcd

And now I see https://github.com/processone/ejabberd/issues/1509
relating to it.

>> I can’t say I’m adept enough at Erlang to be confident of making the correct
>> change for the first issue, but I think I can submit a PR for the second.
>> As a general note about this process, requiring the administrator to switch
>> the storage backend to sql before performing the data export more or less
>> guarantees service downtime. What I had hoped would be possible was:
>> Perform the data export.
>> Import the data into PostgreSQL.
>> Modify the ejabberd configuration to use the PostgreSQL backend (default_db:
>> sql).
>> Restart ejabberd.
>> Be happy. :)
> I also think that this would allow a smaller downtime. On the other
> hand, that would allow the real database contents to change during the
> process, which means that the imported SQL content is not up-to-date.
> I wonder if that's the reason behind the current behavior, or the
> reason is just technical-internal.
I think it’s still possible for the database contents to change during
the process if one is using an authentication mechanism such as LDAP,
but maybe this possibility goes away - at the expense of a period of
service unavailability - when using other authentication methods,
because the user accounts are no longer in the configured database. Of
course, we can prevent connections to the server with a firewall, for
example, but that still leads to downtime. Not a problem in this
instance, as I said - but an interesting puzzle for someone else to ponder.

Many thanks,



James Tait, BSc                        |    xmpp:jayteeuk at wyrddreams.org
Programmer and Free Software advocate  |        Tel: +44 (0)870 490 2407

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20170609/07715114/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20170609/07715114/attachment-0001.sig>

More information about the ejabberd mailing list