Announcement

Collapse
No announcement yet.

Deploying a new binary

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Deploying a new binary

    I am trying to understand how VoltDB handles deploying new binaries to running server instances?

    I think that the steps might be like below, but am not sure:
    1. Stop the instance that you want to restart with a new binary
    2. Replace the binary, and restart the instance
    3. The instance reads data from disk and reaches the same state where the old process was killed

    My concern is that step #3 is slower than the rest of the working of VoltDB (disk vs memory), and I am wondering how that is handled to be fast?

  • #2
    The safe process to upgrade VoltDB binaries is to use a maintenance window and restore from a snapshot.

    This is the same process described here, except during the downtime you would replace the binaries:
    http://voltdb.com/docs/UsingVoltDB/U...aveRestore.php

    I've written a step-by-step example for our Dev Center, which is pending approval for publishing, but has been tested. It may help as well.

    https://github.com/VoltDB/devcenter/...nce-process.md

    During the maintenance window, you would cut over from the older version to the new version. Depending on how you script things, this may be as simple as updating which folder is in the PATH, or renaming folders.

    As a tip, what I do when installing VoltDB is to untar the file to my home directory, and leave the folder name as-is which includes the version number, for example "voltdb-ent-3.6", and then I create a "voltdb" symlink to it, "ln -s ~/voltdb-ent-3.6 ~/voltdb". Then I add $HOME/voltdb/bin to the PATH. When I upgrade to a new version, I can untar the new folder ahead of time so voltdb-ent-3.7 is right alongside the older version, and during the maintenance window the only thing I need to do for the cutover is to rm and recreate the symlink to point to the new binary. This also allows me to revert quickly in the event of any issues. I find this easier than renaming folders or editing scripts to update paths.

    Comment


    • #3
      Thanks, when you say "restore from snapshot", would we be reading the snapshot from disk?

      Comment


      • #4
        That is correct. I meant to add earlier that the speed of restoring from disk depends on the data size, disk speed, level of k-safety, and the number of servers in the cluster.

        Just to make sure I understood correctly, by deploying a new binary, I'm talking about upgrading to a new version of VoltDB. If you mean updating the schema and stored procedures, that does not require any downtime or reloading from disk, you can do that on the fly using the voltadmin update command.

        Comment


        • #5
          It is frequently necessary to search for orders by date and/or perform date computations for our app. There are no DATE/DATETIME datatypes in VoltDB. How are date functions handled? The guide suggest avoiding Date objects.
          FSL:

          Comment


          • #6
            VoltDB uses the TIMESTAMP datatype, which includes date and time. You can insert a date string in the format 'YYYY-MM-DD' into a timestamp datatype column and it will default the time to 00:00:00.

            There are a number of functions that work with timestamp. See the section on Date & Time Functions on this page:
            http://docs.voltdb.com/UsingVoltDB/AppSqlFuncs.php

            You may have read about the need to ensure stored procedures are deterministic, so to avoid code like "new Date()" within a procedure. You can instead use the getTransactionTime() method within the procedure, or you could use the NOW or CURRENT_TIMESTAMP SQL functions to get the same value. There is more information about that here: http://docs.voltdb.com/UsingVoltDB/D...rocDeterminism

            Comment

            Working...
            X