結果整合性データベースのいま | Yakst
一貫性モデルとして、結果整合性が利用されるデータベースに関して、現状の棚卸しをしているMariaDBプロジェクトの記事である。 各データベースの概要や、評判/成熟度/一貫性/ユースケースに基づいた評価、利点および欠点についてまとめた。 はじめに 結果整合性(eventually consistent) [1] は、多くの大規模分散データベースで使われる一貫性モデルの1つである。このようなデータベースでは、複製されたデータ片に対する全ての変更は 結果的に全ての関連するレプリカに反映される必要がある。 さらに、コンフリクトの解消はこれらのデータベースでは扱われず、更新のコンフリクトが発生した場合、アプリケーションで対処の責任を負う必要がある。 結果整合性は、弱い一貫性の1つの特異形態で、オブジェクトに新規の更新がない場合、ストレージシステムが全てのアクセスが結果的には、最後にアップデートした値
MariaDB Galera Cluster 10.1系でSSLを利用する | 俺的備忘録 〜なんかいろいろ〜
MariaDB Galera Clusterで、クライアントとの接続にSSLを利用することができるようなので、設定してみることにした。 調べていると、Galera Clusterのバージョンが10.0系と10.1系で設定方法が違うようだったが、今回は10.1系での設定を行う。 1.鍵ファイルの作成 まずは、Galera Cluster側で以下のコマンドを実行し、公開鍵の作成を行う。 openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem [root@BS-PUB-GALERA-01 ~]# openssl genrsa 2048 > ca-key.pem Generating RSA private key, 2048 bit l
Amazon AuroraとMariaDB Connector/Jの話 - プログラマでありたい
今月創刊したクラウド専門誌の日経クラウドファースト。その特集の1つが、Amazon Auroraです。私も、その特集の執筆に協力させて頂きました。 itpro.nikkeibp.co.jp その中で、AuroraとMariaDB版のConnector/Jについて少し触れています。個人的にはMariaDB版のConnector/Jは、設計思想や実装面から将来性があり、かなり面白い製品と思っています。せっかくの機会なので、少し紹介します。 Auroraのクラスタ・エンドポイントとインスタンス・エンドポイント MariaDBのConnector/Jの話をする前に、まずAuroraに接続するためのエンドポイントの説明をします。Auroraには、クラスタ・エンドポイントとインスタンス・エンドポイントの2種類のエンドポイントを持っています。 インスタンス・エンドポイントは、Auroraの各インスタンス
MariaDB のデータを mysqldump でバックアップ・リストアする - CUBE SUGAR CONTAINER
MySQL (MariaDB) のデータをバックアップ・リストアする方法には色々なやり方があるみたい。 今回は、その中でも最もオーソドックスな mysqldump を使う方法を試してみる。 また、mysqldump はその時点でのデータベースの内容を全て書き出すフルバックアップなので、コマンドを実行した後に行われた更新内容についてはリストアすることができない。 そのため、フルバックアップ後の更新内容については MySQL (MariaDB) からリアルタイムに出力されるバイナリログを差分バックアップとして残しておき、障害直前のデータまで復旧を行うロールフォワードリカバリについても試しておく。 今回の検証環境には CentOS7 を使った。 また、リストア元とリストア先でふたつの仮想マシンを用意しておくと良い。 $ cat /etc/redhat-release CentOS Linux r
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
