All Downloads are FREE. Search and download functionalities are using the official Maven repository.

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.

  1. Change directory to SampleCode/examples/dist/partitionedPersistence. The example instructions assume you are starting from that directory.

  2. 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.
  3. $gfsh
    gfsh>start locator --name=locator
  4. In the first window, start the two servers.
    gfsh>start server --name=server1 --server-port=40404
    gfsh>start server --name=server2 --server-port=40405
  5. In the first window, create a disk store and a region which uses the disk store.
  6. gfsh>create disk-store --name=store --dir=store
    gfsh>create region --name=region --type=PARTITION_PERSISTENT --disk-store=store
  7. 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.
  8. gfsh>put --region=region --key=key0 --value=value0
    gfsh>put --region=region --key=key1 --value=value1
    gfsh>put --region=region --key=key2 --value=value2
  9. 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.
  10. gfsh>stop server --name=server1
    gfsh>get --region=region --key=key0
    gfsh>get --region=region --key=key1
    gfsh>get --region=region --key=key2
  11. 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.
  12. gfsh>stop server --name=server2
    gfsh>start server --name=server1 --server-port=40404
  13. 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.
  14. $gfsh
    gfsh>connect
    gfsh>show missing-disk-stores
  15. In the second window, start the second server. Both servers should now fully start.
  16. gfsh>start server --name=server2 --server-port=40405
  17. Now let's simulate catastrophic data loss. In the first window, stop the first server and remove its data.
  18. gfsh>stop server --name=server1
    gfsh>sh rm -f server1/store/*
  19. 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.
  20. 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
  21. 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.
  22. gfsh>show missing-disk-stores
    gfsh>revoke missing-disk-store --id=2eedbe31-e66b-4cae-909c-047873feda4d
  23. 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.
  24. 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.




© 2015 - 2024 Weber Informatics LLC | Privacy Policy