Minimize downtime when regenerating graph-cache

gspeed · February 12, 2019, 9:24pm

Of course anyone needs to update his environment with fresh pbfs data soon or later; to minimize downtime a 2nd instance of Graphopper can be run with the “-a import” to just create a new graph-cache “offline”. Then just restart the “-a web” Graphhopper instance: however this will create an outage (in my case just a few mins, acceptable).

I was wandering if there is any better way to reduce the downtime, any hint?

I found this discussion, where it is mentioned "At least two independent processes are recommended for production (no down time). " which suggests to have two listeners up and use just one at time, correct?

Thanks!

Harel · February 12, 2019, 9:57pm

I couldn’t convince the guys at GH to facilitate this using HTTP calls so I created a fork and implemented it. I wanted this to be merged to the main version but my pull request was declined.
The code can be found here:

There’s a rebuild http call that receives a pbf file, creates a cache, and replaces the in-memory graph object so the the downtime is minimal.
Here’s the code that uses it:

github.com

IsraelHikingMap/Site/blob/master/IsraelHiking.DataAccess/GraphHopperGateway.cs

using System;
using System.IO;
using System.Linq;
using System.Net.Http;
using System.Threading.Tasks;
using GeoAPI.Geometries;
using IsraelHiking.Common;
using IsraelHiking.DataAccessInterfaces;
using Microsoft.Extensions.Logging;
using NetTopologySuite.Geometries;
using Newtonsoft.Json;

namespace IsraelHiking.DataAccess
{
    public class GraphHopperGateway : IGraphHopperGateway
    {
        private const string BASE_ADDRESS = "http://localhost:8989/";

        private readonly ILogger _logger;

This file has been truncated. show original

This is not ideal as this forks drifts away from the main version.
The way I think it should be properly solved is using docker - create two containers with GH, rebuild one of them, and switch between them. Docker is the ideal solution as it does exactly that.
I have yet to migrate my current solution to docker though…

karussell · February 12, 2019, 10:40pm

GraphHopper is nothing special and you can place it behind a load balancer (like one does for other services) or you create two GraphHopper instances to swap them on demand (there is no need to fork GraphHopper to do this, just use our maven dependencies in a java project). The problem of the latter solution is that you need twice the amount of RAM and in case you need to replace the hardware or restart the server/node etc you still need the load balancer solution, so we do not see a reason to include the second solution.

Please note that it is note recommended to do the import on the same machine where you do the routing as the import process can consume lots of resources (CPU, disk, RAM).