Questions & Answers

[khounlivong]

Für unsere Entwicklungs- und Testumgebung importieren wir periodisch das Live-Projekt.

Was wir schon wissen:

1. Beim Vollbackup werden sämtliche Revisionen sauber importiert. Wir haben noch keine Tests gemacht, die lediglich die letzte Revision importiert, unser Developer-System ging bei der Berechnung der Abhängigkeiten in die Kniee, wohl auch weil die angebundene DB mager konfiguriert war (innodb_buffer_pool_size).
2. Datenbank-Inhalte sind im Backup/Export enthalten, wenn das Häkchen gesetzt ist und benötigen die leeren Datenbanken. Dazu wurde ein generisches Skript gebastelt, welches Nutzer und Datanbanken beibehält und lediglich alle Tabellen löscht.
3. Die groups.xml ist der einzige Teil der nicht im Export enthalten ist, vorausgesetzt alle Module stimmen LIVE und STAGING (unser Developer-Umgeung) überein.

Was stört:

• es sind Reste des letzten Imports vorhanden, Beispiel (ID=1647696):

  [root@cms firstspirit5]# ls web/ -1
  fs5preview
  fs5preview_1956946
  fs5root
  fs5staging
  fs5staging_1956946
  fs5webedit
  fs5webedit_1647696
  fs5webedit_1956946
  fs5webmon
  

  Wie kriegt man die weg? Bloßes Löschen im Filesystem ist irgenwie uncool, Restart der Web-Applikationen, Server-Aufräumen, Restart hat nicht geholfen.
• es sind noch DB-Access-Definitonen vorhanden, welche von uralt-Umgebungen stammen und auf Server referenzieren, die nicht mehr vorhanden sind. Unsere Vermutung, daß alte DB-Schemata dafür vernatwortlich sind, jedoch sind diese nicht mehr vorhanden oder sichtbar. Diese Dinger erscheinen immer wieder, in:

  ./data/projects/project_541471/webapps/webedit/FIRSTpersonalisation.FIRSTpersonalisation/schemata.xml
  ./web/fs5webedit_272180/WEB-INF/schemata.xml
  ./web/fs5webedit_541471/WEB-INF/schemata.xml
  

• auch auf Live. Lt. unserem Betreuer ist das ein Bug:

  <schemaConfiguration default="users_ext">
          <schema uid="ds_ext" schema="ds_ext" caching="false" release="false" syncschema="false" customSettings="false" xsd="/WEB-INF/ds_ext.schema.xsd">
                  <param name="module" value="MySQL51" />
                  <param name="jdbc.CONNECTIONRETRY" value="5" />
                  <param name="jdbc.POOLMAX" value="120" />
                  <param name="jdbc.SCHEMA" value="fs_ds" />
                  <param name="jdbc.POOLTIMEOUT" value="240" />
                  <param name="jdbc.POOLMIN" value="40" />
                  <param name="jdbc.CONNECTIONRETRYCYCLE" value="1000" />
                  <param name="jdbc.DRIVER" value="com.mysql.jdbc.Driver" />
                  <param name="jdbc.CONNECTIONTIMEOUT" value="3600" />
                  <param name="jdbc.layerclass" value="de.espirit.or.impl.mysql.MySQLLayer" />
                  <param name="jdbc.USER" value="fs_ds" />
                  <param name="jdbc.POOLCYCLE" value="180" />
                  <param name="jdbc.URL" value="jdbc:mysql://database:3306/fs_ds" />
                  <param name="jdbc.PASSWORD" value="********" />
          </schema>
          <schema uid="users_ext" schema="users_ext" caching="false" release="false" syncschema="false" customSettings="false" xsd="/WEB-INF/users_ext.schema.xsd">
                  <param name="jdbc.SCHEMA" value="fs_ds" />
                  <param name="jdbc.layerclass" value="de.espirit.or.impl.mysql.MySQLLayer" />
                  <param name="jdbc.USER" value="fs_ds" />
                  <param name="jdbc.DRIVER" value="com.mysql.jdbc.Driver" />
                  <param name="jdbc.URL" value="jdbc:mysql://**.***.**.83:3306/fs_ds" />
                  <param name="jdbc.PASSWORD" value="********" />
          </schema>
  </schemaConfiguration>

  Der zweite Teil kommt immer wieder in die Konfig.

  Irgend eine Idee hierzu?

Zusätzliche Indizes

Wir wissen inzwischen, daß bei größeren Projekten mit externen Datenbanken und häufigen Abfragen zusätzliche Indizes notwendig sind und haben nach dieser Erkenntnis weitere angelegt. Das hatten Performanzsteigerungen teilweise um den Faktor 10 zu Folge.

Leider wirft das insbesondere für ein mögliches Wiederherstellen Fragen auf.

Beim Import eines Projektes wird als erstes der Suchindex aufgebaut - und zwar ohne diese zusätzlichen, geschwindigkeitssteigernden Indizes. Zur Lösung wird nach einem Import der Server heruntergefahren, die Indizes erstellt und der Server dannach wieder hochgefahren.

Irgendeine andere Möglichkeit?

[kohlbrecher]

Hallo Khamsonh,

bei den "Resten" des letzen Imports handeltes sich teilweise um Standardverzeichnisse (die ohne Zahlen am Ende) die nicht gelöscht werden sollten. Handelt es sich um einen externen Tomcat, ist man selbst dafür die Verwaltung verantwortlich. Sollte es sich um den internen Jetty handeln, würde ich vorschlagen Kontakt mit unserem Helpdesk aufzunehmen. Gleiches trifft auf die DB-Schemata zu.

Bei den zusätzlichen Indizes ist es richtig, dass diese beim Import/Export berücksichtigt werden. Das Anlegen kann eventuell durch ein eigenes Skript erledigt werden. Ein Neustart sollte nicht notwendig sein. Alternativ packt man die Datenbankinhalte nicht in den Export und kopiert die Inhalte der Datenbank über normale Datenbankmittel.

Grüße

Jan

[MichaelaReydt]

Hallo Khamsonh,

benötigst Du noch weitere Hilfe oder hat dir Jans Antwort bereits geholfen?

In diesem Fall wäre es super, wenn Du sie entsprechend als "richtige Antwort" markierst, damit auch andere

Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung

gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Viele Grüße

Michaela