partitionedPersistence.README.html Maven / Gradle / Ivy
vFabric™ GemFire®
Partitioned Persistence
Java Caching API Programming Example
The partitionedPersistence example uses gfsh to demonstrate how to use the GemFire partitioned region feature, which spreads your data across multiple servers using GemFire persistence. This feature allows you to keep a persistent copy of data on disk. Each server uses separate files, so your data can be partitioned across the disks of multiple machines.
The Configuration Files
No configuration files are needed for this example.
The Locator/Server Processes
The processes used for this example are:
- The locator process. The locator process runs the JMX Manager and is the end-point for the gfsh client. All gfsh commands are first sent to the JMX Manager and then distributed to the appropriate servers.
- Two server processes.
Running the Examples
Follow these instructions to run the configuration examples.
When you run the examples, if you get a startup failure with a message indicating socket creation failure or that the port is already in use, make sure you are not starting a second copy of the same GemFire process, with the same port configuration. If you are not, then the port specification probably conflicts with some other non-GemFire application.
You need two terminal windows. In both of the windows, make sure the environment is set according to the instructions in examples/EnvSetup.html.
- Change directory to
SampleCode/examples/dist/partitionedPersistence
.
The example instructions assume you are starting from that directory.
- In the first window, begin a gfsh session and then start a locator. The locator will start a JMX Manager on the default port and gfsh will immediately connect to it.
$gfsh
gfsh>start locator --name=locator
- In the first window, start the two servers.
gfsh>start server --name=server1 --server-port=40404
gfsh>start server --name=server2 --server-port=40405
- In the first window, create a disk store and a region which uses the disk store.
gfsh>create disk-store --name=store --dir=store
gfsh>create region --name=region --type=PARTITION_PERSISTENT --disk-store=store
- You now have two servers hosting a partitioned region. In the first window, put several entries into the region. The entries will be spread out across both servers.
gfsh>put --region=region --key=key0 --value=value0
gfsh>put --region=region --key=key1 --value=value1
gfsh>put --region=region --key=key2 --value=value2
- In the first window, stop the first server and attempt to retrieve the values by key. Some of your entries will be unavailable because the server that was hosting them is offline.
gfsh>stop server --name=server1
gfsh>get --region=region --key=key0
gfsh>get --region=region --key=key1
gfsh>get --region=region --key=key2
- In the first window, stop the second server and attempt to restart the first. You'll notice that the first server hangs on startup because it's waiting to connect to the second.
gfsh>stop server --name=server2
gfsh>start server --name=server1 --server-port=40404
- In the second window, begin a gfsh session then connect to the already running JMX Manager and show the missing disk stores. It should show the missing disk store on the second server.
$gfsh
gfsh>connect
gfsh>show missing-disk-stores
- In the second window, start the second server. Both servers should now fully start.
gfsh>start server --name=server2 --server-port=40405
- Now let's simulate catastrophic data loss. In the first window, stop the first server and remove its data.
gfsh>stop server --name=server1
gfsh>sh rm -f server1/store/*
- In the first window, try to update the keys. You should get an error for some of the entries indicating that the data is offline.
gfsh>put --region=region --key=key0 --value=value0_2
gfsh>put --region=region --key=key1 --value=value1_2
gfsh>put --region=region --key=key2 --value=value2_2
- In order to fix this situation you need to let GemFire know that you have completely lost the data for those partitions. In the first window, show the missing disk stores again and then use the displayed ID in the revoke missing disk store command. Your ID will be different than the one displayed below.
gfsh>show missing-disk-stores
gfsh>revoke missing-disk-store --id=2eedbe31-e66b-4cae-909c-047873feda4d
- At this point you will no longer get errors when updating/inserting data. In the first window, start the first server and update the data.
gfsh>start server --name=server1 --server-port=40404
gfsh>put --region=region --key=key0 --value=value0_2
gfsh>put --region=region --key=key1 --value=value1_2
gfsh>put --region=region --key=key2 --value=value2_2
Online backups
To avoid losing data in the future, you should backup your data. The first technique to prevent data loss is to use redundant-copies
feature of partitioned regions. With redundancy-copies
equal to 1, GemFire will keep a live copy of the data in your region spread out over all of the members in the distributed system.
See Configuring High Availability for a Partition Region in the Pivotal GemFire User's Guide for more information on how to use redundancy.
You may also want to backup your region contents at particular points in time. GemFire allows you to perform live physical backups of all of the persistent regions in your distributed system. In the first window, execute the gfsh backup command. This will backup all disk stores to the locator's file-system.
gfsh>backup disk-store --dir=backup
In the second window you may exit gfsh and take a minute to explore the contents of the locator/backup directory. It should contain a sub-directory for the time the backup was taken. That should have three sub-directories, one for each member that was backed up. There will be a restore.sh or restore.bat script generated in each sub-directory that will restore the backup for that member.
Graceful shutdown
If you stop servers with persistent regions one at time GemFire needs to perform expensive work on startup to ensure consistency between copies of your data when you are using redundant-copies
. You can improve the recovery time for persistent partitioned regions with redundancy by shutting down all of the members at once. In the first window, type
gfsh>shutdown
Using shutdown guarantees that all redundant copies of your region are consistent at the time of shutdown, so recovery will happen quickly.