<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: upgrades</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/upgrades.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2010-05-28T14:50:00+00:00</updated><author><name>Simon Willison</name></author><entry><title>Zero-downtime Redis upgrade discussion</title><link href="https://simonwillison.net/2010/May/28/scheduled/#atom-tag" rel="alternate"/><published>2010-05-28T14:50:00+00:00</published><updated>2010-05-28T14:50:00+00:00</updated><id>https://simonwillison.net/2010/May/28/scheduled/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://github.com/blog/655-scheduled-maintenance-today-22-00-pst"&gt;Zero-downtime Redis upgrade discussion&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
GitHub have a short window of scheduled downtime in order to upgrade their Redis server. I asked in their comments if they’d considered trying to run the upgrade with no downtime at all using Redis replication, and Ryan Tomayko has posted some interesting replies.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/github"&gt;github&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/ops"&gt;ops&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/redis"&gt;redis&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/ryan-tomayko"&gt;ryan-tomayko&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/upgrades"&gt;upgrades&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/recovered"&gt;recovered&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/zero-downtime"&gt;zero-downtime&lt;/a&gt;&lt;/p&gt;



</summary><category term="github"/><category term="ops"/><category term="redis"/><category term="ryan-tomayko"/><category term="upgrades"/><category term="recovered"/><category term="zero-downtime"/></entry><entry><title>Quoting Matt Cutts</title><link href="https://simonwillison.net/2008/Jul/8/upgrade/#atom-tag" rel="alternate"/><published>2008-07-08T09:11:36+00:00</published><updated>2008-07-08T09:11:36+00:00</updated><id>https://simonwillison.net/2008/Jul/8/upgrade/#atom-tag</id><summary type="html">
    &lt;blockquote cite="http://www.mattcutts.com/blog/google-releases-protocol-buffers/"&gt;&lt;p&gt;Question: how do you upgrade servers when you need to pass new information between them? It's a fool's game to try to upgrade both servers at the same time. So you need a communication protocol that is not only backward compatible (a new server can speak the old protocol) but also forward compatible (an old server can speak the new protocol). Protocol Buffers provide that because new additions to the protocol can be ignored by the old server.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p class="cite"&gt;&amp;mdash; &lt;a href="http://www.mattcutts.com/blog/google-releases-protocol-buffers/"&gt;Matt Cutts&lt;/a&gt;&lt;/p&gt;

    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/google"&gt;google&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/matt-cutts"&gt;matt-cutts&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/protocolbuffers"&gt;protocolbuffers&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/upgrades"&gt;upgrades&lt;/a&gt;&lt;/p&gt;



</summary><category term="google"/><category term="matt-cutts"/><category term="protocolbuffers"/><category term="upgrades"/></entry></feed>