Створення простих додатків баз даних для одного або невеликої групи користувачів.
Програма поширюється абсолютно безкоштовно.
База даних в хмарі. Установка Firebird на VDS.
У цій статті я розповім як налаштувати ОС Ubuntu 16.04 і Firebird 2.5 Classic, щоб користувачі DataExpress могли отримати доступ до бази, що знаходиться на VDS. Чесно кажучи, я сам недавно став цікавитися цим питанням, та й з Linux мало знаком. Але погуглити в інтернеті, зміг по крупицях добути потрібну інформацію. І ось тепер хочу поділитися цією інформацією з вами. Я не буду особливо роз'яснювати призначення команд, головне - це в точності повторити всі дії. Детальну інформацію по командам ви можете знайти в інтернеті. Також я не буду розповідати про те, який VDS хостинг краще вибрати і як створювати VDS. Цю інформацію ви знайдете на VDS хостингу. Для проби можна вибрати найдешевший варіант. Далі передбачається, що ви вже знайшли потрібний VDS хостинг і встановили ОС Ubuntu 16.04. Поїхали.
Для віддаленого управління сервером встановіть програму Putty.
Увійдіть в систему під користувачем "root". При введенні пароля курсор не рухається - так і повинно бути. Можна відразу змінити пароль користувача на відповідний. Для цього скористайтеся командою passwd. Система запропонує ввести новий пароль.
Перед установкою Firebird потрібно встановити демон inetd. Без нього отримати доступ до бази даних не вийде. Вводимо в командному рядку:
sudo apt-get install -y openbsd-inetd
Тепер встановлюємо Firebird:
sudo apt-get install -y firebird2.5-classic
В процесі установки потрібно буде задати пароль адміністратора SYSDBA. Конфігуріруем Firebird:
Запуститься програма настройки Firebird. Постане питання "Enable Firebird server?" (Включити сервер Firebird?). Дайте відповідь ствердно. Потім потрібно скинути пароль адміністратора SYSDBA. Якщо пароль відрізняється від стандартного (masterke), то при підключенні DataExpress до бази потрібно буде ввести цей пароль. З метою безпеки не рекомендується вводити стандартний пароль.
Відредагуємо файл inetd.conf:
Знаходимо рядок (повинна бути в кінці):
localhost: gds_db stream tcp.
Базова настройка Firebird готова. Тепер нам потрібно якось завантажити на сервер базу. Для цього можна скористатися програмою FileZilla. Але перед тим як налаштовувати FileZilla створимо користувача зі звичайними правами:
chmod 777 / home / user
Тепер користувачеві доступні операції читання / запису / виконання в цій папці. Налаштуємо нове з'єднання в FileZilla.
Після успішного завантаження бази повернемося до Putty. Ми як і раніше не отримаємо доступу до бази поки не поставимо необхідні права. При установці Firebird в системі був створений користувач "firebird", сервер баз даних працює від його імені. Щоб сервер БД зміг отримати доступ до нашого файлу бази, потрібно призначити його власником цього файлу.
chown firebird /home/user/DEMO_DB.FDB
Зверніть увагу, що в Linux регістр має значення.
Все готово для того, щоб ми могли підключитися до віддаленої базі. пробуємо:
Якщо при конфігуруванні Firebird ви ввели не стандартний пароль, то потрібно зняти прапорець "Пароль за замовчуванням" і ввести відповідний пароль.
Додаткові заходи безпеки
Якщо ви серйозно вирішили використовувати VDS для доступу до бази, то не зайвим буде прийняти деякі заходи безпеки. Почнемо з того, що приховуємо реальне розташування бази, створивши алиас. Знаходимо на сервері файл aliases.conf і редагуємо:
Пишемо в кінці файлу, наприклад:
Знаходимо вже знайому нам рядок "0.0.0.0:gds_db." І міняємо "gds_db" на потрібний порт, наприклад 3051. Зберігаємо зміни.
Тепер налаштуємо файрвол ufw. Вводимо в командному рядку послідовно:
ufw enable
ufw allow 22
ufw allow 3051
Перша команда включає файрвол. За замовчуванням файрвол нічого не пропускає. Друга команда відкриває порт 22 для віддаленого управління сервером через програму Putty. Третя команда відкриває порт 3051, який нам потрібен для зв'язку з сервером Firebird. Таким чином в системі відкрито тільки два порти: 22 і 3051. Перезавантажуємо сервер. Пробуємо підключитися.
Налаштування резервного копіювання
#! / Sbin / bash
filename = `date +% y% m ._% H% M% S_mybase`
gbak -b -g /home/user/mybase.fdb /home/user/backups/$filename.fbk -v -y /home/user/backups/$filename.log -user SYSDBA -pass masterkey
Запустіть скрипт і переконайтеся, що резервна копія створюється:
/home/user/backup.sh
ls / home / user / backups
Додамо в цей файл рядок:
0 12 * * * root. /home/user/backup.sh
Вона позначає запускати наш скрипт кожен день о 12:00. Зберігаємо зміни. І на цьому наша настройка закінчується. Непогано було б додати автоматичне видалення старих резервних копій. Якщо хто поділиться скриптом, із задоволенням додам в матеріал.
Ну і пару рядків як можна відновити базу з резервної копії:
mv /home/user/mybase.fdb /home/user/oldbase.fdb
gbak -c /home/user/backups/mybase.fbk /home/user/mybase.fdb -user SYSDBA -pass masterkey
Перед відновленням переконайтеся, що до бази немає підключень. Не можна виконувати відновлення з резервної копії на поточну базу. Тому перейменовуємо файл бази, а потім запускаємо команду. В процесі з резервної копії буде створена нова база даних. Якщо відновлення було успішно, стару базу можна видалити.
Налаштування KeepAlive
У разі обриву з'єднання інформація про нього може як і раніше зберігатися в базі. Через це деякі користувачі не зможуть увійти в базу або змінити деякі записи, т. К. Вони можуть бути заблоковані. Ми можемо налаштувати систему таким чином, щоб наявність з'єднань перевірялося системою з певною періодичністю. Це дозволить Firebird закривати обірвані з'єднання. Параметри KeepAlive встановлюються в файлі sysctl.conf:
Додамо в файл наступні рядки:
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 2
Перший параметр вказує системі починати перевірку з'єднання через 60 секунд. Якщо клієнт не відповів, то повторити спробу через 30 секунд (другий параметр). Всього спроб 2 (третій параметр). Після другої спроби система чекає ще 30 секунд (другий параметр) і закриває з'єднання. Час закриття з'єднання розраховується за формулою time + (probes + 1) * intvl. У нашому прикладі до закриття з'єднання пройде приблизно: 60 + (2 + 1) * 30 = 150 секунд.
Оптимізація бази DataExpress
Швидкість передачі даних в мережі Інтернет значно нижче, ніж в локальній мережі. Якщо до цього ви працювали з базою в локальній мережі, а потім перейшли в Інтернет, то ви відразу помітите затримки.
1. Насамперед потрібно зменшити розмір текстових полів до необхідного мінімуму. Якщо ви міняєте розмір полів в уже робочої базі, то після зміни розміру полів зробіть процедуру резервного копіювання / відновлення, щоб стиснути базу і очистити її від сміття. Також не міняйте розмір великій кількості полів, т. К. Це може привести до дуже довгому збереженню змін. При зміні розміру поля DataExpress насправді створює нове поле і копіює вміст старого поля в нове, старе поле після цього знищується. Тому розмір бази після такої операції не зменшується, а навпаки збільшується.
2. Намагайтеся уникати інтенсивного використання функцій DB в виразах і обчислюваних полях запитів.
3. При відкритті форми, програма читає дані всіх полів, в тому числі зображення та файли, що зберігаються в базі (мініатюри зображень завжди зберігаються в базі). Якщо зображення і файли зберігаються в базі, то це може привести до значного уповільнення читання даних з бази. У цьому випадку має сенс створювати просту форму і запит для вибірки даних з потрібної форми, або використовувати звіт.
4. Читання підлеглих даних форми (таблиць і запитів) теж може сильно уповільнювати роботу. У цьому випадку теж має сенс створювати просту форма + запит або використовувати звіт.