{"id":17569081,"url":"https://github.com/riywo/captheorem","last_synced_at":"2025-04-22T11:06:44.080Z","repository":{"id":4103132,"uuid":"5212171","full_name":"riywo/CAPtheorem","owner":"riywo","description":null,"archived":false,"fork":false,"pushed_at":"2012-07-28T05:34:14.000Z","size":101,"stargazers_count":5,"open_issues_count":0,"forks_count":2,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-03-29T14:23:31.906Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/riywo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2012-07-28T05:09:53.000Z","updated_at":"2016-03-07T18:23:32.000Z","dependencies_parsed_at":"2022-09-14T21:50:51.489Z","dependency_job_id":null,"html_url":"https://github.com/riywo/CAPtheorem","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/riywo%2FCAPtheorem","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/riywo%2FCAPtheorem/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/riywo%2FCAPtheorem/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/riywo%2FCAPtheorem/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/riywo","download_url":"https://codeload.github.com/riywo/CAPtheorem/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250227239,"owners_count":21395728,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-21T17:09:03.686Z","updated_at":"2025-04-22T11:06:44.049Z","avatar_url":"https://github.com/riywo.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003ctable\u003e\n\u003ctr\u003e\n  \u003ctd\u003e\u003c/td\u003e\n  \u003ctd\u003eクライントも繋がらないノード障害\u003c/td\u003e\n  \u003ctd\u003eクライアントは繋がるノード間障害\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eMySQLのslave(master-slave\u0026sharding)\u003c/td\u003e\n  \u003ctd\u003eC型。故障検知してサービスアウトして他のslaveに任せるロジックがあれば短時間で復旧できる。\u003c/td\u003e\n  \u003ctd\u003eレプリ遅延やレプリが切れた場合：A型。レプリを何とかして追いつかせることでCを復旧させる。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eMySQLのmaster(master-slave\u0026sharding)\u003c/td\u003e\n  \u003ctd\u003eC型。但し故障検知してフェールオーバーさせるロジックがあれば短時間で復旧できる。\u003c/td\u003e\n  \u003ctd\u003e(ちょっと違うけど)複数masterへのcommit時に片方のみ失敗：A型。完全な一貫性保持は難しい。\u003c/td\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eMySQL Cluster\u003c/td\u003e\n  \u003ctd\u003eTODO\u003c/td\u003e\n  \u003ctd\u003eTODO\u003c/td\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003ememcached\u003c/td\u003e\n  \u003ctd\u003eデータロスト。オリジンが別にあれば故障ノードを外して再度キャッシュさせることでC型っぽい挙動。\u003c/td\u003e\n  \u003ctd\u003eノード間通信が存在しないので起こり得ない\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eCassandra\u003c/td\u003e\n  \u003ctd\u003eA型。どれかのノードに到達できればレプリカの存在する複数ノードを使って読み書きできる。一貫性は後で復旧させればよいという発想だが、実際は結構大変らしい。\u003c/td\u003e\n  \u003ctd\u003eA型。上と同じ感じ。一貫性の強度をquorumにするといくつかのレプリカノードから情報を確認して不整合あればそこで復旧させたりもできる。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eHBaseのRegionServer\u003c/td\u003e\n  \u003ctd\u003eC型。データ自体はHDFSでレプリカがあるのでマスターノードが新しいRSの割り当てを行ったら復旧する。\u003c/td\u003e\n  \u003ctd\u003eC型。クラスタ分断の場合は、少数の側が自殺することでCを保つらしい。死んだ後は多分上と同じ。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eHBaseのMasterServer\u003c/td\u003e\n  \u003ctd\u003eA型。RSの調停ができなくなるだけなので、早めに復旧できればいいっぽい。スタンバイへのバックアップとかは不明。\u003c/td\u003e\n  \u003ctd\u003eA型。左と同じ。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eMongoDBのprimary(ReplicaSet)\u003c/td\u003e\n  \u003ctd\u003eC型だけどほぼAもカバー。primary障害の場合、どれかが昇格。クライアント側はどれかにつながりさえすれば今のprimaryを知ることができる。\u003c/td\u003e\n  \u003ctd\u003eprimaryと他のreplicaが通信できなくなった場合：多分primary障害と判断されて左と同じ？\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd\u003eZooKeeper\u003c/td\u003e\n  \u003ctd\u003eA型だけどほぼCもカバー。読み込みはどのノードでも可能だが、結果整合性。primaryの場合failoverの間は書けない(多分)。\u003c/td\u003e\n  \u003ctd\u003eA型？分断した場合どうなるの？\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Friywo%2Fcaptheorem","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Friywo%2Fcaptheorem","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Friywo%2Fcaptheorem/lists"}