31 Jan
2011
31 Jan
'11
7:18 p.m.
Hello list,
I have had a short attempt:
set GLOBAL read_only=true;
on the MySQL that runs my curriki and it kind of works.
A few exceptions are thrown at the beginning but otherwise it seems to render well.
The interest is that it could allow some of the web requests to be served by a database
that is a slave of the main database, in live synchronization with the master MySQL.
Has anyone tried that?
thanks in advance
paul
31 Jan
31 Jan
7:48 p.m.
On 01/31/2011 07:18 PM, Paul Libbrecht wrote:
Hello list,
I have had a short attempt:
set GLOBAL read_only=true;
on the MySQL that runs my curriki and it kind of works.
A few exceptions are thrown at the beginning but otherwise it seems to render well.
The interest is that it could allow some of the web requests to be served by a database
that is a slave of the main database, in live synchronization with the master MySQL.
You mean that the public wiki reads data from the read-only database,
which is actually updated by cloning another read-write database updated
from a private wiki? That's an interesting idea for securing a public
server.
You should also set in xwiki.cfg:
xwiki.readonly=1
This might reduce some of the errors that you get, although there's a
lot of code that ignores this setting. It would be nice if you could
report (on jira) what exactly breaks so that we can fix it properly.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
9:59 p.m.
Le 31 janv. 2011 à 19:48, Sergiu Dumitriu a écrit :
Actually, the goal is the converse: the internal, robot-oriented xwiki would read the
cloned DB.
The interest
is that it could allow some of the web requests to be served by a database that is a slave
of the main database, in live synchronization with the master MySQL.
You mean that the public wiki reads data from the read-only database,
which is actually updated by cloning another read-write database updated
from a private wiki? That's an interesting idea for securing a public
server.
could be though you need a filtering mechanism thn.
You should also set in xwiki.cfg:
xwiki.readonly=1
why *also* ?
This might reduce some of the errors that you get,
although there's a
lot of code that ignores this setting. It would be nice if you could
report (on jira) what exactly breaks so that we can fix it properly.
If you say a lot of code ignores that than I'd better not rely on it I'm afraid.
Nonetheless, the previous option sounds good.
paul
10:24 p.m.
On 01/31/2011 09:59 PM, Paul Libbrecht wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Le 31 janv. 2011 à 19:48, Sergiu Dumitriu a écrit :
Actually, the goal is the converse: the internal, robot-oriented xwiki would read the
cloned DB.
"Set" it so that some of the code inside the platform is aware that the
wiki is supposed to be read-only and act accordingly. "Also", because
that's not enough to guarantee that no changes will be made to the data,
and the database-level read-only is much safer.
The
interest is that it could allow some of the web requests to be served by a database that
is a slave of the main database, in live synchronization with the master MySQL.
You mean that the public wiki reads data from the read-only database,
which is actually updated by cloning another read-write database updated
from a private wiki? That's an interesting idea for securing a
public server.
could be though you need a filtering mechanism thn.
You should also set in xwiki.cfg:
xwiki.readonly=1
why *also* ? This might
reduce some of the errors that you get, although there's a
lot of code that ignores this setting. It would be nice if you could
report (on jira) what exactly breaks so that we can fix it properly.
If you say a lot of code ignores that than I'd better not rely on it I'm afraid.
Nonetheless, the previous option sounds good.
5030
days inactive
5030
days old
3 comments
2 participants
participants (2)
-
Paul Libbrecht -
Sergiu Dumitriu