This chapter describes the Directory Server Enterprise Edition features that provide high data availability and integrity. This chapter covers the following topics:
Directory Server provides a robust replication mechanism, including the following features:
Unlimited masters for replication
Globally synchronized replication using the retro changelog
Replicated account lockout attributes
Monitoring replication convergence
In a multimaster replication environment, data is updated on multiple masters. Each master maintains a change log, and the changes made on each master are replicated to the other servers. Each master plays the role of supplier and consumer. Directory Server has no limits on the number of masters, allowing your multimaster replication topology to include an unlimited number of masters in multiple data centers.
You can also configure your replication topology to contain only masters, eliminating the need to route operations to consumers and simplifying your overall deployment.
Directory Server allows you to prioritize updates for replication. Priority is a boolean feature and is on or off. You can prioritize replication according to the following parameters:
For example, a password attribute can be configured to replicate immediately.
For example, you can set up add operations to have a higher priority than modification operations.
For example, you can specify that modifications made by administrative users have a higher priority than modifications made by regular users.
Entry or subtree
For example, you can specify that a particular group has a higher priority than other groups.
The priority rules are configured on each master replica. The master can replicate an update to one or more hubs or consumer replicas. The priority of the update is then cascaded across all of the hubs and consumer replicas. If one parameter is configured for prioritized replication, all updates that have that parameter are prioritized for replication. If multiple parameters are configured for prioritized replication, only updates that match all parameters are prioritized for replication.
See Replication Priority in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide for instructions on configuring prioritized replication using command-line tools.
The retro changelog receives updates from all master replicas in the topology. The updates from each master replica are combined in the retro changelog. The retro changelog provides a way for applications to track changes so that they can be synchronized. Directory Server enables you to access a coherent version of the retro changelog on any master in a multimaster topology. You can also update your application to manage its state according to change numbers. This makes it possible to fail over between retro changelogs on different servers.
The global retro changelog contains all of the changes. If two changes occur on the same entry in two different locations, the retro changelog provides an ordered change description. If you query the retro changelog from any server, it will contain similar information.
See Replication and the Retro Change Log Plug-In in Sun Java System Directory Server Enterprise Edition 6.2 Reference for background information about the retro changelog.
Directory Server replicates account lockout data that is stored when a client application fails to authenticate to the server. You can use this feature with the Directory Proxy Server capability to route binds appropriately. Together, these features provide global account lockout. Global account lockout prevents a client application from gaining more than a specified number of login attempts across an entire directory service topology.
Directory Server quickly calculates the number of pending replication changes. Directory Server finds the oldest change that the consumer is aware of and can compare it with the other servers, making it possible to calculate the replication delay. From this change, the consumer can also browse the list of changes until the most recent change, and count the number of changes that need to be applied.
Moreover, this attribute can be queried with virtually no impact to Directory Server performance, regardless of how large the change log grows.
In the Directory Service Control Center, you can view a summary of all the pending changes for a given suffix. In the Suffixes tab, the pending changes are in the Missing Changes column, as shown in the following figure.
Directory Server provides a mechanism for adding new entries to an existing database. This import process checks if a given entry already exists so that data is not overwritten. This feature allows you to import an LDIF file in multiple passes at different times. Successive imports do not delete what already exists in the database.
For more information about importing entries to large replicated suffixes, see Incrementally Adding Many Entries to Large Replicated Suffixes in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
All offline and online backup methods can be invoked in the CLI by using dsadm or dsconf. The default behavior for these commands is to operate in synchronous mode. The commands do not return a completion code until the task is complete.
You can use the dsconf import, dsconf export, dsconf backup, and dsconf restorecommands in an asynchronous mode by setting the -a flag.
You can perform an online binary backup with dsconf or by using the Directory Service Control Center (DSCC).
For example, to back up master sA1 and store the resulting binary backup in the /install-path/sA1-bak directory, run the following command:
$ dsconf backup -p 20390 install-path/sA1-bak
Use the -a or --async option to start a backup task that returns immediately.
You can perform an online LDIF export using the command line or using the DSCC. For example, use the following command to export to a file called export.ldif:
$ dsconf export -p 20390 "dc=example,dc=com" install-path/export.ldif Beginning export of 'example' example: Processed 8 entries (100%). Export finished. Task completed (slapd exit code: 0).
You can perform an offline binary backup with the dsadm backup command. The instance must be stopped before running this command.
The following command performs an offline binary backup:
$ dsadm backup install-path/sA1 install-path/sA1-bak [28/Oct/2006:23:38:13 -0500] - Backup starting (install-path/sA1-bak) [28/Oct/2006:23:38:13 -0500] - WARNING<20509> - Backend Database - conn=-1 op=-1 msgId=-1 - Cannot create new directory install-path/sA1-bak/dsA1 (-5943) Cannot create or rename a filename that already exists. [28/Oct/2006:23:38:13 -0500] - Backing up file 1 (install-path/sA1-bak/dsA1/dsA1_objectclass.db3) [28/Oct/2006:23:38:13 -0500] - Backing up file 2 (install-path/sA1-bak/dsA1/dsA1_id2entry.db3) [28/Oct/2005:23:38:13 -0500] - Backup completed (install-path/sA1-bak)
You can perform an offline LDIF export using the dsadm export command as follows:
$ dsadm export install-path/sA1 "dc=example,dc=com" install-path/export.ldif Exporting data... [28/Oct/2005:23:37:46 -0500] - DEBUG - conn=-1 op=-1 msgId=-1 - Backend Instance: dsA1 ldiffile: install-path/export.ldif [28/Oct/2005:23:37:46 -0500] - export dsA1: Processed 8 entries (100%).
The dsadm and dsconf commands can also be used to restore data. The commands are used the same way as for backups except that the commands used are dsadm restore and dsconf restore. The instance must be stopped before running this command.
Directory Server now allows you to compact the database files to reduce disk use and reduce backup time. You can compact an existing suffix using the dsadm repack command. The instance must be stopped before running this command.
For more information about compacting your database files using the dsadm command, see the dsadm(1M) man page.
Directory Server provides a configurable feature that enables you to stop database updates on disk so that a file system snapshot can be taken safely.
When frozen mode is set, all configured databases are taken offline. Any internal operations in progress are notified of the database going offline. LDAP operations in progress are completed, and the database environment is flushed. Subsequent incoming operations are refused until the server property is reset to read-write or read-only. In a single server topology, operations received when frozen mode is on result in an LDAP error being returned.
The standard error message for database offline is logged. In a replicated topology, a referral is returned. For this feature to work correctly, no other tasks should be running on the databases. Set the frozen mode using the dsconf set-server-prop command as follows:
dsconf set-server-prop read-write-mode:frozen
Once this property is set, you can safely take the file system snapshot.
See Backing Up a File System in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide for instructions on configuring frozen mode using command-line tools.
In previous versions of Directory Server, attributes such as the all IDs threshold required the server to be offline when the attribute value was changed. You can now change the values of such attributes while the instance is online.
Although the value can be changed online, changes for some attributes might not take effect until after the instance has been restarted. In addition, some changes require manual intervention before restarting. For example, you can change the path to the data directory with the server online, but before the change takes effect, you need to do the following:
Stop the instance.
Ensure that the new directory exists and has the correct permissions.
Move the data from its present location to the new location.
Restart the instance.
The following sections describe the changes that can now be made with the server online.
You can change the global and index-specific values of the all IDs threshold with the server online. The change does not take effect until the affected indexes are re-indexed or the data is re-initialized.
For example, on the command line, you can change the global all IDs threshold by running the following command:
# dsconf set-server-prop -p 20390 all-ids-threshold:2000
When you change the all IDs threshold located in the server-prop property, you must restart the server. All other all IDs threshold changes are made dynamically.
You can change the database path attribute while the server is online. After you have changed the path, you then need to stop the server, move the database files, and start the server.
The database path attributes include nsslapd-db-home-directory, nsslapd-db-logdirectory, and nsslapd-directory. These attributes correspond to the dsconf command properties db-env-path, db-log-path, and db-path, respectively.
For example, to change the location of the example backend database, do the following:
# /opt/sun/install-path/bin/dsconf set-suffix-prop -p 20390 "dc=example,dc=com" \ db-path:/install-path/dbtst Changing "db-path" does not move the database file automatically. You will have to stop the server, move the database files and restart the server. Do you want to continue [y/n] ? y Directory Server needs to be restarted for changes to take effect # mv /install-path/sA1/db/example /install-path/dbtst # /opt/sun/install-path/bin/dsadm start /install-path/sA1 Server started: pid=29050
Every attribute defined in the server's schema has a syntax associated with it. The syntax defines the kind of information that is expected to be held in the attribute so that the server can perform the appropriate kinds of matching against it. The syntax definition also allows the server to properly index the values so that searches against it can be processed quickly.
Directory Server Enterprise Edition introduces a configurable option, check-syntax-enabled, set by using the dsconf command, to ensure that updated attributes adhere to the syntax definitions. Attribute values are rejected when they violate the syntax definitions. For example, when syntax checking is on, if a user tries to update an attribute with an integer syntax to include a non-numeric value, the update will be rejected.
By default, syntax checking is off. When syntax checking is on, all import and update operations are checked.
Directory Proxy Server provides schema validation to ensure that only the allowed data is permitted on write operations. For example, when entries are aggregated using the virtual directory functionality, the aggregate entries might not match the schema of any of the backend servers participating in the entry aggregation. In this case, schema checking can occur on the Directory Proxy Server using a virtual schema.
When schema checking is enabled, Directory Proxy Server retrieves schema available in the cn=schema suffix and uses it to do schema checking. You can define the LDIF data view holding the cn=schema suffix. The content of the cn=schema suffix can point to an LDAP server or to a schema stored in an LDIF file local to the Directory Proxy Server.
To read more about the features presented in this chapter, refer to the following documentation.
Designing a highly available deployment
Backing up and restoring directory data
Using a global retro changelog
Using global account lockout
Making a file system snapshot when the database is in frozen mode
Checking valid attribute syntax on update