<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/feed.rss.xml" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Carsten Birkelbach</title>
    <description/>
    <link>https://speakerdeck.com/cbirkelbach</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/cbirkelbach.rss"/>
    <lastBuildDate>2019-09-23 09:46:02 -0400</lastBuildDate>
    <item>
      <title>Datenbank Schemaänderungen mit Zero Downtime</title>
      <description>Seit Kubernetes ist es einfach geworden, neue Versionen eines Microservices ohne Downtime zu deployen.
Refactorings gehören dabei zum alltäglichen Handwerk eines Entwicklers. Im Datenbankumfeld wird aber bereits die Umbenennung eines Feldes zur Herausforderung.
Wann ist der richtige Zeitpunkt zur Schemaänderung?
Denn entweder kann die alte oder die neue Version des Services nicht mit dem neuen Schema arbeiten.

Also doch wieder im Wartungsfenster den Microservice herunter fahren und die Datenbank migrieren? Oder einen Read-only Modus in den Service einbauen, um so den potentiellen Datenverlust zu vermeiden?

Nicht nötig, denn in diesem Talk werden Rezepte vorgestellt, eine Schemaänderung ohne Downtime oder Datenverlust zu meistern.

Es wird gezeigt, wie Datenbankmigrationen getestet werden können.

Dabei wird der Talk durch Beispiele und Fallstricke aus der Praxis veranschaulicht.</description>
      <media:content url="https://files.speakerdeck.com/presentations/bbea34236da04304a39704eb9127e33e/preview_slide_0.jpg?13673505" type="image/jpeg" medium="image"/>
      <content:encoded>Seit Kubernetes ist es einfach geworden, neue Versionen eines Microservices ohne Downtime zu deployen.
Refactorings gehören dabei zum alltäglichen Handwerk eines Entwicklers. Im Datenbankumfeld wird aber bereits die Umbenennung eines Feldes zur Herausforderung.
Wann ist der richtige Zeitpunkt zur Schemaänderung?
Denn entweder kann die alte oder die neue Version des Services nicht mit dem neuen Schema arbeiten.

Also doch wieder im Wartungsfenster den Microservice herunter fahren und die Datenbank migrieren? Oder einen Read-only Modus in den Service einbauen, um so den potentiellen Datenverlust zu vermeiden?

Nicht nötig, denn in diesem Talk werden Rezepte vorgestellt, eine Schemaänderung ohne Downtime oder Datenverlust zu meistern.

Es wird gezeigt, wie Datenbankmigrationen getestet werden können.

Dabei wird der Talk durch Beispiele und Fallstricke aus der Praxis veranschaulicht.</content:encoded>
      <pubDate>Tue, 24 Sep 2019 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/cbirkelbach/datenbank-schemaanderungen-mit-zero-downtime-710d9345-1d83-4337-9a24-2a1ea34ee886</link>
      <guid>https://speakerdeck.com/cbirkelbach/datenbank-schemaanderungen-mit-zero-downtime-710d9345-1d83-4337-9a24-2a1ea34ee886</guid>
    </item>
    <item>
      <title>JUG Hannover: Datenbank Schemaänderungen mit Zero Downtime</title>
      <description>Seit Kubernetes ist es einfach geworden, neue Versionen eines Microservices ohne Downtime zu deployen.
Refactorings gehören dabei zum alltäglichen Handwerk eines Entwicklers. Im Datenbankumfeld wird aber bereits die Umbenennung eines Feldes zur Herausforderung.
Wann ist der richtige Zeitpunkt zur Schemaänderung?
Denn entweder kann die alte oder die neue Version des Services nicht mit dem neuen Schema arbeiten.

Also doch wieder im Wartungsfenster den Microservice herunter fahren und die Datenbank migrieren? Oder einen Read-only Modus in den Service einbauen, um so den potentiellen Datenverlust zu vermeiden?

Nicht nötig, denn in diesem Talk werden Rezepte vorgestellt, eine Schemaänderung ohne Downtime oder Datenverlust zu meistern.

Es wird gezeigt, wie Datenbankmigrationen getestet werden können.

Dabei wird der Talk durch Beispiele und Fallstricke aus der Praxis veranschaulicht.</description>
      <media:content url="https://files.speakerdeck.com/presentations/75cccbd4120f480bad1dff57ad18c279/preview_slide_0.jpg?13670907" type="image/jpeg" medium="image"/>
      <content:encoded>Seit Kubernetes ist es einfach geworden, neue Versionen eines Microservices ohne Downtime zu deployen.
Refactorings gehören dabei zum alltäglichen Handwerk eines Entwicklers. Im Datenbankumfeld wird aber bereits die Umbenennung eines Feldes zur Herausforderung.
Wann ist der richtige Zeitpunkt zur Schemaänderung?
Denn entweder kann die alte oder die neue Version des Services nicht mit dem neuen Schema arbeiten.

Also doch wieder im Wartungsfenster den Microservice herunter fahren und die Datenbank migrieren? Oder einen Read-only Modus in den Service einbauen, um so den potentiellen Datenverlust zu vermeiden?

Nicht nötig, denn in diesem Talk werden Rezepte vorgestellt, eine Schemaänderung ohne Downtime oder Datenverlust zu meistern.

Es wird gezeigt, wie Datenbankmigrationen getestet werden können.

Dabei wird der Talk durch Beispiele und Fallstricke aus der Praxis veranschaulicht.</content:encoded>
      <pubDate>Mon, 23 Sep 2019 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/cbirkelbach/jug-hannover-datenbank-schemaanderungen-mit-zero-downtime</link>
      <guid>https://speakerdeck.com/cbirkelbach/jug-hannover-datenbank-schemaanderungen-mit-zero-downtime</guid>
    </item>
  </channel>
</rss>
