вы считаете + 60% к цене это нормально? боюсь предположить, но мне кажется что вашим основным покупателем являются люди которые не совсем в теме. т.е. вы просто что-то навязываете (пластинки по +60% к стоимости, «пластмассовые» Denon'ы etc), т.к. ни один человек собирающий винил не будет его покупать в российском магазине, а если уж говорить о коллекцонерах то их магазин вообще discogs, как-то так
Как помне, все эти проигрыватели/иглы для «домашнего использования» не стоят своих денег, более того я вряд ли найду иглы которые звучат лучше Shure, причем в России как обычно на все есть своя наценка которая смотриться, мягко скажем, бесчеловечно, смотрите сами: ваша цена на пластинки http://www.audiomania.ru/vinilovye_plastinki/sade/, реальная цена http://www.juno.co.uk/artists/Sade/?facet%5Bformat_type_norm_facet%5D%5B0%5D=LP
линейка Technics 1200 всегда была именно домашней, за 30 с гаком лет там ничего не поменялось, для особых аудиофилов есть MK4 который помимо 33/45 еще и на 78 оборотов крутит, и, кстати, в сравнении с «лучшими» у них прямой привод + тяжелый тонвал что, на минуточку, не пасиковый привод
Аргументированная критика это хорошо и, возможно, это все действительно неправда, но вы действительно считаете что данные ссылки все разъясняют:
START TRANSACTION;
CREATE TABLE t (s1 SMALLINT);
INSERT INTO t VALUES (1);
INSERT INTO t VALUES (32768); /* This causes an error. */
COMMIT;
SELECT * FROM t;
Result:
MySQL finds a row containing 1. PostgreSQL finds nothing.
Reason:
PostgreSQL rolls back the entire transaction when it encounters a syntax error. MySQL only cancels the statement.
CREATE TABLE t (s1 INT);
INSERT INTO t VALUES (1);
COMMIT;
START TRANSACTION;
SELECT CURRENT_TIMESTAMP FROM t;
/* Pause 1 second. */
SELECT CURRENT_TIMESTAMP FROM t;
Result: PostgreSQL shows the same timestamp twice. MySQL shows two different timestamps.
Reason:
PostgreSQL keeps the same time throughout a transaction; MySQL keeps the same time throughout a statement.
The key sentences in the standard say that the result of a datetime value function should be the time when the function is evaluated, and «The time of evaluation of a datetime value function during the execution of S and its activated triggers is implementation-dependent.»
* при этом замечу что как раз функции (пример: clock_timestamp()) ведут себя ожидаемым образом
и т.д.
ps: я бы еще не отказался почитать о печальной известности bitmap-индексов постгреса
С таким подходом вы, скорее всего, многое упускаете т.к. если бы потрудились и просмотрели хотя бы главную страницу проекта и, таки да — «дрова завезли»
Если честно, то самое реальное преимущество PostgreSQL которое даст «скорость работы, разработке и т.п» — это отдавать большую часть работы на сторону СУБД за счет большей поддержки SQL и, конечно, PL/pgSQL, но это, по разным причинам, не для всех. Плюсом ко всему в современном многоядерном/многопроцессорном мире Postgres со своей «процессной моделью» гораздо лучше масштабируется по ядрам/физическим процессорам. Я вас не призываю к использованию Postgres, кто-то испытывает боль при работе с ним, кто-то с другим решением, но сравнивать Postgres и MySQL достаточно тупиковое решение — они очень разные
Координатор при 2-х машинах достаточно ненужное решение.
При живом архиве на слейве можно/нужно указать restore_command на слейве,
в случае падения просто rsync'нуть недостающие wal'ы на слейв с мастера и сделать ему promote, если отставание не большое, как вы пишите, то это достаточно шустро, при синхронной rsync'аться не надо, но если данные важны то перепровериться стоит и, опять же, promote.
В любом случае вам нужно будет время на определение того что мастер «ушел» чтоб не переключаться на «каждый чих», а это даунтайм если ваше приложение не способно уходить в «RO» на слейв
PS: посмотрите еще repmgr, в последние дни его как ругают так и хвалят )
Все хотят чтоб «без разрыва», но, увы, пока в природе чуда которое сответствует вашим требованиям не существует.
Можно попробовать разобраться в проблеме.
1. «Балансировать селекты между нодами»
Постгрес, как и любая современная РСУБД, способен спокойно держать пару десятков тысяч OLTP-транзакций в секунду с достаточно среднего железа. Вам «селекты» нужно балансировать чтоб железо не простаивало или действительно есть потребность?
2. «почему два хоста? потому, что нужен-то мастер-слейв и потому, что три хоста дороже, чем два.»
«Мастер-слейв» не спасают вас от потери данных, truncate cascade в данном случае может превратить не 1, а 2-е машины в «тыкву» (синхронно или асинхронно он это сделает выбирать вам) посмотрите в сорону создания бекапов (PITR). Поэтому и ваше желание «вообще не терять данные» и «не дорого» — это взаимоисключающие понятия
По фейловеру можете посмотреть исходники Patroni, Stolon чтоб понять что там и как или попробовать использовать одно из решений
Замечу, что я не рассказываю что это невозможно, я обращаю ваше внимание на то, что работает репликация именно так. Если вы можете часть своих запросов выполнять на данных которые могут отставать — выполняйте, это частый сценарий.
На сколько сильно у вас отстает мастер при асинхронной репликации и зачем вы «связались» с синхронной при 2-х машинах?
1) А она и не должна, репликация «отпускает» коммит когда логи доехали, а не когда они были применены, в 9,6 для этого появится remote apply michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply
2) Есть такое, но для синхронной репликации крайне не рекомендуется иметь всего 1 машину, т.к. в случае её выпадения мастер «встанет колом»
При условии что у вас всего 2-е машины (мастер-слейв) и пункта 1 вопрос: вам точно нужна синхроная репликация?
Не совсем так, цель планирования — получить самый «дешевый» план выполнения, запрашиваемые поля в этом случае влияют на стоимость «в районе» доступа к хранилищу (нужно нам с диска читать и сколько), поэтому это достаточно нормальное поведение.
И, да, планировщик не должен всегда трансформировать подобные запросы, т.к. данный «финт ушами» во многих случаях дороже
Крайне не рекомендуется использовать LIMIT без ORDER BY т.к. это может помешать в выборе правильного плана оптимизатором. В отличии от MySql у постгреса первичный ключ не кластер и он не «выравнивает» данные по индексу постоянно, отсюда и «неожиданный» результат т.к. при последовательном вычитывании данные будут расположены в порядке изменения (mvcc)
В MySql подобный выигрыш ощутимие и стабильнее по причине того, что даже при index only scan постгрес может «бегать» на диск что в explain будет показано в heap fetches, тут все дело в visibility map и такие «фокусы» в постгресе будут работать не на всех таблицах/данных особенно у тех кто «сознательно отключает autovacuum», хотя, стоит сказать, что с «глубокими» limit/offset постгрес справляется вполне достойно
очень, мягко скажем, противоричивый источник правды
* при этом замечу что как раз функции (пример: clock_timestamp()) ведут себя ожидаемым образом
и т.д.
ps: я бы еще не отказался почитать о печальной известности bitmap-индексов постгреса
При живом архиве на слейве можно/нужно указать restore_command на слейве,
в случае падения просто rsync'нуть недостающие wal'ы на слейв с мастера и сделать ему promote, если отставание не большое, как вы пишите, то это достаточно шустро, при синхронной rsync'аться не надо, но если данные важны то перепровериться стоит и, опять же, promote.
В любом случае вам нужно будет время на определение того что мастер «ушел» чтоб не переключаться на «каждый чих», а это даунтайм если ваше приложение не способно уходить в «RO» на слейв
PS: посмотрите еще repmgr, в последние дни его как ругают так и хвалят )
Можно попробовать разобраться в проблеме.
1. «Балансировать селекты между нодами»
Постгрес, как и любая современная РСУБД, способен спокойно держать пару десятков тысяч OLTP-транзакций в секунду с достаточно среднего железа. Вам «селекты» нужно балансировать чтоб железо не простаивало или действительно есть потребность?
2. «почему два хоста? потому, что нужен-то мастер-слейв и потому, что три хоста дороже, чем два.»
«Мастер-слейв» не спасают вас от потери данных, truncate cascade в данном случае может превратить не 1, а 2-е машины в «тыкву» (синхронно или асинхронно он это сделает выбирать вам) посмотрите в сорону создания бекапов (PITR). Поэтому и ваше желание «вообще не терять данные» и «не дорого» — это взаимоисключающие понятия
По фейловеру можете посмотреть исходники Patroni, Stolon чтоб понять что там и как или попробовать использовать одно из решений
На сколько сильно у вас отстает мастер при асинхронной репликации и зачем вы «связались» с синхронной при 2-х машинах?
2) Есть такое, но для синхронной репликации крайне не рекомендуется иметь всего 1 машину, т.к. в случае её выпадения мастер «встанет колом»
При условии что у вас всего 2-е машины (мастер-слейв) и пункта 1 вопрос: вам точно нужна синхроная репликация?
И, да, планировщик не должен всегда трансформировать подобные запросы, т.к. данный «финт ушами» во многих случаях дороже