Назад | Перейти на главную страницу

Tokyo Tyrant ulog / управление журналом обновлений

Я тестирую Tokyo Tyrant в режиме мастер-мастер и обнаружил, что ulog выходит из-под контроля и блокирует диск.

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

Я полагаю, я напишу сценарий оболочки, который удалит улоги старше X, как только я выясню, сколько времени назад требуется Tokyo Tyrant в журнале обновлений, чтобы выполнить аварийное переключение.

У кого-нибудь есть опыт работы с этим токийским тираном? Есть ли у вас ощущение (признание того, что каждая установка отличается в зависимости от того, что хранится) для оптимального размера ulog по сравнению с тем, как далеко назад экземпляр Tokyo Tyrant должен заглянуть в ulog, чтобы получить статус мастера?

Спасибо натан

К вашему сведению, я написал сценарий управления ulog, который учитывает задержку репликации:

http://conigliaro.org/2010/04/28/tokyo-tyrant-update-log-ulog-management/

Чтобы продолжить, ниже представлен ответ Микио Хирабаяши (разработчик TT) на аналогичное электронное письмо:

Если вы можете подтвердить, что только одно ведомое устройство, которое является другой частью двойного ведущего устройства, получает доступ к ведущему серверу, запросите время задержки ведомого устройства с помощью команды «tcrmgr inform -st ...», и вы можете определить, какой файл можно удалить .

Выполнение этой команды позволит вам увидеть, как далеко ведомое устройство отстает от ведущего. Как только вы узнаете, что можете потратить некоторое время на поиск правильного размера оборота ulog и вернуть много файлов ulog, вы можете выбросить мусор и чувствовать себя в безопасности. Вероятно, лучше всего делать это под нагрузкой, которая имитирует тяжелый день в ваших базах данных ключей / значений Tokyo Tyrant и т. Д.

Я бессовестно сорвал скрипт из stackoverflow:

> #!/bin/bash
> 
> # Deletes all but the newest 5 files to keep Tokyo Tyrant ulogs from
> killing the disk.
> logdir='/path/to/ttserver/ulog/' 
> mydir=`ls -t $logdir` it=1
> 
> for file in $mydir
>     do
>         if [ $it -gt 5 ]
>         then
>             echo file $it will be deleted: $logdir$file
>             #rm -rf $file
>         fi
>         it=$((it+1))
>     done

Ответ @kubanskamac был абстрактным правильным, но Микио дает команду начать оптимизацию.

Отказ от ответственности: я впервые слышу о Tokyo Tyrant. Я просто вижу несколько знакомых шаблонов, просматривая документы.

Я знаю, что в транзакционных системах (например, базах данных) внимание уделяется двум типам неожиданных событий:

  • сбой питания - когда вы по какой-то причине теряете содержимое кеш-памяти RAM, но после перезагрузки вы все еще можете получить доступ к файлам на диске
  • сбой диска - вы больше не можете получить доступ к данным из файлов на диске; файлы потеряны или содержат только мусор; вам нужно восстановить из резервной копии

Каждое бревно обычно проходит три стадии существования:

  1. Активный журнал это было только что создано с очень свежими транзакциями; содержащиеся в нем данные еще не были сохранены в файлы данных; это абсолютно необходимо для восстановления целостности файлов данных в случае сбоя питания
  2. После фиксации данных (записи в файлы базы данных) журнал теперь называется совершенный журнал; данные находятся на диске в двух разных форматах / местах - в этом журнале и в файле базы данных; вам не нужен этот журнал в случае сбоя питания, но он вам понадобится в случае сбоя диска - после восстановления файла базы данных (с предыдущей недели?) вы можете повторно применить все транзакции из последовательных зафиксированных + активных журналов в том же хронологическом порядке последовательность получения свежей копии данных; если вы потеряли последние журналы, вы потеряли последние транзакции, но, по крайней мере, у вас все еще есть довольно свежая и полностью согласованная база данных
  3. После резервного копирования файла базы данных (последовательного копирования в безопасное место) ваш журнал становится архивный журнал. Он не нужен для защиты от любого отказа.

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