Объединить несколько результатов MySQL запроса в один

Question

[Maxima]

Есть запрос с сервера А
$queryA = mysql_query("SELECT * FROM table");
и запрос с сервера B
$queryB = mysql_query("SELECT * FROM table");
Таблицы идентичны, во всем кроме данных.
Данные сервера А частично (в начале) равны данным с сервера B
Сортировка по дате.

Нужно собрать данные из двух таблиц в один mysql_fetch_array
Возможно ли это?

Comments

[Maxima]

Акцент: Таблицы одинаковые по структуре и названию живут на физически разных серверах в разных датацентрах.

Answer 1

[Анатолий]

mysql_fetch_array нужен рессурс, рессурса у вас два, в итоге ничего у вас не выйдет, array_merge вам в помошь, я думаю это единственный вариант. Хотя я могу ошибаться =)

Comments

[Maxima]

array_merge это первое что я попробовал.
Видимо не корректно это делал, но всё грустно.

[Анатолий]

если названия полей одинаковые, то в принципе должно их обьеденить без проблем:

$array1 = array(
	array(
		"id"   => "1",
		"name" => "name1"
	),
	array(
		"id"   => "2",
		"name" => "name2"
	)
);

$array2 = array(
	array(
		"id"   => "3",
		"name" => "name3"
	),
	array(
		"id"   => "4",
		"name" => "name4"
	)
);

print_r( array_merge( $array1, $array2 ) );

// вывод

Array
(
    [0] => Array
        (
            [id] => 1
            [name] => name1
        )

    [1] => Array
        (
            [id] => 2
            [name] => name2
        )

    [2] => Array
        (
            [id] => 3
            [name] => name3
        )

    [3] => Array
        (
            [id] => 4
            [name] => name4
        )

)

[Maxima]

ID могут пересекаться при том что данные будут там разные

[Maxima]

Хотя я туплю, мне не обязательно иметь ID на выходе

Answer 2

[Алексей Сидоров]

Нда… печаль. Срочно курить нормализацию

Comments

[Maxima]

Готов внять совету гуру

Answer 3

[mgyk]

Тут проблема в постановке задачи. Читать данные с другого сервера, можно используя FEDERATED engine. Но вы будите расстроены скоростью.

Можно поднять master-master репликацию в mysql. То есть каждый сервер будет себя считать слейвом :). В таком случае останеться только при проблемах перебрасывать ip. Данные будут подтягиваться автоматом.

Comments

[Maxima]

Не знал про FEDERATED engine буду изучать, спасибо.
Про репликацию сомнительно, там могут пересекаться id полей соответственно не ясно как их объединить корректно.
По id нельзя остается по дате.
Думал что есть возможность как то это дело объединить указав сортировку по дате (не знаю как :-)
очевидно что прийдется это дело собирать в общий массив пересортировав перед этим.
Думал ещё сделать некую промежуточную таблицу на основном сервере в которую по хрону уже пересобирать таблици из двух баз.

[mgyk]

Можно выставить, чтобы id были с каким-то шагом, у меня допустим на одном сервере были 11,21,31 на втором 12,22,32 и т.п. (auto_increment_increment опция) Кроме этого не стоит писать одноврмененно на два сервера. Если писать только на один в каждый момент времени, то все будет ОК :) Если писать на два сервера, то порядок записей будет немного другой + могуть быть аномалии при запросах вида INSERT INTO SELECT FROM

Answer 4

[BearOff]

>> в итоге данные в момент работы резерва на него и пишутся

если я правильно понял, после того, как основной сервер поднимется, на резервном у вас остаются уникальные данные, и отсюда возникает потребность в объединении результатов?
Если это так, то у вас проблема не в объединении двух запросов, а в том, что после восстановления основного сервера первым делом необходимо синхронизировать его с резервным, и дальше работать только с основным.

Comments

[Maxima]

Вы всё правильно поняли но синхронизация на мой взгляд не самая безопасная операция, как я уже писал ID записей будут совпадать и единственная разница это время.
Короче я не хочу рисковать данными на основном сервере.
Мне нужно просто объединить результаты.

[BearOff]

Погодите, но синхронизация — это операция уж точно более безопасная, чем ваша текущая ситуация (как мне кажется).
Я не понимаю, зачем использовать резервный сервер для получения данных, когда работает основной. В чём вы видите сложность синхронизации? Почему вас беспокоят ID? Если они у вас автоинкрементные, вставьте все записи резервного сервера в основной, опуская ID — и все дела. Т.к. дублирования у вас всё равно нет, после синхронизации удаляйте записи с резервного сервера, если опасаетесь, что не сможете их опознать по дате/времени как «уже перенесённые» в следующий раз.

Answer 5

[TimTowdy]

Не извращайтесь. Вы пытаетесь эмулировать мастер-мастер репликацию средствами PHP.

Comments

[Maxima]

Мне не нужна такая репликация. Меня устраивает что на каждом сервере свой контент, я не хочу ничего смешивать ибо опыт такого весьма плачевный.
Просто чтоб вам понять нужно всю страктуру раскрыть, сейчас у нас все сервера работают в кластере и мастер мастер репликация просто не возможна.
И более того губительна для кластера, он сам разруливает всё своими силами.

[TimTowdy]

Про репликацию сомнительно, там могут пересекаться id полей соответственно не ясно как их объединить корректно.

Настройте правильно, тогда пересекаться ничего не будет:
dev.mysql.com/doc/refman/5.0/en/replication-options-master.html#sysvar_auto_increment_increment

[Maxima]

Мы уже всё решили, результат прекрасен и стабилен, о лучшем я и не мечтал.
У нас простое правило мы не можем трогать записи в продакшн БД.
Ни какого внешнего воздействия быть не должно.
Сейчас так и есть.

[TimTowdy]

просто есть резервный сервер, а есть основной они физически в разных местах.
В случае падения основного, начинает работу резервный (плюс он в кластере вообще), в итоге данные в момент работы резерва на него и пишутся очевидно, и они важны клиентам, и их нужно как то выдать вместе с данными с основного сервера.

Судя по этому описанию — именно она вам и нужна. Не понимаю в чём смысл хранить отдельно данные, которые пришли во время сбоя, и которые пришли в штатной ситуации, а потом при запросе их объединять. Делайте мастер-мастер и падение одного сервера никак не скажется на работе системы.

[TimTowdy]

Вы хотите получить отказоустойчивость, но изначально выбрали неправильный путь. Нужна отказоустойчивая база данных — делайте отказоустойчивую базу данных. Если будете пытаться решать проблемы с базой на уровне приложения — получите уродливую архитектуру и кучу геморроя.

[Maxima]

Вы пытаетесь рассуждать имея отрывки данных.
Я уже пояснил что всё работает как мы хотели, и именно так как нам было нужно.
У нас две задачи, первая это отказоусточивость, вторая это кластеризация.
Иначе бы получилось что мы используем резервные сервера в те редкие дни когда канал основного сервера падал.
Сейчас у нас все сервера работают в одном кластере и если основной сервер отрубается из кластера то вся инфа сохраняется на резервных серверах, очевидно.
И вот в этих редких случаях инфа с этих серверов (за небольшой промежуток времени простоя основного сервера) становилась недоступна клиентам.
А вот теперь всё доступно.

Answer 6

[homm]

UNION

Comments

[Maxima]

Я не очень понял, а как его использоватьесли данные с разных серверов?

[homm]

Простите, информацию про разные сервера тупо пропустил. Во первых на нее не сделан акцент, во вторых запросы в примере явно сделаны к одному серверу.

Answer 7

[equand]

Собираете в памяти в один array иначе никак.

Comments

[Maxima]

Да это понятно, я думал есть иной способ.

Answer 8

[eternals]

1. Никак, ёптидь. Это вам не Microsoft SQL Server с его SSIS. Сосите кеглю, вобщем.
Или вон с federated помирайте.

2. Про резервную копию, репликацию и т.д. (в комментах расширение было). У mysql есть встроенный механизм репликации и он вам скорее всего подойдёт.

Comments

[Maxima]

Во первых спокойно.
Во вторых репликация и так есть.
В третьих она тут не поможет.
Толку от вашего коммента, ноль.

[eternals]

Во-первых, держи: ",,,,------". Используй при необходимости.
Во-вторых, ваша проблема в том, что после подъёма основного сервера после падения не происходит автоматического восстановления консистентности.
В-третьих, именно она тут должна помочь. А поможет или нет зависит от вашего уровня интеллекта.
В-четвёртых, толк от моего комментария в том, чтобы вы и другие в следующий раз когда будете планировать системы, вспомнили, что mysql — это кусок устаревшего ненадёжного говна и сделали правильный выбор.

[JeanLouis]

@eternals: ваши комментарии выдают в вас низкопробного специалиста.

[eternals]

JeanLouis, я глубоко озабочен вашим мнением. Особенно если учесть, что в списке «нравится» у вас Opera.
Вас, наверное, сильно разочаровало мой мнение о mysql? Не печальтесь, дела обстоят ещё хуже. Я лет 8 плотно занимаюсь mysql и знаю, о чём говорю.

[Maxima]

Успокойтесь, я всё решил весьма успешно.
На самом деле я в самом начале пошел по верному пути используя array_merge,
но сделал ошибку не убрав ID в результате запроса.
Сейчас всё решилось как нельзя лучше.
Я не синхронизирую ничего, все сервера живут своей жизнью и не влияют друг на друга
в случае падения и после восстановления, а именного этого я и хотел.
На выходе теперь результат с двух серверов, всё супер.
Всем кроме многострадального @eternals, спасибо.

[eternals]

1. Вы так часто призываете к спокойствию и вот теперь пишете комментарий в полчетвёртого ночи. Наверное, вам сейчас не сладко, чувствуется у вас психологический надлом. Вы там до аптеки добегите, персенчику примите. Поспите хоть.

2. Решение зависит от условий задачи. array_merge на уже средних массивах данных вы не используете. Всё это тупо и медленно.

3. Решение с «независимой жизнью серверов» вполне имеет право на существование. Только обычно его делают при больших массивах данных и ещё ряде условий, а у вас, очевидно, просто нарушение в проектировании системы.

4. От вас благодарности сейчас и не жду. Я жду, что публика будет расти вместе с ИТ миром, и постепенно сделает правильные выводы.
Удачи.