But, it wont be persisted across restarts in Mesos-land, because Mesos doesn't have the idea of data volumes. The way that Google (Omega) gets around this is having GFS deal with replication, and persisting all of their databases into the shared file system.

There is an interesting discussion on the mailing list http://mail-archives.apache.org/mod_mbox/mesos-user/201410.m...

In order to use docker volume you have to stick your ArangoDB docker instance to exact same mesos worker. Otherwise database instance may be started by marathon on any random chosen worker, without saved volume. IMHO, sticking database instance to exact cluster node renders whole idea of using mesos and marathon completely useless.

You could mount a network volume on all your mesos hosts and make that available to the DB container, so that no matter which host handles that job, your data will persist easily.

What would the performance characteristics of that be? What configures the network volume? Isn't configuring and maintaining a network volume comparable to configuring and maintaining a database?

Mesos is missing something to deal with persistent storage. From what I've heard all teams that employ Mesos don't actually run their persistant storage clusters in Mesos. Perhaps handy for them, but for me that takes most of the use out of Mesos.

Mesosphere's DNS implementation (https://github.com/mesosphere/mesos-dns) helps address that problem. You can use dns routing to create an internal storage or implement a cache that routes cache misses to an external store.

Mesos-DNS has nothing to do with data persistance on mesos. It is just another implementation of cluster service locator.

That's a rather large overlook in a tutorial for a DBMS based app though.