Re: Rolling upgrade of multiple servers

"Bright, Daniel" <dbright@xxxxxxxxxxxxxx> · Thu, 31 Jan 2013 16:56:34 +0000

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

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. 

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users