Re: Uber migrated from Postgres to MySQL
| От | Scott Mead |
|---|---|
| Тема | Re: Uber migrated from Postgres to MySQL |
| Дата | |
| Msg-id | CAKq0gvLJXPEvBnL1_nLE0oKp0BScXMBUxyL9VfHuc1gznqacnw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Uber migrated from Postgres to MySQL (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
| Ответы |
Re: Uber migrated from Postgres to MySQL
(Bruce Momjian <bruce@momjian.us>)
Re: Uber migrated from Postgres to MySQL (Geoff Winkless <pgsqladmin@geoff.dj>) Re: Uber migrated from Postgres to MySQL (Chris Travers <chris.travers@gmail.com>) Re: Uber migrated from Postgres to MySQL (Kevin Grittner <kgrittn@gmail.com>) |
| Список | pgsql-general |
On Wed, Jul 27, 2016 at 3:34 AM, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
"The bug we ran into only affected certain releases of Postgres 9.2 and has been fixed for a long time now. However, we still find it worrisome that this class of bug can happen at all. A new version of Postgres could be released at any time that has a bug of this nature, and because of the way replication works, this issue has the potential to spread into all of the databases in a replication hierarchy."
On 27/07/2016 10:15, Condor wrote:On 26-07-2016 21:04, Dorian Hoxha wrote:Many comments: https://news.ycombinator.com/item?id=12166585
https://www.reddit.com/r/programming/comments/4uph84/why_uber_engineering_switched_from_postgres_to/
On Tue, Jul 26, 2016 at 7:39 PM, Guyren Howe <guyren@gmail.com> wrote:Honestly, I've never heard of anyone doing that. But it sounds like
they had good reasons.
https://eng.uber.com/mysql-migration/
Thoughts?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
They are right for upgrades.
It's a hard to shutdown 1 TB database and wait couple of days pg_upgrade to finish upgrade and meanwhile database is offline.
In some distros after upgrade of PG version you don't have old binary and library, need to do full dump and restore that take time and disk space.
Our last 1TB upgrade from 9.0 -> 9.3 went like a charm in something like seconds. (with the -k option)
However, be warned that the planing and testing took one full week.
That being said, it doesn't really provide a back-out plan. The beauty of replication is that you can halt the upgrade at any point if need be and cut your (hopefully small) losses. If you use -k, you are all in. Sure, you could setup a new standby, stop traffic, upgrade whichever node you'd like (using -k) and still have the other ready in the event of total catastrophe. More often than not, I see DBAs and sysads lead the conversation with "well, postgres can't replicate from one version to another, so instead.... " followed by a fast-glazing of management's eyes and a desire to buy a 'commercial database'.
All in all, Evan's blog seemed to start out decently technical, it quickly took a turn with half-truths, outdated information and, in some cases, downright fud:
ISTM that they needed a tire swing and were using a dump truck. Hopefully they vectored somewhere in the middle and got themselves a nice sandbox.
--Scott
Regards,
Hristo S.
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
--
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 по дате отправления:
Предыдущее
От: Artur ZakirovДата:
Сообщение: Re: FTS with more than one language in body and with unknown query language?