PK Information | Software & Business Consulting

View Original

FileMaker Server SOS

Here at PK Information, we try to be prepared for anything. Power failures, corrupted databases, server shutdowns — we've seen it all. We've been working with FileMaker Servers for years, and we've developed some solid tactics for use whenever a server is struggling.

Note: these methods are specifically for use with Windows Servers.

Power Outages

In the event of something like a power outage (particularly for servers that are local), the main method of preparation is to have the server use a battery backup. This will allow the server to be brought down slowly and properly, rather than just cutting off power—which can potentially result in a damaged or corrupted database.

If you have a local server, ask yourself if any of these should be considered for your redundancy plans:

  • Tornadoes

  • Earthquakes

  • Hurricanes

  • Ice

  • Fire

  • Tsunamis

  • Volcanic eruption

  • Cars hitting transformers

  • Cleaning personnel unplugging cables to vacuum the room

  • Coffee spills

  • Cats


...okay, you probably said yes to at least one of those, if not multiple. Consider this your official warning that every local server should have a backup battery, generator, or similar device to at a minimum ensure a safe shutdown.

See this content in the original post

Server-Side Problems

For hiccups or issues within the server itself, such as hanging connections from the Data API or Script Engine, we can do a bit more to help shut the server down gracefully. While there’s no official method for bringing a struggling server down, we’ve found a few tricks that help us protect our client’s databases as much as possible.

It's helpful to think about FileMaker Server as a series of processes layered on top of each other, like a stack of pancakes. For example, in order for the Web Publishing Engine to work, it needs to have the Script Engine turned on; In order for the Data API to work, it needs to have the Web Publishing Engine on; and so on.

The layers we like to think of are these:

  1. FM Data API

  2. Web Publishing Engine

  3. FM Script Engine

  4. Databases

  5. FM Server

We turn off these processes from top to bottom—starting with Data API and working down to the FM Server process itself. We also like to give a few seconds in between each, to ensure that each process has been completely stopped before moving to the next.

Generally, we’ve found that the best method for turning these off is to use the Command Line Interface (CLI). Often when a server is struggling, the AdminServer (the process that gives us the Console) can potentially have some issues, sometimes displaying incorrect data or long-removed connections. By using the CLI, we cut out that extra work the server needs to do to display that information to us, and it will often save time in the shutdown process.

Once the individual processes are turned off, then we work on getting the databases closed. Again, working through the CLI is likely to be the cleanest method for shutting down the databases, so they will be less likely to fail their consistency check after restarting the machine. When doing this, we will generally add “--force” or “-f” to ensure that there isn’t any waiting time for the database to close. This will prevent new users from trying to log in, and also speed up the closing process significantly.

Finally, we shut down the server through the command line as well.

See this content in the original post

If there aren’t any issues with this process (such as a database being stuck in the Closing status for longer than it should), then your database likely won't even need to go through a lengthy consistency check when the server comes back up. We've been able to save databases from corruption utilizing these methods.

If for any reason, the CLI doesn't close the databases or server in a timely manner, we HIGHLY recommend that you do NOT perform a hard restart of the computer. Instead, if you're using a Windows Server, go to Windows Services to stop the FileMaker Server service from there. This will shut the server down as cleanly as it can — this is, though, a last resort. We don't advise using the Windows Services shutdown process for everyday restarts.

Regular Maintenance

We do also recommend regular (bi-weekly or monthly) restarts of any FileMaker Servers in order to maintain the health of the server. Just like with a car, it’s better and easier and more affordable to preventatively address maintenance rather than reactively wait until a problem arrives. One or twice a year, it’s also wise to review the size of your database and server, then consider if an upgrade would be helpful.

See this content in the original post

But if you ever find yourself with a struggling server, hopefully, these tips will help you be able to avoid database corruption. However, if you do suffer corruption and have to rebuild your database, at least you’ll have up-to-date and usable backups available to pull from… right? You do have those, we presume?

See this content in the original post

PK Information is a FileMaker-certified development agency serving the Tampa Bay, Miami Lakes, and Knoxville regions. We believe software should work the way you do, with business priorities first and technology second.


LEARN MORE

Would you like to learn more about hosting options for your FileMaker database? We’d love to discuss the possibilities with you!