КАК ЭТО РАБОТАЕТ?

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

Изменения в библиотеке SQLite являются внутренними, и имеют такой же интерфейс.

Библиотеки LiteSync будут общаться друг с другом, обмениваясь данными транзакций.






КОПИРОВАНИЕ

Когда приложение открывается в первый раз, оно подключается к другому узлу и загружает свежую копию базы данных.

В централизованной топологии первичный узел отправит копию базы данных вторичным узлам.

После загрузки узел начинает синхронизацию.



СИНХРОНИЗАЦИЯ

Как только узлы имеют одинаковую базу данных, они обмениваются транзакциями, которые были выполнены, когда они находились в автономном режиме.

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

Если узел находится в автономном режиме, то транзакция сохраняется в локальном журнале для последующего обмена.



НУЖНО ЛИ МЕНЯТЬ КОД МОЕГО ПРИЛОЖЕНИЯ?

Есть несколько шагов, но в основном мы должны изменить строку URI в открытой базе данных здесь:

“file:/path/to/app.db”

Примерно вот так:

“file:/path/to/app.db?node=secondary&connect=tcp://server.ip:1234”

Хорошей новостью является то, что LiteSync использует собственный интерфейс SQLite3. Это означает, что нам не нужно использовать другой API.



ПОДКЛЮЧЕНИЕ

Каждый узел имеет 2 варианта:

привязка к адресу
подключение к адресу партнера

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



ПОДДЕРЖИВАЕМЫЕ ТОПОЛОГИИ


ЦЕНТРАЛИЗОВАННАЯ, ЗВЕЗДНАЯ ТОПОЛОГИЯ


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

Вот несколько примеров конфигураций:


Первичный узел может связываться с адресом, а вторичные узлы соединяются с ним.

Основной узел:

"file:/home/user/app.db?node=primary&bind=tcp://0.0.0.0:1234"

Вторичный узел: (на другом устройстве)

"file:/home/user/app.db?node=secondary&connect=tcp://server:1234"


Основной узел также может подключаться к вторичным узлам.

Основной узел:

"file:/home/user/app.db?node=primary&connect=tcp://address1:port1,tcp://address2:port2"

Вторичные узлы: (каждый на отдельном устройстве)

"file:/home/user/app.db?node=secondary&bind=tcp://0.0.0.0:1234"


Мы можем даже использовать смесь этих двух вариантов.

Основной узел::

"file:/home/user/app.db?node=primary&bind=tcp://0.0.0.0:1234&connect=tcp://address1:port1"

Вторичный Узел 1:

"file:/home/user/app.db?node=secondary&connect=tcp://server:1234"

Вторичный Узел 2:

"file:/home/user/app.db?node=secondary&bind=tcp://0.0.0.0:1234"



Одноранговая топология


Полностью подключенная одноранговая сеть создается между первичными узлами.

Нам нужно сообщить общее количество узлов в сети вручную на каждом узле (пока)

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

Вот пример сети с 3 узлами:

Узел 1:

"file:db1.db?node=primary&total_primary_nodes=3&bind=tcp://0.0.0.0:1201"

Узел 2:

"file:db2.db?node=primary&total_primary_nodes=3&bind=tcp://0.0.0.0:1202& connect=tcp://127.0.0.1:1201"

Узел 3:

"file:db3.db?node=primary&total_primary_nodes=3&bind=tcp://0.0.0.0:1203& connect=tcp://127.0.0.1:1201,tcp://127.0.0.1:1202"



Смешанная топология


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

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

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

Вот пример URI для вторичного узла:

"file:db4.db?node=secondary&connect=tcp://127.0.0.1:1201,tcp://127.0.0.1:1202,tcp://127.0.0.1:1203"



СТАТУС СИНХРОНИЗАЦИИ

Мы можем проверить состояние синхронизации с помощью этой команды:

PRAGMA sync_status

Возвращает строку JSON.



Уведомление о синхронизации

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

Выберите язык -->

Важно: функция уведомления вызывается рабочим потоком. Приложение НЕ должно использовать соединение с базой данных внутри функции уведомления, и оно должно возвращаться как можно быстрее! Приложение может передать уведомление в основной поток перед возвратом.



ПРОВЕРКА, ЕСЛИ БАЗА ДАННЫХ ГОТОВА

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

Мы можем получить статус синхронизации и проверить переменную db_is_ready

Проверьте основные примеры приложений ниже.



Как использовать это в моем приложении?

Есть 3 шага:

1  Замените библиотеку SQLite библиотекой, содержащей LiteSync.

2  Измените строку подключения URI

3  Проверьте состояние готовности БД

При компиляции приложений C и C ++ вы должны связать свое приложение с библиотекой LiteSync.

Для других языков вы должны иметь соответствующую установленную оболочку.



ПЕРВИЧНЫЙ ПРИМЕР УЗЛА

Первичный узел может быть обычным приложением, точно таким же, что и вторичные узлы, но с другим URI.

Или мы можем использовать приложение, предназначенное для основного узла.

Базовое автономное приложение, используемое исключительно для сохранения централизованного узла БД, будет выглядеть так:

Выберите язык -->



ПРИМЕР ОСНОВНОГО ПРИЛОЖЕНИЯ

Базовое приложение, которое пишет в локальную базу данных, будет выглядеть так:

Выберите язык -->



ТЕКУЩИЕ ОГРАНИЧЕНИЯ

1  Избегайте использования функций, которые возвращают разные значения при каждом вызове, например random() и date('now')

2  Ключевое слово AUTOINCREMENT не поддерживается

3  Мы должны использовать только одно соединение с каждым файлом базы данных. Не позволяйте нескольким приложениям обращаться к одному и тому же файлу базы данных. Каждый экземпляр должен использовать свой собственный файл базы данных, а затем они будут реплицироваться и синхронизироваться с помощью LiteSync.