HeiseForenWiki:Datenrekonstruktion - Versionsgeschichte

Lgkf: Versionsabhängigkeiten

2005-10-06T06:51:23Z

Versionsabhängigkeiten

← Nächstältere Version		Version vom 6. Oktober 2005, 08:51 Uhr
Zeile 2:		Zeile 2:
	Ausserdem sollten die Spameinträge automatisch beseitigt werden.<br>		Ausserdem sollten die Spameinträge automatisch beseitigt werden.<br>
	Dazu wurde ein [[SQL]]-Script erstellt, dass diese Schritte ausführt, auch um die Änderungen nachvollziehbar zu machen.<br>		Dazu wurde ein [[SQL]]-Script erstellt, dass diese Schritte ausführt, auch um die Änderungen nachvollziehbar zu machen.<br>
			Alle Schritte wurden auf einem System mit MySQL 4.1.11 ausgeführt - manche dieser Befehle sind in früheren Versionen des MySQL Servers so nicht lauffähig, speziell das 'delete...where xy in (select...)' geht auf 3er Versionen nicht.<br>
	Zuerst wurde festgelegt, dass alle Einträge ab dem 26.9.05 23:00:00 zu verwerfen waren. Es mag sein, dass einzelne Änderungen nach diesem Datum nicht von Bots oder Spammern stammen und eigentlich gutgemeint waren; es wurde aber darauf verzichtet, das genauer aufzudröseln.<br>		Zuerst wurde festgelegt, dass alle Einträge ab dem 26.9.05 23:00:00 zu verwerfen waren. Es mag sein, dass einzelne Änderungen nach diesem Datum nicht von Bots oder Spammern stammen und eigentlich gutgemeint waren; es wurde aber darauf verzichtet, das genauer aufzudröseln.<br>
	<br>		<br>
	Aus dieser Festlegung lässt sich daher die Liste der Spam-Einträge wie folgt erstellen:<br>		Aus dieser Festlegung lässt sich daher die Liste der Spam-Einträge wie folgt erstellen:<br>
	<pre>		<pre>
	create table spamed_pages as select old_title as title, old_namespace as ns,		create table spamed_pages select old_title as title, old_namespace as ns,
	count(old_title) as n_attacks,cur_id as spamed_id		count(old_title) as n_attacks,cur_id as spamed_id
	from old join cur on old_title = cur_title		from old join cur on old_title = cur_title

Lgkf: 'as' raus, Versionsabhängigkeiten

2005-10-06T06:43:51Z

'as' raus, Versionsabhängigkeiten

← Nächstältere Version		Version vom 6. Oktober 2005, 08:43 Uhr
Zeile 79:		Zeile 79:
	Jedenfalls braucht man zusätzlich zu den Informationen aus der Lists der gespamten Seiten noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke speichert. Dazu wird zuerst ermittelt, welcher Eintrag den neuesten Zeitstempel trägt, der vor der deadline liegt:		Jedenfalls braucht man zusätzlich zu den Informationen aus der Lists der gespamten Seiten noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke speichert. Dazu wird zuerst ermittelt, welcher Eintrag den neuesten Zeitstempel trägt, der vor der deadline liegt:
	<pre>		<pre>
	create table to_replace as select max(old_timestamp) as good_time, old_title as title,		create table to_replace select max(old_timestamp) as good_time, old_title as title,
	ns, n_attacks, spamed_id		ns, n_attacks, spamed_id
	from old join spamed_pages on old_title = title		from old join spamed_pages on old_title = title
Zeile 137:		Zeile 137:
	delete from cur where cur_id in (select spamed_id from to_replace);		delete from cur where cur_id in (select spamed_id from to_replace);
	</pre>		</pre>
			(ob dieses delete from ... where <key> in (select...) funktioniert, hängt von der verwendeten Version ab. getestet wurde das mit mysql 4.1.11)
	gleich gefolgt vom Insert aus der schon vorbereiteten newcur:		gleich gefolgt vom Insert aus der schon vorbereiteten newcur:
	<pre>		<pre>
Zeile 149:		Zeile 150:
	delete from old where old_id in (select lg_id from to_replace);		delete from old where old_id in (select lg_id from to_replace);
	</pre>		</pre>
			(geht so erst ab Version 4.1.xx)
	Ohne diesen letzten Schritt würde die Liste der letzten Änderungen nicht richtig funktionieren.		Ohne diesen letzten Schritt würde die Liste der letzten Änderungen nicht richtig funktionieren.

Lgkf: nachgearbeitet

2005-10-04T10:40:03Z

nachgearbeitet

← Nächstältere Version		Version vom 4. Oktober 2005, 12:40 Uhr
Zeile 37:		Zeile 37:
	+------------------------------------+----+-----------+-----------+		+------------------------------------+----+-----------+-----------+
	</pre>		</pre>
	Eine Komplikation ergibt sich daraus, dass in [http://meta.wikimedia.org/wiki/Help:Database_layout MediaWiki] die Tabellen für die aktuelle Version eines Artikels und die archivierten Fassungen vorhergehender Versionen in 2 unterschiedlichen Tabellen ~~abgelegt sind~~. Vermutlich ist dies aus Gründen der Performace so angelegt. Die jeweiligen Tabellen haben diese Felder:		Eine Komplikation ergibt sich daraus, dass in [http://meta.wikimedia.org/wiki/Help:Database_layout MediaWiki] die Tabellen für die aktuelle Version eines Artikels und die archivierten Fassungen vorhergehender Versionen in 2 unterschiedlichen Tabellen stehen. Vermutlich ist dies aus Gründen der Performace so angelegt. Die jeweiligen Tabellen haben diese Felder:
	<pre>		<pre>
	mysql> describe old;		mysql> describe old;
Zeile 77:		Zeile 77:
	+-------------------+---------------------+------+-----+---------+----------------+		+-------------------+---------------------+------+-----+---------+----------------+
	</pre>		</pre>
	Jedenfalls braucht man zusätzlich zu den Informationen aus der Lists der gespamten Seiten noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke speichert:		Jedenfalls braucht man zusätzlich zu den Informationen aus der Lists der gespamten Seiten noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke speichert. Dazu wird zuerst ermittelt, welcher Eintrag den neuesten Zeitstempel trägt, der vor der deadline liegt:
	<pre>		<pre>
	create table to_replace as select max(old_timestamp) as good_time, old_title as title,		create table to_replace as select max(old_timestamp) as good_time, old_title as title,
Zeile 85:		Zeile 85:
	group by old_title;		group by old_title;
	</pre>		</pre>
	~~leider lässt sich so~~ noch ~~nicht~~ die old_id ~~des~~ letzten guten Eintrags aus der old herausfinden, die wird ~~jetzt noch zuerst~~ als Spalte (lg_id) hinzugefügt und dann anhand der bereits bekannten 'good_time' eingetragen:		Jetzt kann man noch die old_id dieses letzten guten Eintrags aus der old herausfinden, die wird zunächst als Spalte 'lg_id' hinzugefügt und dann anhand der bereits bekannten 'good_time' eingetragen:
	<pre>		<pre>
	alter table to_replace add lg_id integer;		alter table to_replace add lg_id integer;
Zeile 118:		Zeile 118:
	+----------------+------------------------------------+----+-----------+-----------+-------+		+----------------+------------------------------------+----+-----------+-----------+-------+
	</pre>		</pre>
	~~jetzt~~ ist das Gröbste geschafft ~~- weil~~ sich leider updates mit mehreren Feldern direkt in [[SQL]] eigentlich nicht vernünftig erstellen lassen - in [[PostGres]] ist das über eine eingebaute [Skriptsprache ~~Scriptsprache~~] einfacher - wird zunächst eine Tabelle erzeugt, die die beabsichtigten Änderungen schon enthält:		Jetzt ist das Gröbste geschafft, die Informationen, was wodurch zu ersetzen ist, sind ermittelt.<br>
			Weil sich leider updates mit mehreren Feldern direkt in [[SQL]] eigentlich nicht vernünftig erstellen lassen - in [[PostGres]] ist das über eine eingebaute [[Skriptsprache]] einfacher - wird zunächst eine Tabelle erzeugt, die die beabsichtigten Änderungen schon enthält:
	<pre>		<pre>
	create table newcur as select cur_id, cur_namespace, cur_title, old_text as cur_text,		create table newcur as select cur_id, cur_namespace, cur_title, old_text as cur_text,

Lgkf am 4. Oktober 2005 um 00:53 Uhr

2005-10-04T00:53:50Z

← Nächstältere Version		Version vom 4. Oktober 2005, 02:53 Uhr
Zeile 37:		Zeile 37:
	+------------------------------------+----+-----------+-----------+		+------------------------------------+----+-----------+-----------+
	</pre>		</pre>
	Eine Komplikation ergibt sich daraus, dass in [http://meta.wikimedia.org/wiki/Help:Database_layout MediaWiki] ~~sich~~ die Tabellen für die aktuelle Version eines Artikels und die archivierten Fassungen ~~vorhergender~~ Versionen in 2 unterschiedlichen Tabellen abgelegt sind. Vermutlich ist dies aus Gründen der Performace so angelegt. Die jeweiligen Tabellen haben diese Felder:		Eine Komplikation ergibt sich daraus, dass in [http://meta.wikimedia.org/wiki/Help:Database_layout MediaWiki] die Tabellen für die aktuelle Version eines Artikels und die archivierten Fassungen vorhergehender Versionen in 2 unterschiedlichen Tabellen abgelegt sind. Vermutlich ist dies aus Gründen der Performace so angelegt. Die jeweiligen Tabellen haben diese Felder:
	<pre>		<pre>
	mysql> describe old;		mysql> describe old;
Zeile 77:		Zeile 77:
	+-------------------+---------------------+------+-----+---------+----------------+		+-------------------+---------------------+------+-----+---------+----------------+
	</pre>		</pre>
	Jedenfalls braucht man zusätzlich su den Informationen aus der ~~Litse~~ der gespamten Seiten noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke speichert:		Jedenfalls braucht man zusätzlich zu den Informationen aus der Lists der gespamten Seiten noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke speichert:
	<pre>		<pre>
	create table to_replace as select max(old_timestamp) as good_time, old_title as title,		create table to_replace as select max(old_timestamp) as good_time, old_title as title,
Zeile 118:		Zeile 118:
	+----------------+------------------------------------+----+-----------+-----------+-------+		+----------------+------------------------------------+----+-----------+-----------+-------+
	</pre>		</pre>
	jetzt ist das ~~gröbste~~ geschafft - weil sich leider updates mit mehreren Feldern direkt in [[SQL]] eigentlich nicht vernünftig erstellen lassen - in [[PostGres]] ist das über eine eingebaute Scriptsprache einfacher - wird zunächst eine Tabelle erzeugt, die die beabsichtigten Änderungen schon enthält:		jetzt ist das Gröbste geschafft - weil sich leider updates mit mehreren Feldern direkt in [[SQL]] eigentlich nicht vernünftig erstellen lassen - in [[PostGres]] ist das über eine eingebaute [Skriptsprache Scriptsprache] einfacher - wird zunächst eine Tabelle erzeugt, die die beabsichtigten Änderungen schon enthält:
	<pre>		<pre>
	create table newcur as select cur_id, cur_namespace, cur_title, old_text as cur_text,		create table newcur as select cur_id, cur_namespace, cur_title, old_text as cur_text,

Lgkf am 4. Oktober 2005 um 00:48 Uhr

2005-10-04T00:48:40Z

@@ Zeile 37: / Zeile 37: @@
 +------------------------------------+----+-----------+-----------+
 </pre>
+Eine Komplikation ergibt sich daraus, dass in [http://meta.wikimedia.org/wiki/Help:Database_layout  MediaWiki] sich die Tabellen für die aktuelle Version eines Artikels und die archivierten Fassungen vorhergender Versionen in 2 unterschiedlichen Tabellen abgelegt sind. Vermutlich ist dies aus Gründen der Performace so angelegt. Die jeweiligen Tabellen haben diese Felder:
-jetzt braucht man noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke hat:
+<pre>
 <pre>
 create table to_replace as select max(old_timestamp) as good_time, old_title as title,
@@ Zeile 109: / Zeile 148: @@
 delete from old where old_id in (select lg_id from to_replace);
 </pre>
-Ohne diesen letzten Schritt würde die Liste der letzten Änderungen nicht richti funktionieren.
+Ohne diesen letzten Schritt würde die Liste der letzten Änderungen nicht richtig funktionieren.
 alles ganz einfach eigentlich...

Lgkf am 3. Oktober 2005 um 23:50 Uhr

2005-10-03T23:50:37Z

Neue Seite

Durch den Verlust von Verwaltungsinformationen bei der [[HeiseForenWiki:Downtime]] war die Kombination eines Backups des Wiki in einer 1.3er Version mit Daten aus der Version 1.4.5 erforderlich. 
Ausserdem sollten die Spameinträge automatisch beseitigt werden. 
Dazu wurde ein [[SQL]]-Script erstellt, dass diese Schritte ausführt, auch um die Änderungen nachvollziehbar zu machen. 
Zuerst wurde festgelegt, dass alle Einträge ab dem 26.9.05 23:00:00 zu verwerfen waren. Es mag sein, dass einzelne Änderungen nach diesem Datum nicht von Bots oder Spammern stammen und eigentlich gutgemeint waren; es wurde aber darauf verzichtet, das genauer aufzudröseln. 
 
Aus dieser Festlegung lässt sich daher die Liste der Spam-Einträge wie folgt erstellen: 
<pre>
create table spamed_pages as select old_title as title, old_namespace as ns,
count(old_title) as n_attacks,cur_id as spamed_id
from old join cur on old_title = cur_title
where cur_namespace = old_namespace and old_timestamp > 20050926230000 group by old_title, old_namespace;
</pre>
Das ergab folgende Liste:
<pre>
+------------------------------------+----+-----------+-----------+
| title | ns | n_attacks | spamed_id |
+------------------------------------+----+-----------+-----------+
| Anmeldung | 4 | 79 | 700 |
| Editierhilfe | 4 | 30 | 656 |
| Erste_Schritte | 4 | 37 | 659 |
| GNU_Freie_Dokumentationslizenz | 0 | 45 | 694 |
| Gut | 0 | 20 | 1401 |
| Hauptseite | 1 | 51 | 941 |
| Hilfe | 4 | 42 | 657 |
| Hommingberger_Gepardenforelle | 0 | 56 | 1381 |
| Inhalt:Allgemein_Forenspezifisches | 0 | 20 | 696 |
| Inhalt:Allgemeines | 0 | 21 | 695 |
| Inhalt:Heise-Forenspezifisches | 0 | 21 | 697 |
| Inhalt:Technisches | 0 | 17 | 698 |
| Jm | 2 | 23 | 1023 |
| Lizenzbestimmungen | 4 | 20 | 1688 |
| Mediawiki_145 | 4 | 16 | 1648 |
| Newbie | 0 | 39 | 623 |
| Wikipedia | 0 | 44 | 699 |
| Wunschliste | 4 | 22 | 690 |
| Über_HeiseForenWiki | 5 | 34 | 691 |
+------------------------------------+----+-----------+-----------+
</pre>

jetzt braucht man noch die id desjenigen Eintrags aus der Tabelle old, der den letzten gültigen Eintrag vor der Spamattacke hat:
<pre>
create table to_replace as select max(old_timestamp) as good_time, old_title as title,
ns, n_attacks, spamed_id
from old join spamed_pages on old_title = title
where old_namespace = ns and old_timestamp < 20050926230000
group by old_title;
</pre>
leider lässt sich so noch nicht die old_id des letzten guten Eintrags aus der old herausfinden, die wird jetzt noch zuerst als Spalte (lg_id) hinzugefügt und dann anhand der bereits bekannten 'good_time' eingetragen:
<pre>
alter table to_replace add lg_id integer;

update to_replace set lg_id =
(select old_id from old where old_timestamp = good_time and old_title = title and old_namespace = ns);
</pre>
sodass sich insgesamt diese Liste ergibt:
<pre>
+----------------+------------------------------------+----+-----------+-----------+-------+
| good_time | title | ns | n_attacks | spamed_id | lg_id |
+----------------+------------------------------------+----+-----------+-----------+-------+
| 20040311184023 | Anmeldung | 4 | 79 | 700 | 6741 |
| 20050416182413 | Editierhilfe | 4 | 30 | 656 | 6740 |
| 20041219104846 | Erste_Schritte | 4 | 37 | 659 | 6732 |
| 20050624000344 | GNU_Freie_Dokumentationslizenz | 0 | 45 | 694 | 6731 |
| 20050701163645 | Gut | 0 | 20 | 1401 | 6762 |
| 20050401162822 | Hauptseite | 1 | 51 | 941 | 6739 |
| 20040409055542 | Hilfe | 4 | 42 | 657 | 6735 |
| 20050701091623 | Hommingberger_Gepardenforelle | 0 | 56 | 1381 | 6734 |
| 20050825093256 | Inhalt:Allgemein_Forenspezifisches | 0 | 20 | 696 | 6759 |
| 20040921202718 | Inhalt:Allgemeines | 0 | 21 | 695 | 6756 |
| 20050831144546 | Inhalt:Heise-Forenspezifisches | 0 | 21 | 697 | 6730 |
| 20040531214350 | Inhalt:Technisches | 0 | 17 | 698 | 6749 |
| 20050719121959 | Jm | 2 | 23 | 1023 | 6745 |
| 20050826160145 | Lizenzbestimmungen | 4 | 20 | 1688 | 6755 |
| 20050705214127 | Mediawiki_145 | 4 | 16 | 1648 | 6747 |
| 20040813120217 | Newbie | 0 | 39 | 623 | 6733 |
| 20050624000100 | Wikipedia | 0 | 44 | 699 | 6746 |
| 20050826234332 | Wunschliste | 4 | 22 | 690 | 6750 |
| 20040608234835 | Über_HeiseForenWiki | 5 | 34 | 691 | 6737 |
+----------------+------------------------------------+----+-----------+-----------+-------+
</pre>
jetzt ist das gröbste geschafft - weil sich leider updates mit mehreren Feldern direkt in [[SQL]] eigentlich nicht vernünftig erstellen lassen - in [[PostGres]] ist das über eine eingebaute Scriptsprache einfacher - wird zunächst eine Tabelle erzeugt, die die beabsichtigten Änderungen schon enthält:
<pre>
create table newcur as select cur_id, cur_namespace, cur_title, old_text as cur_text,
old_comment as cur_comment, old_user as cur_user, old_user_text as cur_user_text,
old_timestamp as cur_timestamp, cur_restrictions, cur_counter, cur_is_redirect,
old_minor_edit as cur_minor_edit, cur_is_new, cur_random,
20051003120000 as cur_touched, 99999999999999 - old_timestamp as inverse_timestamp
from to_replace
join cur on spamed_id = cur_id
join old on lg_id = old_id;
</pre>
Die Ausgabe dieser Tabelle sparen wir uns, weil es wortwörtlich den Rahmen sprengen würde ;). 
 
Die geplanten Löschungen werden jetzt in der Tabelle cur2delete gesichert, und dann gleich auch durchgeführt:
<pre>
create table cur2delete as select * from cur where cur_id in (select spamed_id from to_replace);
delete from cur where cur_id in (select spamed_id from to_replace);
</pre>
gleich gefolgt vom Insert aus der schon vorbereiteten newcur:
<pre>
insert into cur select * from newcur;
</pre>
jetzt werden noch die gespammten Einträge aus der old weggeschmissen, als Kriterium einfach der Zeitstempel:
<pre>
delete from old where old_timestamp > 20050926230000;
</pre>
was bleibt ist noch, die Einträge aus der old zu löschen, die jetzt bereits in der cur stehen:
<pre>
delete from old where old_id in (select lg_id from to_replace);
</pre>
Ohne diesen letzten Schritt würde die Liste der letzten Änderungen nicht richti funktionieren.

alles ganz einfach eigentlich...