On 01/31/2013 09:14 AM, Bright, Daniel wrote:
When you say schema replication is tricky because it is a “single” master, I am using an
MMR environment where in effect every member is a master. Is this a setting that is
controlled elsewhere, and does this mean that any custom changes to the schema need to be
made on this single master server?
Yes. That's the best way to do it. If you make schema changes to one master, then
make sure that all of those schema changes have been replicated to all servers throughout
your topology, then you can make schema changes to another master. Schema replication is
not multi-master in the sense that you can make simultaneous changes to to the schema on
more than one master. You just have to be careful. That's why using a single master
is easier - if you always make changes on that one master, it should work.
OK thanks, that is the way I am planning on doing this. Just for clarification, the master
schema server in an MMR environment is whatever one I make changes to, it is however
prudent to make schema changes only to one server as normal replication rules do not apply
to schema and conflicts could arise if changes are made to more than one master.
Right.
Custom Schema
If the standard 99user.ldif file is used for custom schema, these changes are replicated
to all consumers.
Custom schema files must be copied to each server in order to maintain the information in
the same schema file on all servers. Custom schema files, and changes to those files, are
not replicated, even if they are made through the Directory Server Console or
ldapmodify.
If there are custom schema files, ensure that these files are copied to all servers after
making changes on the supplier. After all of the files have been copied, restart the
server.
For more information on custom schema files, see Section 3.4.7, “Creating Custom Schema
Files”<https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Director...;.
That's a little bit misleading. In order for schema changes to be replicated, they
_must_ be changed using ldapmodify (which is what the console uses). Schema changes made
over ldap are stored in 99user.ldif. However, if you manually edit 99user.ldif, schema
changes will _not_ be replicated.
That is of course unless you restart the directory services on this server, in the past
when I’ve made changes to 99user.ldif they go into effect when I restart the service, is
this not true anymore? I haven’t done this for a few years so perhaps I am remembering
incorrectly.
When you make changes to 99user.ldif by editing the file, and then restart the server (or
use the schema-reload.pl script), yes, the schema changes do go into effect immediately,
but they are not replicated.
That is something I was unaware of, thanks for the clarification.
Also, regarding replication between 32-bit and 64-bit servers, I have been using my test
environment for a few weeks, and have had people actively using it for that period of time
too. No issues so far have arisen, the period of time from the start of this update
process until the end is about a month and I’m worried that replication issues may arise
during this time period, has anyone else done a similar rolling upgrade and has it caused
issues in the past, especially using different architectures as the replicating servers?
------------------------
CONFIDENTIALITY NOTICE
This e-mail and any attachments contain information which may be confidential or
privileged and exempt from disclosure under applicable law. If you are not the intended
recipient, be aware that any disclosure, copying, distribution, or use of the contents of
this information is without authorization and is prohibited. If you have received this
email in error, please immediately notify us by returning it to the sender and delete this
copy from your computer system. Thank you.
------------------------