mikrocontroller.net

Forum: PC Hard- und Software Datenbank - Failsave gestalten?


Autor: Tom (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Hallo Leute!

Ich hab bei mir eine kleine Datenbank 200mb auf einem Server (SQL 
Express) in meinem kleinen Netz laufen. Läuft auch alles soweit sogut.


Nun bin ich aber manchmal nicht da und nur jemand mit wenig bis gar 
keiner Computer Erfahrung vor Ort. Gebe es ein Möglichkeit die Datenbank 
irgendwie auf einem zweiten physischen Server zu spiegeln und wenn der 
erste Ausfällt übernimmt der zweite?


Oder wie kriege ich das ganze Failsave?

Danke Gruß

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Backup reicht nicht?

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem NAS-System und Raid?

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Kann die APP immer gleich in zwei Datenbanken schreiben?

Autor: Tom (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hi,

ja ein NAS ist vorhanden. Mir geht es nicht darum das da was verloren 
geht sondern das ohne mich das niemand wiederherstellen kann.

Leider kann die APP das nicht.

Gruß

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom schrieb:
> irgendwie auf einem zweiten physischen Server zu spiegeln

Wenn Du nur spiegelst, kann der gleiche Befehl auch den Spiegel 
zerstören. Du solltest besser mehrere Backups mit verschiedenen Ständen 
haben.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für SQL Server gibt es "Fail Over Cluster".
Allerdings nicht für die Express Version. Das geht erst ab der Standard 
Version vom SQL Server.
Fail Over kann genau deine Anforderungen erfüllen - 2 Server mit dem 
selben Datenbestand und der 2. übernimmt, wenn der erste Probleme hat.
https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-2017

Autor: Tom (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
oszi40 schrieb:
> Tom schrieb:
>> irgendwie auf einem zweiten physischen Server zu spiegeln
>
> Wenn Du nur spiegelst, kann der gleiche Befehl auch den Spiegel
> zerstören. Du solltest besser mehrere Backups mit verschiedenen Ständen
> haben.

Hi
wie gesagt mir fällt da nix ein! Wie kriege ich es hin einen Server mit 
Backup so laufen zu lassen das wenn er mal ausfällt trotzdem jemand ohne 
viel Computer Ahnung ihn wieder zum laufen kriegt.

Autor: Ein Name (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Suchbegriff dazu ist auto failover.

Bei SQL Express findest du aber nur den Ratschlag - SQL Server 
High-Availability Solutions kaufen.

Selbst schreiben ist gar nicht so einfach. Sobald du in Urlaub bist, 
passiert irgend etwas, an das du nicht gedacht hast. Die 
Datenbankhersteller haben Jahrzehnte gebraucht, bis das bei allen Arten 
von Fehlern zuverlässig läuft.

Ein Vorschlag wäre: Anschauen wie die Mysql das macht und überlegen, ob 
du das für die SQL Express nachbauen willst.

Autor: Tom (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Danke!

Gibts da was von MySql also sprich kostenlos dann baue ich meine 
Datenbank einfach auf MySql um.

Autor: Tom (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ja das mit SQL Server kannte ich nur halt muss man da gut Geld für 
blechen. Reicht da überhaupt nur 1 Lizenz? Die kostet ja auch schon 
1000€

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Tom schrieb:
> Gibts da was von MySql also sprich kostenlos

Ja, gibt es. Bei MySQL kann einen man einen Slave-Server als Replikat 
des Masters laufen lassen. Der fährt die Operationen des Masters nach.

https://www.thomas-krenn.com/de/wiki/MySQL_Replikation

: Bearbeitet durch User
Autor: c.m. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Tom schrieb:
> oszi40 schrieb:
>> Tom schrieb:
>>> irgendwie auf einem zweiten physischen Server zu spiegeln
>>
>> Wenn Du nur spiegelst, kann der gleiche Befehl auch den Spiegel
>> zerstören. Du solltest besser mehrere Backups mit verschiedenen Ständen
>> haben.
>
> Hi
> wie gesagt mir fällt da nix ein! Wie kriege ich es hin einen Server mit
> Backup so laufen zu lassen das wenn er mal ausfällt trotzdem jemand ohne
> viel Computer Ahnung ihn wieder zum laufen kriegt.

garnicht. je nach dem was ausfällt, von netz über serverhardware, 
betriebssystem, datenbank software, oder von nutzern erzeugte 
datenzerstörung braucht man jemanden der das analysieren und 
entsprechend reagieren kann.
dafür gibts admins.

bei oracle heisst eine failover database übrigens shadow database 
(prinzipiell ein einpielen der archive logs in eine zweite datenbank), 
oder RAC.
da mysql von oracle übernommen wurde haben die dort vielleicht auch 
inzwischen andere begrifflichkeiten eingeführt.
wenn es mysql ohne oracle und ohne lizenskosten sein soll, dann ist 
deren fork mariadb wohl die erste wahl.

Autor: Tom (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vielen Dank für den Input hat mir schonmal sehr weitergeholfen!

Beitrag #5682995 wurde von einem Moderator gelöscht.
Beitrag #5683021 wurde von einem Moderator gelöscht.
Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Tom schrieb:
> Vielen Dank für den Input hat mir schonmal sehr weitergeholfen!

Nee, glaub' ich nicht. Einen sauberen HA-Cluster aufzusetzen, ist kein 
Kinderspiel und nicht mit einem Doppelklick auf Setup.EXE getan.

Das ganz unabhängig davon, ob man nun die mit Abstand leistungsfähigste 
OpenSource-Datenbank PostgreSQL benutzen will, MySQL oder seine Ableger 
MariaDB oder MaxSQL, Oracle, DB2, MSSQL oder whatever. Von mir aus DRBD 
zusammen mit <whatever>.

Was sind eigentlich ein Quorum oder ein Split-Brain? Nur so in den Raum 
gefragt. Die Replikation ist der einfachste Teil, spannend wird es mit 
Distributed Locking, Switch- und Failover, ... was davon ist in einem 
einfachen Master-Slave-Setup relevent, was vernachlässigbar? Was könnte 
dieses Ding mit dem Write-Ahead-Log sein?

Und dann: 200 MB? Wäre da nicht was anderes als ein RDBMS angemessen?

Welche Sicherheiten garantieren eigentlich RDBMS? Und wozu?

;-)

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sachte, lass ihn am Leben. ;-)

Vollautomatischer Failover scheint nicht erforderlich zu sein, manueller 
Failover reicht offenbar:

Tom schrieb:
> wenn er mal ausfällt trotzdem jemand ohne
> viel Computer Ahnung ihn wieder zum laufen kriegt.

Bei MySQL Replikation ist ein manueller Failover mit der Abschaltung des 
Masters und der Aktivierung einer sekundären IP-Adresse auf dem Slave 
erledigt. Das kriegt man per Script jedem beigebogen, der eine Tastatur 
bedienen kann. Notfalls bringt man der Hauskatze bei, ein Netzwerkkabel 
umzustecken.

Den Fallback kann er später selber machen, wenn er wieder da ist.

Nun kann er sich mal meinen Link oben anschauen und sich schläuen, ob 
das was für ihn sein könnte. Wenn ja, ist das kein Hexenwerk. Wenn er 
dann noch drauf achtet, die transaktionsfähige Engine zu verwenden, dann 
ist doch eine nicht sehr anspruchsvolle Sache.

: Bearbeitet durch User
Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Sachte, lass ihn am Leben. ;-)
>
> Vollautomatischer Failover scheint nicht erforderlich zu sein, manueller
> Failover reicht offenbar:
>
> Tom schrieb:
>> wenn er mal ausfällt trotzdem jemand ohne
>> viel Computer Ahnung ihn wieder zum laufen kriegt.
>
> Bei MySQL Replikation ist ein manueller Failover mit der Abschaltung des
> Masters und der Aktivierung einer sekundären IP-Adresse auf dem Slave
> erledigt. Das kriegt man per Script jedem beigebogen, der eine Tastatur
> bedienen kann. Notfalls bringt man der Hauskatze bei, ein Netzwerkkabel
> umzustecken.
>
> Den Fallback kann er später selber machen, wenn er wieder da ist.
>
> Nun kann er sich mal meinen Link oben anschauen und sich schläuen, ob
> das was für ihn sein könnte. Wenn ja, ist das kein Hexenwerk. Wenn er
> dann noch drauf achtet, die transaktionsfähige Engine zu verwenden, dann
> ist doch eine nicht sehr anspruchsvolle Sache.



Ja genau so habe ich mir das ganze vorgestellt, manueller Failover ist 
völlig ausreichend!

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Notfalls bringt man der Hauskatze bei, ein Netzwerkkabel
> umzustecken.

Irgendwelche Tips und Vorschläge dazu? :)

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert

: Bearbeitet durch User
Autor: stnv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MS SQL Server in der Express Version kann hier nicht viel. Er ist 
auch nicht unbedingt für solche Szenarien vorgesehen.

Die Spiegelung braucht mindestens eine Standard Version. Das muss aber 
auch die Anwendung mitmachen.

Mit einiges an scripten kann man eine SQL Express Version zum "Log 
Shipping" überzeugen. Damit kann man aber kein automatisches Failover 
umsetzen. Wenn die Datenbank mit ihren Daten bereits auf einem anderen 
Rechner "halb" läuft, kann man einiges an Zeit sparen.

Das ganze ist nicht ganz ohne...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
By the way: MySQL wurde durch MariaDB abgelöst - jedenfalls in der Welt 
jenseits von Oracle.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte in dieser Frage aber genauso funktionieren.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Tom schrieb:
>> Gibts da was von MySql also sprich kostenlos
>
> Ja, gibt es. Bei MySQL kann einen man einen Slave-Server als Replikat
> des Masters laufen lassen. Der fährt die Operationen des Masters nach.

Besser wäre Galera Cluster (von MariaDB oder Percona Server). Da ist die 
Replikation synchron, man kann auf beide (bzw. alle) Nodes im Cluster 
schreiben und ein Proxy ist auch schon dabei.

Backups braucht man aber natürlich trotzdem noch. Der Cluster schützt 
nur vor einem Hardware-Ausfall, nicht vor einer amoklaufenden Anwendung, 
einem Hack oder dem DBA, der im Tran wichtige Daten löscht.


https://github.com/wenerme/wener/blob/master/articles/High%20Availability%20Solutions%20for%20the%20MariaDB%20and%20MySQL%20Database.md
https://www.slideshare.net/MariaDB/mariadb-high-availability-81651161

: Bearbeitet durch User
Autor: TestX (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das Problem bei Cluster Lösungen ist der Administrationsaufwand.....kein 
normaler IT support kann soetwas wieder in Betrieb nehmen nach zB einem 
Stromausfall....außerdem braucht es bei Multisynchronen Setups min. 5HW 
Nodes...das ist wahrscheinlich weit von dem entfernt was der TO möchte..

@TO bleib bei deinem Setup und fertige eine Doku an wie man das Backup 
einspielt. Dann such dir eine fähige IT Firma für den Notfall..das ist 
der einzig gangbare Weg - alles andere übersteigt deine Ressourcen bei 
weitem

Autor: Nano (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Snapshots wären auch eine Lösung.

Wenn der DB Server ausfällt, einfach ein älteres Snapshot 
wiederherstellen.
Die Snapshots kann man auch in Intervallen automatisiert neu anlegen 
lassen.

Einen Datenverlust wird man in dem Fall aber dennoch haben, da ein 
Snapshot genau wie ein Backup auch, nur einen älteren Zustand der 
Datenbank wiederherstellen würde.
Will man neu hinzukommende Daten sichern, dann muss man bevor man zu 
einem älteren Sanpshot zurückgeht, die irgendwie wegsichern und dann 
manuell einpflegen.

Für Snapshots eignet sich ein Dateisystem wie ZFS.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> Snapshots wären auch eine Lösung.

Wie man ohne IT Kompetenz kaputte Hardware mit Snapshots wieder ganz 
macht, wäre dann aber noch zu klären.

Autor: Keep it simple and stupid (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> wäre dann aber noch zu klären.

Die Entwicklung der vergangenen Jahrzehnten ist total in die falsche 
Richtung gegangen. Wir haben tolle Cluster-Systeme, die niemand mehr 
korrekt konfigurieren und hochfahren kann.

Besser wäre, die Backup-Mechanismen stellen einfach eine konsistente 
Festplatte mit Betriebssystem, Programmen und aktuellen Daten zusammen. 
Wenn der Rechner nicht mehr funktioniert, einfach Platte raus ziehen und 
Backup-Platte rein schieben.

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keep it simple and stupid schrieb:
> Besser wäre, die Backup-Mechanismen stellen einfach eine konsistente
> Festplatte mit Betriebssystem, Programmen und aktuellen Daten zusammen.
> Wenn der Rechner nicht mehr funktioniert, einfach Platte raus ziehen und
> Backup-Platte rein schieben.

Nutzt aber nix, wenn der Fehler jenseits der Software oder Festplatte 
liegt...

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Keep it simple and stupid schrieb:
> Die Entwicklung der vergangenen Jahrzehnten ist total in die falsche
> Richtung gegangen. Wir haben tolle Cluster-Systeme, die niemand mehr
> korrekt konfigurieren und hochfahren kann.

Ach?

Tatsächlich hat sich die Sache in der betrieblichen Praxis wesentlich 
vereinfacht. Etliche Cluster von PC-Servern wurden durch Virtualisierung 
abgelöst. Redundante VM-Hosts ersetzen diverse Individuallösungen 
früherer ressourcenfressender Hardware-Cluster. Viel Knowhow braucht das 
nicht - beim Storage-Cluster evtl schon, aber das brauchte man vorher 
auch schon.

(1) In vielen Fällen reicht es bereits aus, wenn beim Crash eines Hosts 
die VMs auf den anderen Hosts neu gestartet werden. Der Service ist 
wenige Minuten weg und muss dafür nur aus einem VM-Crash heraus neu 
starten können. Spart zudem an Lizenzen und redundanter Hardware.

(2) Reicht das nicht, kann man einen sekundären Server als permanent 
bzgl RAM synchronisiertes Replikat auf einem anderen Host betreiben. 
Fliegt der Host des ersten weg, übernimmt das Replikat fliegend.

In einer solchen Umgebung sind automatisch alle Server durch (1) gegen 
HW-Ausfall abgedeckt, ein paar besonders zeitkritische evtl durch (2). 
Egal was für Server das sind, mit egal welchem Betriebssystem. Ein 
Knowhow für alles.

Unabhängig davon gibt es weiterhin recht umgängliche Lösungen innerhalb 
der Applications. MySQL/MariaDB Varianten wurden bereits genannt. 
Microsoft Exchange repliziert die DB selbst, Active Directory und DHCP 
ebenso.

: Bearbeitet durch User
Autor: Nano (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Nano schrieb:
>> Snapshots wären auch eine Lösung.
>
> Wie man ohne IT Kompetenz kaputte Hardware mit Snapshots wieder ganz
> macht, wäre dann aber noch zu klären.

Ah sorry, habe das gestern Nacht nicht richtig gelesen.
Dachte es ging nur um den Datenbankserver wenn dieser als Software 
Probleme macht.

Wenn die HW ausfällt, dann ist das natürlich nicht mehr so einfach.
Aber hier könnte man die Snapshots auf einem NAS machen.
Den Datenbankserver auf eigener HW und die Daten kann man dann per nfs 
einbinden oder kopieren.
Fällt der erste DBS aus, dann könnte ein anderer einspringen und die 
Daten vom NAS per nfs einbinden.
Falls die Daten auf dem NAS wegen dem ersten DBS kaputt sind, kommt der 
Snapshot ins Spiel.
Das ganze ist natürlich etwas komplizierter und es bräuchte wirklich 
einen Admin, der erst einmal analysisert, was genau kaputt ist.
Umsonst gibt es da nichts.

Insofern, wie wäre es mit ssh und Remoteadministration wenn man vor Ort 
nicht da sein kann?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Wenn die HW ausfällt, dann ist das natürlich nicht mehr so einfach.
> Aber hier könnte man die Snapshots auf einem NAS machen.

Damit verschiebst du die Verfügbarkeitsfrage vom DB-Server auf ein 
hochverfügbares NAS.

Mal ehrlich: Ist das einfacher als eine simple MariaDB-Replikation? Die 
hatte ich schon. Ist nicht weiter kompliziert und x-fach beschrieben. 
Der Fallback geht halt nur offline, weil dabei ein Backup der Slave-DB 
zurück kopiert werden muss, aber 200 MB sind Pillepalle.

> Das ganze ist natürlich etwas komplizierter und es bräuchte wirklich
> einen Admin, der erst einmal analysisert, was genau kaputt ist.
> Umsonst gibt es da nichts.

Exakt. Also nix für die Hauskatze. Die ist aber Vorgabe.

Bei der vorgeschlagenen Replikation muss man nur die IP-Adresse der 
Funktion übernehmen. Was manuell problemlos ist, weil man split brain 
nicht berücksichtigen muss, sondern ganz banal auf STONITH per Hauskatze 
setzt.

Wenn man sich die DB zerlegt hat und deshalb nichts mehr geht, dann 
hilft das natürlich nicht. Aber dafür einen katzentauglichen Weg zu 
finden, ohne sich der konkreten Anwendung zu nähern, dürfte im privaten 
Umfeld schwierig sein.

: Bearbeitet durch User
Autor: Nano (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Nano schrieb:
>> Wenn die HW ausfällt, dann ist das natürlich nicht mehr so einfach.
>> Aber hier könnte man die Snapshots auf einem NAS machen.
>
> Damit verschiebst du die Verfügbarkeitsfrage vom DB-Server auf ein
> hochverfügbares NAS.

Ja, das ist richtig.
Man müsste noch Redundanz einbauen und zwei NAS vorhalten.

Dann kann man sowohl HW Fehler als auch Softwarefehler schnell 
ausgleichen.
Aber die Analyse gehört trotzdem dazu, denn man muss ja wissen, wenn 
etwas mit der Software schief läuft, nicht das man mit kaputten Daten 
weiterarbeitet.

Durch die redundante HW wäre es aber zumindest administrativ per remote 
Zugang lösbar.



>
> Mal ehrlich: Ist das einfacher als eine simple MariaDB-Replikation? Die
> hatte ich schon. Ist nicht weiter kompliziert und x-fach beschrieben.
> Der Fallback geht halt nur offline, weil dabei ein Backup der Slave-DB
> zurück kopiert werden muss, aber 200 MB sind Pillepalle.

Backups haben halt das Problem, dass sie vielleicht nicht regelmäßig 
gemacht werden, dann hat man einen sehr alten Datenbestand der 
Datenbank.
Die Snapshots lassen sich automatisieren und bspw. auch stündlich 
machen.
Die Backups nur, wenn man die HW nicht abklemmt, aber dann ist das kein 
Backup mehr, da ein Backup streng genommen erst dann ein Backup ist, 
wenn im Falle eines Befalls von Schadsoftware des Servers das Backup 
davon nicht betroffen ist, also abgeklemmt wurde.
Eine Platte die dauerhaft dranhängt, selbst wenn sie die Daten spiegelt, 
kann somit kein Backup sein. Im Prinzip hat man dann damit dann sowieso 
so etwas wie ein NAS, nur eben in billig.
Insofern kann man auch gleich zwei externe NAS nehmen und Snapshots 
nutzen.
Backups ersetzen die allerdings auch nicht, aber ein Großteil der 
Crashszenarien wie HW Ausfall usw. kann man damit abdecken.

Das Zurückspielen aus einem Backup ist einfach, da stimme ich zu.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Das Zurückspielen aus einem Backup ist einfach, da stimme ich zu.

Kommt drauf an, ob man Ahnung hat, es an die richtige Stelle spielt UND 
es aktuell genug ist. Die Messwerte von Weihnachten bis heute könnten 
z.B. schon fehlen?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
>> Mal ehrlich: Ist das einfacher als eine simple MariaDB-Replikation? Die
>
> Backups haben halt das Problem,

Diese Replikation hat im Betrieb nichts mit einem Backup zu tun. Der 
Master liefert dem Slave (in der ursprünglichen Version) permanent und 
live alle relevanten SQL Statements, und der vollzieht sie ebenso live 
auf seiner eigenen DB nach.

Einen Backup - was dann auch eine offline Kopie des Filesystems sein 
kann - braucht man nur beim Fallback, also zurück von Slave auf Master. 
Und bei der Einrichtung der Replikation.

Nebenbei: Einen Bezug zum Backup gibts nur andersrum: Dieser 
Replikations-Mechanismus wird ggf auch für point in time recovery 
verwendet. Man hebt die binlogs dieses Verfahrens seit der letzten 
Vollsicherung auf. Vollsicherung plus binlogs = letzter Stand.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine automatische Verifikation der Replikation ist einfach: Man setzt 
einen Query sowohl auf den Master als auch auf den Slave ab (über die 
Node-IP vom Slave statt der Funktions-IP) und erfragt irgendeinen Wert, 
der den letzten Stand des Inhalts beschreibt. Idealerweise ist das eine 
Timestamp. Liegen die mehr als ein paar Sekunden auseinander, könnte man 
ein Problem haben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.