Винести базу боксу на окремий сервер

Мені здається це погана витівка, так як наслідки не роботи одного сервера можуть бути плачевними, а також затримки передачі між серверами.
Ви б краще вирішували проблеми з інтеграціями, те що ви описуєте "впровадження у вас можуть синхронізувати з боксом рік" не є нормою

Для нас не проблема підтримувати пов'язаність двох серверів. Вони знаходяться у своїй гермозоні. Розв'язання задачі дозволить підключатися всім системам білінгу/ERP/etc. до однієї БД та вносити актуальні зміни онлайн.
Гірше той, милицю яких збудували зараз, як виявилося це складніший витівок, який намагаються вирішити вже більше року. А саме побудувати синхронний імпорт/експорт для білінг<->CRM

Що вам заважає весь обмін переробити через API, тут у вас з'явиться швидкість і доступ?
Просто розумієте якщо ви пустите в БД іншого розробника, то там почнеться "срач" за яким потрібно стежити (логгувати), а це ще один "головлювати" для ПМ-му проекту

Відсутність API у сервісів, з якими будується зв'язка. Одна система без API, друга працює з API але тільки імпорт в систему, а будь-які доробки виконуються лише їх розробниками системи (з'являється залежність від швидкості реалізації завдань). А Бокс зі своїм API.
Своя інфраструктура швидше у реалізації. + за логування підключимо до graylog.

Зрозуміло тільки що у вас багато змінних у вашому завданні.
Ну давайте почекаємо відповіді Устименка чи Мірошниченка, мені здається за таке завдання братися не будуть, тому що тут багато підводних каменів у тому числі які відповідають за підтримку продукту, це все потрібно десь прописувати

Реальний біль роботи у CRM зараз тільки збільшується, ось тільки уявіть весь шлях оформлення клієнта у CRM зараз.
З телефонії завели контакт у бокс, створили йому картку з фіо та тіл та ін. Далі щоб надавати клієнту послугу (тв/інтернет та ін.) його потрібно передати в білінг (білінг стежить за оплатами і дозволяє Radius серверу авторизувати клієнта)
Оскільки немає двостороннього імпорту/експорту у бокс-білінг, то доводиться створювати обліковий запис окремо у білінгу.
Але працює імпорт у бокс із білінгу. Зараз Бокс створює дубль заявки та виходить задваювання клієнтів у боксі. (Клієнти заведені в боксі та клієнти імпортовані з білінгу)
Зупинити бокс на імпорт небажано, тому що в ньому використовуються бізнес-процеси і вважається за ними ЗП менеджера)
А експорт із боксу повноцінно ще не працює у білінг, щоб в одній системі створювати облік.
І є ще третя система ERP, з якої планували побудувати інтеграцію, але тепер задумався скільки ще на це потрібно часу :)
Сподіваюся, зрозуміло пояснив про всі змінні.
Я з Мірошниченком спілкувався з цього приводу. Давайте почекаємо його повернення, розумію що він поки не доступний, нехай видужує.

Писати щось у базу даних OneBox'a безпосередньо – не варто (навіть "не можна").
OneBox – це не софт, який пишеться "від бази даних". Не все так просто.
Сама БД OneBox'a - не нормалізована згідно з усіма канонами ANSI SQL. Це ціна продуктивності, щоб OneBox міг перетравлювати десятки мільйонів контактів та десятки мільйонів ордерів.
Простими словами (для тих хто не в темі SQL'a) - ті самі дані можуть дублюватися в різні осередки різних таблиць. Для продуктивності вибірок.
Базу даних OneBox'a контролює так званий ORM SQLObject. Це важлива історія:
Коли OneBox оновлюється, SQLObject дивиться які колонки куди додати, які видалити, для яких змінити тип даних. Якщо ви додасте колонку в базу даних - нічого страшного, її SQLObject не чіпатиме. Але якщо ви руками поміняєте колонку - SQLObject через 1 хвилину поверне тип даних на місце згідно з конфігурацією ORM.
Нікому не варто прив'язуватися до бази даних OneBox'a – тому що ми її змінюємо.
Ми можемо без проблем перейменувати таблицю, створити нову структуру таблиць і сконвертувати дані між ними навіть у межах однієї версії, а клієнт цього навіть не помітить.
---
Знаючи, як зазвичай влаштовані білінгові системи провайдерів, можу сказати, що там база даних змінюється неймовірно рідко. І куди правильніше та надійніше використовувати такі варіанти:
Варіант 1, найправильніший
OneBox стукає у API billing'a та міняємо там що потрібно.
Якщо API немає - можна зробити цілком конкретні скрипти на php/perl/python/cgi, які прийматимуть GET/POST параметри і запускатимуть потрібний SQL.
Варіант 2
Є якийсь скрипт на стороні білінгу (або близько до нього), який стукається в API OneBox'a, отримує дані, потім SQL змінюється щось треба в білінгу.
Варіант 3
Перевести білінг на бік OneBox'a.
Я розумію, що ви на це зараз не погодитеся, але по суті навіть перша версія OneBox'a починалася з білінгу для інтернет-провайдера і OneBox безпосередньо вів тарифікацію і контролював raduis-сервера. . Ех, добрі часи були :)
---
Найкласніший варіант 1 - зробіть на своїй стороні мега-просте API, без авторизації (ну або IP restricted авторизацію), яке буде робити тільки необхідне додавання оновлення користувача.
Я розумію, що завдання не просте.
Дайте контакт технаря який пиляє білінг безпосередньо - і я її вирішу. Тільки технаря прямо, якщо там буде якийсь менеджер і він щось узгоджуватиме - ой все :)