Re: Multimaster
| От | Dorian Hoxha |
|---|---|
| Тема | Re: Multimaster |
| Дата | |
| Msg-id | CANsFX04RArfV4sWpVymUUefjDoiCf54VUzukA3XbY5pDoY3NKg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Multimaster (Moreno Andreo <moreno.andreo@evolu-s.it>) |
| Ответы |
Re: Multimaster
|
| Список | pgsql-general |
@Konstantin
1. It's ok in my cases.2. Not required in my cases.
3. Just require users to use different servers for now I think. Sometimes(always?) users can be greedy with feature requests.
4. I want magically consistency + failover (I can instruct the client to retry all masters).
Good-cluster is the only thing that is stopping postgresql from killing many nosqls in my opinion. Citusdb is single-master(can't even update many rows on the same shard), Postgres-XL has no highavailibility (and having 3 servers per node + global dtm), GreenPlum is olap(and old version of postgres), app-side sucks.
With sharding, the holy-grail is to have automatic-global-range-partitioning (hypertable,hbase,cockroachdb,bigtable etc) on the primary-key or a special column. The con of this, is that indexes of a row reside in another region, which may mean another server, which you need cross-server-transaction to update a row.
In this case, I think you can save the indexes on the same server as the row and be fine.
In this case, I think you can save the indexes on the same server as the row and be fine.
To have good speed you can implement: 1-shard-only-queries (no cross-nodes transaction), async-disk changes (so the changes are done only in the memory of all replicated servers and not in commit-log (used by couchbase)).
Multi-shard transactions aren't needed as much in my opinion.
5. The fewer places/files there are to configure any system the better it is IMHO.
Cheers and good luck!
On Fri, Apr 1, 2016 at 8:15 PM, Moreno Andreo <moreno.andreo@evolu-s.it> wrote:
Il 01/04/2016 17:22, Joshua D. Drake ha scritto:On 04/01/2016 04:50 AM, Konstantin Knizhnik wrote:I'd like to post my use case, hoping it could be of any interest.There are also some minor technical issues which lead us to making few
changes in pglogical code but we tried to do our best to keep original
versions unchanged, so we can switch to public version in future.
It seems the better solution for all of this would be for BDR and this project to come together as a community project to get multimaster for PostgreSQL. Otherwise we are going to end up with the same situation we had before Pg had master-slave replication.
JD
We are giving a cloud service, based on our professional application, hosting databases on our server and replicating them to every site the users register with.
Every user have (for now) a unique database to keep in sync.
Users write on their local database and data is replicated with the server via a background process running while user is connected.
Actually we have to improve what our replicator is doing: it's only replicating the single user's database. The improvement should that we can put it on the "server" (in some cases there are groups of users sharing a dedicated server) and, given a configuration of what and how to replicate, it should replicate more than one DB a time.
Actually, it's a stand-alone program, but what we'd like would be something more integrated in PostgreSQL, so where PostgreSQL can run (everywhere!), so can it.
We were beginning to "translate" (and then improve) this program in c#, when I bumped into articles pointing to BDR, and I started taking a look. But it seems that is good to replicahe whole servers, and still hasn't the granularity we need.
My 2 cent...
Cheers,
Moreno.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: