1.1.1

Logs generated in /vmware/server1/sqlfserver.log
The server is still starting. 15 seconds have elapsed since the last log
message:
Region /_DDL_STMTS_META_REGION has potentially stale data. It is waiting
for another member to recover the latest data.
My persistent id:
DiskStore ID: aa77785a-0f03-4441-84f7-6eb6547d7833
Name:
Location: /10.0.1.31:/vmware/server1/./datadictionary
Members with potentially new data:
[
DiskStore ID: f417704b-fff4-4b99-81a2-75576d673547
Name:
Location: /10.0.1.31:/vmware/locator1/./datadictionary
]
Use the "sqlf list-missing-disk-stores" command to see all disk stores that
are being waited on by other members.
The data store startup messages indicate that locator1 has "potentially new data" for the data dictionary. In this
case, both locator2 and server1 were shut down before locator1 in the system, so those members are waiting on
locator1 to ensure that they have the latest version of the data dictionary.
The above messages for data stores and locators can be commonplace when individual members are shut down
one-by-one rather than by using sqlf shut-down-all, which allows all members to synchronize and shut
down gracefully. However, if the indicated disk store persistence files are available on the missing member,
simply start that member and allow the running members to recover. For example, in the above system you
would simply start locator1 and allow locator2 and server1 to synchronize their data.
To avoid this type of delayed startup and recovery:
1. Use sqlf shut-down-all to gracefully shut down all data store members after synchronizing disk stores with
the available locators.
2. Use sqlf locator on page 377 to shut down remaining locator members after the data stores have stopped.
3. If a member cannot be restarted and it is preventing other data stores from starting, use sqlf
revoke-missing-disk-store to revoke the disk stores that are preventing startup. This can cause some loss of
data if the revoked disk store actually contains recent changes to the data dictionary or to table data.
If persistence disk store files for the data dictionary are deleted, moved, or modified, further complications can
occur during startup. These problems are generally indicated by a ConflictingPersistendDataException while
starting up other members of the system. For example:
ConflictingPersistentDataException: Region /_DDL_STMTS_META_REGION remote
member curwen(23695)<v1>:4505 with
persistent data /10.0.1.31:/vmware/locator1/./datadictionary created at
timestamp 1373667883741 version 0 diskStoreId
9cf5aea67c6c4374-9d7205f72fecd47c name was not part of the same distributed
system as the local data from
/10.0.1.31:/vmware/server1/./datadictionary created at timestamp
1373649392112 version 0 diskStoreId aa77785a0f034441-84f76eb6547d7833
name - See log file for details.
If the datadictionary directory is deleted or moved, then SQLFire creates a new data dictionary upon
startup of that member. (Remember, all SQLFire locators and data stores maintain a persistent data dictionary
for the distributed system, even if you do not persist data in the tables.) However, other members in the distributed
system may expect the locator or data store to have the previous, deleted version of the datadictionary, in order
to recover more recent operations. If this occurs, the newly-created data dictionary conflicts with other members
view of the distributed system, and new members that startup throw a
ConflictingPersistendDataException.
vFabric SQLFire User's Guide718