Primary keys on all tables to help replication

Request new functionality here
Halfwalker
Bear Rating Trainee
Bear Rating Trainee
Posts: 18
Joined: 05 Jul 2014, 22:10

Primary keys on all tables to help replication

Postby Halfwalker » 05 Jul 2014, 22:42


User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Primary keys on all tables to help replication

Postby fox » 05 Jul 2014, 22:59

This sounds a lot like "pls help me make another feedly" so probably no.

e: to elaborate, the keys are set the way they are supposed to be set, I think. changing things arbitrarily because of some whatsitsface mysql thing doesn't sound like a good idea to me.

Halfwalker
Bear Rating Trainee
Bear Rating Trainee
Posts: 18
Joined: 05 Jul 2014, 22:10

Re: Primary keys on all tables to help replication

Postby Halfwalker » 05 Jul 2014, 23:25


User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Primary keys on all tables to help replication

Postby fox » 05 Jul 2014, 23:36

I do understand what you need to change to add a primary key to the table, you don't really have to explain the keywords here.

e: I see some of those are only missed for mysql because fuck mysql I guess so nobody ever cared to notice. If you make a proper pull request I'll consider merging it.

Halfwalker
Bear Rating Trainee
Bear Rating Trainee
Posts: 18
Joined: 05 Jul 2014, 22:10

Re: Primary keys on all tables to help replication

Postby Halfwalker » 05 Jul 2014, 23:38


User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Primary keys on all tables to help replication

Postby fox » 05 Jul 2014, 23:44

I can suggest the following, which should obviously be done in sync for both schema files:

- feedbrowser_cache has feed_url as a primary in pgsql so mysql should use that
- counters_caches, user_prefs - you'll need to add a column i.e. id integer primary key
- linked_instances has a primary key already?
- user_labels2 you can't just set label_id as a primary here, probably requires a separate id column
- version - whatever

e: Probably remove some indexes from newly keyed fields too.

Halfwalker
Bear Rating Trainee
Bear Rating Trainee
Posts: 18
Joined: 05 Jul 2014, 22:10

Re: Primary keys on all tables to help replication

Postby Halfwalker » 08 Jul 2014, 04:20


User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Primary keys on all tables to help replication

Postby fox » 09 Jul 2014, 14:55

If you want any of this changed in trunk, post a properly made pull request.

Halfwalker
Bear Rating Trainee
Bear Rating Trainee
Posts: 18
Joined: 05 Jul 2014, 22:10

Re: Primary keys on all tables to help replication

Postby Halfwalker » 12 Jul 2014, 00:51

Gotta learn git first ...

hrk
Bear Rating Disaster
Bear Rating Disaster
Posts: 75
Joined: 24 Apr 2013, 12:39

Re: Primary keys on all tables to help replication

Postby hrk » 13 Jul 2014, 13:17

If you want to learn GIT, then you should go here:

This (free) book brought me from "How the hell does this work?" to "OMFG it's so easy and powerful and I'll migrate every project to git!".

Having said that, an observation: you clearly didn't follow fox's guidelines to defining the keys. Any particular reason for that?

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Primary keys on all tables to help replication

Postby fox » 17 Jul 2014, 14:20


Halfwalker
Bear Rating Trainee
Bear Rating Trainee
Posts: 18
Joined: 05 Jul 2014, 22:10

Re: Primary keys on all tables to help replication

Postby Halfwalker » 01 Aug 2014, 00:18

hrk - thanks for the pointer, will check it out. As for the keys, I did follow his guidelines, except for feedbrowser_cache. I just wanted to be as unobtrusive as possible, so a simple auto-increment int as a PK seems to do the trick, and avoids the issue with specifying a length for feed_url ... It's just a way to have a unique identifier so the Percona/mysql cluster replication will work cleanly.

fox - I'm sorry, I didn't realize primary keys were a bold idea.

The "installer" is just my own scripted setup. Used by myself and a few others. Got tired of referring to notes and snippets every time I set up a new box or vps, so wound up scripting things. That way I know that it's built the way *I* want, and consistently every time.

For example I use it for building a 3-node redundant email system, and toss in tt-rss as an additional service on top of exim4/dovecot/roundcube/clamav/spamassassin/etc/yada/yada. It's in place and working really swimmingly now - one can hit the servers in a dns-round-robin fashion and everything is kept in sync.

Thanks for all the help.


Return to “Feature requests”

Who is online

Users browsing this forum: No registered users and 6 guests