вобщем цель такова :
имею 10 vps с mysql на борту , юзер коннектиться к какому-то одному из серверов и требуеться что-бы изменения которые он произвел в БД моментально копировались на остальные бд , при этом что-бы не возникало косяков заключающихся в том что 2 юзера на разных серверах изменили одну и ту-же строку в одной и той-же таблице с разницей во времени скажем 0,2 секунды и при этом данные в этих 2-х бд оказались конфликтующими

была мысль перед тем как заносить данные во все бд лочить запросы от остальных юзеров к этой таблице, но тогда я могу пострадать от DDOS-a так как при этом подходе независимо от того сколько у меня серверов достаточно будет положить один

Репликация мастер-мастер в реальном времени, на десять инстансов. Нереально. Лучше всего попробовать переформулировать задачу, возможно разнести разные части таблиц по разным серверам.

критична всего одна таблица , если на одном (11-м) из серверов повесить демона который будет принимать запросы от юзеров к критичной таблице и делать одновременные запросы ко всем остальным серверам
а остальные таблицы к примеру можно синхронизировать раз в 2 часа

такое реально реализовать при условии что количество юзеров - 20 000 в сутки , из них доступ к критичной таблице будут иметь только около 2000 - 4000 , при этом селект запросы каждым будут совершаться раз в 10 минут , а количество alter составит максимум 100 за сутки естественно никакой периодичности

если сделать так что-бы возможный ддос не мог затронуть критичную таблицу то тогда реализация вышеописанного реальна ?


######

или лучше сделать на 11-м серве бд содержащую только критичную таблицу и остальные 10 будут делать запросы к ней , а синхронизацию таблиц на 10 серваках производить раз в 1-2 часа

ps: в критичной таблице всего 2 колонки , обе bigint unsigned , одна из них (id) - primary key

> косяков заключающихся в том что 2 юзера на разных серверах изменили одну и ту-же строку в одной и той-же таблице

Именно для этой таблицы запись производить только на одном сервере, на остальные потихоньку разливать - тогда (по идее) коллизий не будет.

Гарантированно - только вариант с 11 сервером.

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

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

Аналогия: subversion - первый случай, mercurial - второй.

Есть другой вариант, но он потребует более серьезных изменений в архитектуре.
Сделать разделение (Partitioning) и разнести по серверам критичную таблицу, чтобы защититься от ДДОС.
Каждая запись будет находится только на 1 сервере. Разрешение конфликтов - простое.
В этом случае вы экономите 1 сервер, но требуется настройка Partitioning.

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

В документации по MySQL есть раздел.
Фактически, вам нужно выбрать способ разделения и указать условия.