Обновление Sonarqube от 4.5 до 4.5.1 не будет работать

Question

Я пытаюсь обновить Sonarqube от 4.5 до 4.5.1 на Ubuntu 14.04 64 бит. Менеджер пакетов обслуживает новую версию, и она установлена, по-видимому, без проблем. Однако, когда я пытаюсь получить доступ к веб-интерфейсу, он выводит меня на страницу, где говорится, что мне нужно обновить базу данных. Поэтому я перехожу на страницу my_sonar_server/setup и нажмите «Обновить». Через несколько секунд появится следующее сообщение

Восклицательных Невозможно обновление базы данных

Сбой переноса: произошла ошибка, все последующие миграции отменены: ActiveRecord :: ConnectionNotEstablished: нет доступных соединений: изменять табличное snapshot_sources изменять данные длинный текст. Пожалуйста, проверьте журналы.

sonar.log имеет следующее исключение

2014.11.10 10:04:38 ИНФО веб [DbMigration] MysqlMediumtextToLongtext: мигрирующей

2014.11.10 10:04:42 ERROR Интернет [ossui.JRubyFacade] Не удалось обновить базу данных Произошла ошибка, все последующие миграции отменены:

ActiveRecord :: ConnectionNotEstablished: не доступно подключение: изменить таблица snapshot_sources изменить данные longt ext /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract_adapter.rb:227:in log' /opt/sonar/web/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/jdbc/adapter.rb:183:in выполнить ' /opt/sonar/web/WEB- INF/дб/мигрирует/600_mysql_mediumtext_to_longtext.rb: 42: в apply' /opt/sonar/web/WEB-INF/db/migrate/600_mysql_mediumtext_to_longtext.rb:30:in до ' орг/JRuby/RubyKernel.java: 2223: в send' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:282:in мигрируют' баночка: файл/Opt/сонар/Библиотека/сервер/JRuby-complete- 1.7.9.jar /META-INF/jruby.home/lib/ruby/1.8/benchmark.rb: 293: в measure' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:282:in мигрируют ' орг/JRuby/RubyKernel.java: 2227: в send' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:365:in мигрируют' /непринятия /sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:491:in migrate' org/jruby/RubyProc.java:290:in call ' org/jruby/RubyProc.java: 224: in call' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:567:in ddl_transaction' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:490: в migrate' org/jruby/RubyArray.java:1613:in каждый ' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:477:in migrate' /opt/sonar/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:401:in вверх' /Opt/сонар/веб/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb: 383: in migrate' /opt/sonar/web/WEB-INF/lib/database_version.rb:62:in upgrade_and_start ' /opt/sonar/web/WEB-INF/app/models/database_migration_manager.rb:109 : in start_migration' org/jruby/RubyProc.java:290:in call ' org/jruby/RubyProc.java: 228: in `call'

Любая помощь здесь была бы высоко оценена!

Благодаря

Answer 1

Журнал достаточно четко: ConnectionNotEstablished. Это означает, что вы неправильно настроили свой экземпляр SonarQube для доступа к базе данных ...

Answer 2

Проблема в том, что в какой-то момент одна из таблиц (snapshot_sources) была повреждена, предположительно, когда мы клонировали наш производственный сервер, чтобы иметь тестовый сервер.

Когда я попытался получить доступ к определенной строке в этой конкретной таблице либо через phpmyadmin, либо в командной строке, соединение с базой данных было потеряно (процесс mysqld был перезагружен). Я исследовал корень проблемы (выкапывая /var/log/mysql/error.log) вместе с нашей ИТ-командой и достиг вышеупомянутого вывода.

Таким образом, миграция базы данных была прервана из-за этого, из-за того, что миграция пытается изменить snapshot_sources таблицы для преобразования data поля из mediumtext в longtext

так, как я установил это было :

1. Экспорт производство DB (с truncate предложений по откачке таблицы перед импортом)
2. резервного копирования искаженного DB для дальнейшего расследования в случае необходимости
3. Импорт производство DB на тестовом сервере
4. Обновление SQ от 4.5 до 4.5.1

Надеюсь, что это помогает кто-то другой или, по крайней мере, это своего рода руководителей для команды сонара.