[ejabberd] SQL Export, ejabberd 17.04

Badlop badlop at gmail.com
Fri Jun 9 19:43:08 MSK 2017


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


>
> 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.


>
> In this particular case it’s not really a problem, but in larger deployments
> I can imagine it would be. In such instances, would the recommended approach
> be to take a copy of the data and configure a “shadow” instance on which to
> perform the export?
>
> Best regards,

--
Badlop
ProcessOne


More information about the ejabberd mailing list