Upgrading Payara Server
There are two valid methods of fully upgrading to a new release of Payara Server. Either of the following two methods would work in most circumstances:
-
Backing up and restoring the existing configuration to a new installation.
-
Maintaining completely separate domain and node directories and pointing the new version to the existing directories.
Method 1: Backup and Restore
This method involves the following steps:
-
Stop the running domain
The asadmin backup-domainsubcommand will only work if the domain is not running so, if this method is chosen for a production system, there would need to be an arranged period of downtime. -
Run
asadmin backup-domainfrom the existing Payara Server installation -
Once the domain has been backed up, restore the domain to the newly downloaded Payara Server installation by running
asadmin restore-domainfrom the bin directory of the new Payara Server installation
After following these steps, you should be left with a similar directory structure to the following:
/opt/payara/161/payara41/glassfish/domains/myDomain /opt/payara/162/payara41/glassfish/domains/myDomain /opt/payara/backups/myDomain/myDomain_2016_05_27_v00001.zip
This method only backs up the domain directory and its contents.
Any instances you have in node directories will need to regenerated by using
the --sync=full option of the start-local-instance subcommand:
asadmin start-local-instance --sync=full myInstanceThis will recreate the instance from scratch. Be aware, though, that this will not recreate things stored in the instance directory which are outside of the configuration like JMS file stores. If there is any JMS persistence which does not use a database, these must be handled manually.
See Restore a Payara Domain for more detail.
Method 2: Move the domain directory and node directories
An alternative to backing up and restoring the domain, then recreating the instances, would be to create the domain and node directories in a location separate to the installation. For example, if you download Payara Server 4.1.1.154, created a domain, and then wanted to use Payara Server 4.1.1.162, you would use the following process:
/opt/payara/payara-4.1.154/payara41 bin/asadmin create-domain --domaindir /tmp myTempDomain
/opt/payara/payara-4.1.154/payara41 cd ../../payara-4.1.162/payara41
/opt/payara/payara-4.1.162/payara41 bin/asadmin start-domain --domaindir /tmp myTempDomainThis will use the 4.1.1.154 installation to create a new domain, and then run it with the 4.1.1.162 installation.
You can do the same thing with nodes too:
/opt/payara/payara-4.1.154/payara41 bin/asadmin create-node --nodedir /tmp myLocalNodeIn this way, the user configuration is always kept separate to the installation, and rollback is as simple as using the previous installation directory.
If you are using Payara Server on Linux, you could take advantage of "symbolic links"
to make life easier. When your domain directory is in a non-standard
location, it means that you need to specify its location with each
start/stop/restart command. If you were to create a symbolic link to
the domain directory inside the default domains directory, then all of your
existing scripts will carry on as normal.
You could even extend this further to create a symbolic link to whichever Payara Server installation was currently used in production, for example:
/opt/payara/live/payara41/....
This means that any rollback is as simple as stopping the server, updating a symbolic link and starting it again.
Without the use of symbolic links, things get a bit more manual (though still
quite straightforward). The asadmin start-domain subcommand has a
--domaindir option which allows you to specify the location of a domain
directory. So you could have a directory structure like this:
/opt/payara/154/payara41/.... /opt/payara/161/payara41/.... /opt/payara/162/payara41/.... /opt/payara/domains/myDomain /opt/payara/nodes/myLocalNode
Then you could start your domain with whatever version of Payara Server you wanted:
/opt/payara/154/payara41/bin/asadmin start-domain --domaindir /opt/payara/domains myDomain…or like this:
/opt/payara/162/payara41/bin/asadmin start-domain --domaindir /opt/payara/domains myDomain
The --domaindir option specifies the parent directory for your
domain and where you would store all of your domains if needed.
|
You can also start nodes in the same way:
/opt/payara/162/payara41/bin/asadmin start-local-instance --nodedir /opt/payara/nodes myLocalNodeJDK 11: Upgrade Considerations
| Applies to Payara Server 5.192 and superior releases |
The domain.xml configuration file contains instructions for handling JDK 11. Without these instructions, Payara Server will not start up on JDK 11 and/or will throw many exceptions during runtime.
If older, pre-5.192, domains are being migrated this has to be taken into account. The following jvm-options have to be added to the java-config element in domain.xml:
<jvm-options>[9|]--add-opens=java.base/jdk.internal.loader=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/java.lang=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/java.nio=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/sun.nio.ch=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.management/sun.management=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/sun.net.www.protocol.jrt=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]-Xbootclasspath/a:${com.sun.aas.installRoot}/lib/grizzly-npn-api.jar</jvm-options>The following jvm-options have to be removed:
<jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/modules/endorsed${path.separator}${com.sun.aas.installRoot}/lib/endorsed</jvm-options>
<jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext</jvm-options>