1. Overview of GlassFish Server Administration
Default Settings and Locations
Instructions for Administering GlassFish Server
Domains for Administering GlassFish Server
Domain Administration Server (DAS)
Creating, Logging In To, and Deleting a Domain
To Create a Domain From a Custom Template
Starting and Stopping a Domain
Configuring a DAS or a GlassFish Server Instance for Automatic Restart
To Configure a DAS or an Instance for Automatic Restart on Windows
To Configure a DAS or an Instance for Automatic Restart on Linux
To Configure a DAS or an Instance for Automatic Restart on Oracle Solaris
To Prevent Service Shutdown When a User Logs Out on Windows
Suspending and Resuming a Domain
Setting Up Automatic Backups of a Domain
To Create a Backup Configuration
To Enable a Backup Configuration
To Disable a Backup Configuration
To Delete a Backup Configuration
Backing Up and Restoring a Domain
To Switch a Domain to Another Supported Java Version
To Change the Administration Port of a Domain
4. Administering the Virtual Machine for the Java Platform
6. Administering Web Applications
7. Administering the Logging Service
8. Administering the Monitoring Service
9. Writing and Running JavaScript Clients to Monitor GlassFish Server
10. Administering Life Cycle Modules
11. Extending and Updating GlassFish Server
Part II Resources and Services Administration
12. Administering Database Connectivity
13. Administering EIS Connectivity
14. Administering Internet Connectivity
15. Administering the Object Request Broker (ORB)
16. Administering the JavaMail Service
17. Administering the Java Message Service (JMS)
18. Administering the Java Naming and Directory Interface (JNDI) Service
19. Administering Transactions
For mirroring purposes, and to provide a working copy of the DAS, you must have:
One host (olddashost) that contains the original DAS.
A second host (apphost) that contains a cluster with server instances running applications and catering to clients. The cluster is configured using the DAS on the first host.
A third host (newdashost) where the DAS needs to be re-created in a situation where the first host crashes or is being taken out of service.
Note - You must maintain a backup of the DAS from the first host using the backup-domain(1) subcommand as described in To Back Up a Domain. You can automatically maintain a backup of the DAS using the automatic backups feature of Oracle GlassFish Server.
The following steps are required to migrate the DAS from the first host (olddashost) to the third host (newdashost).
This is required so that the DAS can be properly restored on newdashost without causing path conflicts.
For example:
asadmin> restore-domain --backupdir /net/backups.example.com/glassfish
This example assumes that backups are stored in a network-accessible location. If this is not the case, manually copy the latest backup file from offline storage to a directory on newdashost.
If you have both configuration-only and full backups, restore the latest full backup first. Then, restore the latest configuration-only backup if it is newer than the latest full backup. Use the --backupconfig option of the restore-domain subcommand to specify the appropriate full and configuration-only backups.
You can backup any domain. However, while re-creating the domain, the domain name should be same as the original.
For example:
asadmin> start-domain domain1
See Chapter 2, Setting Up SSH for Centralized Administration, in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide for instructions.
asadmin> list-instances --long
If the domain uses centralized administration, use the update-admin-server-coordinates subcommand on newdashost:
asadmin> update-admin-server-coordinates
If the domain does not use centralized administration, use the update-admin-server-local-coordinates subcommand on apphost:
asadmin> update-admin-server-local-coordinates --adminhost host3 --adminport port-number node-name
Restarting the clustered and standalone instances on apphost triggers their recognition of the new DAS on newdashost.
If the domain does not use centralized administration, use the start-local-instance subcommand to start the cluster instances on apphost.
asadmin> list-instances --long