GitHub - superfly/litefs: FUSE-based file system for replicating SQLite databases across a cluster of machinesYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GitHub - backtrace-labs/verneuil: Verneuil is a VFS extension for SQLite that asynchronously replicates databases to S3-compatible blob stores.
Verneuil1 [vɛʁnœj] is a VFS (OS abstraction layer) for SQLite that accesses local database files like the default unix VFS while asynchronously replicating snapshots to S3-compatible blob stores. We wrote it to improve the scalability and availability of pre-existing services for which SQLite is a good fit, at least for single-node deployments. Backtrace relies on Verneuil to backup and replicate
Litestream - Streaming SQLite Replication
Stop building slow, complex, fragile software systems. Safely run your application on a single server. Fully-replicated database with no pain and little cost. Get started Join our Slack No-worry backups Continuously stream SQLite changes to AWS S3, Azure Blob Storage, Google Cloud Storage, SFTP, or NFS. Quickly recover to the point of failure if your server goes down. Use existing apps Runs as a s
pglogical - 2ndQuadrant | PostgreSQL
pglogical is a logical replication system implemented entirely as a PostgreSQL extension. Fully integrated, it requires no triggers or external programs. This alternative to physical replication is a highly efficient method of replicating data using a publish/subscribe model for selective replication. pglogical forms the foundation for BDR – which runs as an extension on top of it – providing the
ReAir: Easy-to-Use Tools for Migrating and Replicating Petabyte-Scale Data Warehouses
Airbnb’s data infrastructure has been an essential part of our strategy to continuously improve our products. Our Hive data warehouse grew exponentially from 350TB in the middle of 2013 to 11PB by the end of 2015. As the company grew, the demands on the reliability of the warehouse grew as well, and we sought to migrate our warehouse to new architectures. We found that existing migration tools eit
MySQLレプリケーションにおけるフェイルオーバー – OpenGroove
MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時に やることをざっくりまとめてみた。 マスタでは障害等によりMySQLインスタンスが停止していることが前提。 マスタ1:スレーブ1構成の場合 1.マスタに昇格するスレーブにSTOP SLAVEを発行。 2.マスタに昇格するスレーブにRESET MASTERを発行。 3.スレーブに降格するマシンでCHANGE MASTER を実行し、 START SLAVEする。 もう少し詳しく書くと。 1.スレーブ側でIOスレッドでのバイナリログ受け渡しが完了する頃を見計らって、 STOP SLAVE IO_THREAD を発行。 mysql > STOP SLAVE IO_THREAD; “Has read all relay log”を確認できまるまで、SHOW PROCESSLIST の出力結果をチェックする。 2.ス
MySQL :: MySQL 4.1 リファレンスマニュアル :: 4.11.9 レプリケーション FAQ
FLUSH TABLES WITH READ LOCK gtar zcf /tmp/backup.tar.gz /var/lib/mysql（または、このバリエーション） SHOW MASTER STATUS（後で必要となるため、出力を必ず記録しておく） UNLOCK TABLES 代替手段として、上記のバイナリコピーの代わりに、マスタの SQL ダンプを使用することもできます。これを行うには、マスタで mysqldump --master-data を実行し、後でその SQL ダンプをスレーブで実行します。ただし、これはバイナリコピーよりも時間がかかります。 2 つの方法のどちらを使用する場合でも、その後、スナップショットがあり、ログ名およびオフセット値を記録する場合の指示に従ってください。同じスナップショットを使用して複数のスレーブをセットアップできます。いったんマスタのスナップショッ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.8 フェイルオーバー中のソースの切替え
(MySQL 8.0.23 の)CHANGE REPLICATION SOURCE TO ステートメントまたは CHANGE MASTER TO ステートメント (MySQL 8.0.23 の前) を使用して、新しいソースに変更するようレプリカに指示できます。 レプリカは、ソース上のデータベースがレプリカ上のデータベースと互換性があるかどうかをチェックしません。単に、新しいソースバイナリログ内の指定された座標からイベントの読取りおよび実行を開始します。 フェイルオーバーの状況では、グループ内のすべてのサーバーが同じバイナリログファイルから同じイベントを実行するのが一般的であるため、イベントのソースを変更しても、変更を加えるときに注意することで、データベースの構造または完全性に影響を与えないはずです。 レプリカは、バイナリロギングを有効にして実行するようにしてください (--log-bin
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.4.2.1 CHANGE MASTER TO ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL レプリケーションの設定 - maruko2 Note.
MySQL レプリケーションの設定 提供：maruko2 Note. 移動： 案内, 検索 目次 1 MySQL レプリケーションの特徴 2 MySQL レプリケーションの動作概要 3 レプリケーションのセットアップ 3.1 レプリケーション用の my.cnf 設定 3.2 マスターにレプリケーション専用のユーザーを登録する 3.3 マスターサーバのスナップショットを作成する 3.4 マスターサーバのスナップショットを元に、スレーブを作成する 4 レプリケーションが正常に行われているか確認する方法 5 マスターのバイナリログの削除 6 参考ページ 7 MySQL 関連のページ MySQL レプリケーションの特徴 MySQL のレプリケーションは非同期。 1つのマスターに対して、1つ以上のスレーブが可能。 更新系のクエリはマスターのみで実行しなければならい。更新系クエリをスレーブで実行すると
MySQL レプリケーションの設定 - maruko2 Note.
MySQL レプリケーションの設定 提供：maruko2 Note. 移動： 案内, 検索 目次 1 MySQL レプリケーションの特徴 2 MySQL レプリケーションの動作概要 3 レプリケーションのセットアップ 3.1 レプリケーション用の my.cnf 設定 3.2 マスターにレプリケーション専用のユーザーを登録する 3.3 マスターサーバのスナップショットを作成する 3.4 マスターサーバのスナップショットを元に、スレーブを作成する 4 レプリケーションが正常に行われているか確認する方法 5 マスターのバイナリログの削除 6 参考ページ 7 MySQL 関連のページ MySQL レプリケーションの特徴 MySQL のレプリケーションは非同期。 1つのマスターに対して、1つ以上のスレーブが可能。 更新系のクエリはマスターのみで実行しなければならい。更新系クエリをスレーブで実行すると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://webcache.googleusercontent.com/search?q=cache:KEaHYCqHet4J:dev.mysql.com/doc/refman/5.1/ja/replication-solutions-switch.html+&cd=1&hl=en&ct=clnk&lr=lang_en%7Clang_ja
StumbleUpon
MySQL :: MySQL Forums
MySQL :: MySQL 8.0 Reference Manual :: 19.2.1 Replication Formats
HBase - HBase Replication
Searching your Java CMS using Apache Solr: Introduction – Trifork Blog
Replication, max_allowed_packet and LOAD DATA INFILE