• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Frage zu ZFS/RAIDZ: Kommt es auf die Anschlussreihenfolge der Festplatten beim Wiedereinbau an?

pit234a

Well-Known Member
#28
"Frage zu ZFS/RAIDZ: Kommt es auf die Anschlussreihenfolge der Festplatten beim Wiedereinbau an?"

Das hab ich mir nicht ausgedacht, das ist das Thema dieses Threads!

Ich bin ja wahrlich nicht einer, der sich gegen Diskussionen stellt, wenn diese sich eben in Folge einer Frage ergeben, aber es fällt mir einfach schwer, den Argumenten zu folgen und vor allem, die wieder zu finden, wenn man so weit abweicht und dabei auch gerade aktuelle Themen in anderen Beiträgen streift.

Zurück: es kommt nicht auf die Reihenfolge an, ZFS macht das automagisch korrekt.
Ich finde trotzdem, dass man einfach die Reihenfolge einhalten sollte, wenn immer das möglich ist. Weil man eh die Platten markiert und weiß, welche wo war und deshalb wohin gehört.

Und, was soll man da noch mehr sagen?

Ich empfinde diesen Thread deshalb eigentlich für beendet.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#31
Mal ketzerisch, vielleicht auch weil ich über die Jahre einfach zu viel MySQL-Missbrauch gesehen habe: MySQL und MariaDB sind seit unvergesslich katastrophalen MySQL 4.x Tagen wesentlich besser geworden. Nicht zuletzt auch, weil erst Sun und später Oracle, sowie die MariaDB Corporation da richtig reingebuttert haben. Und definitiv für MySQL und MariaDB spricht, dass sie sowohl für Entwickler, als auch Admins sehr leicht handhabbar sind. Sie verzeihen auch grobe Fehler, bis hin zu reinem Schwachsinn. Aber auch die Konkurrenz ist wesentlich besser geworden. Für die meisten kleinen Anwendungen, die mit nur einer Instanz laufen und einfach eine Datenbank brauchen, ist sqlite oft die bessere Wahl. Und für alles, was mehr Datenbank benötigt, kann man auch gleich PostgreSQL nehmen.
 

Azazyel

Well-Known Member
#32
OK, dann anders gefragt: Bis zu welcher Unternehmens/Organisationsgröße kann man mit mysql ausreichend fahren?
Würdest du heute anfangen zu wachsen, wäre die Skalierbarkeit einer einzigen SQL-Datenbankinstanz nicht dein limitierender Faktor. Aus historischen Gründen sieht das bei manchen Unternehmen anders aus.
Oracle war 1979 (2 Jahre vor dem ersten PC) die erste kommerziell verfügbare relationale Datenbank überhaupt. Hardware war irrwitzig langsam und teuer. Viele Unternehmen sind mit Oracle groß geworden und haben sich eine riesige Anwendungslandschaft rund um (eine) zentrale Oracle-Datenbank(en) aufgebaut. Die Anwendungen bauen teilweise sehr intensiv auf Oracle-Features auf, die lange vor einer Standardisierung von SQL entstanden sind und nur mit massivem Aufwand auf andere Datenbanken übertragbar wären.

In Oracle sind im Laufe der Zeit unglaubliche viele Ressourcen geflossen, wodurch im Laufe der Zeit ein ebenso hochperformantes wie kompliziertes Stück Software entstanden ist.

Rückblickend würde man es natürlich anders machen, aber hinterher ist man immer schlauer.
Heutzutage würdest du dir keine zentrale Datenbank mit dutzenden direkt darauf zugreifenden Anwendungen mehr aufbauen, die permanent ein Flaschenhals werden kann. Du würdest - je nach Anwendungsfall - eine Datenbank pro Anwendung nutzen, andere Architektur-Pattern verwenden, dich aus dem großen Fundus der NoSQL-Datenbanken bedienen und vieles mehr.

Wenn du mit moderner Hardware und MariaDB/PostgreSQL (letzteres würde ich bevorzugen) mit einem sauberen Datenmodell in Performance-Grenzen läufst, die man nicht mehr mit Wald-und-Wiesen-Maßnahmen wie Query-Optimierung und Indizes in den Griff kriegst, dann - Gratulation! Dein Laden läuft so gut, dass du auch entsprechend Ressourcen in die Hand nehmen kannst, um deine Anwendung(en) jenseits der Grenzen einer SQL-Datenbankinstanz zu skalieren.
 

medV2

Well-Known Member
#33
Würdest du heute anfangen zu wachsen, wäre die Skalierbarkeit einer einzigen SQL-Datenbankinstanz nicht dein limitierender Faktor. Aus historischen Gründen sieht das bei manchen Unternehmen anders aus.
Oracle war 1979 (2 Jahre vor dem ersten PC) die erste kommerziell verfügbare relationale Datenbank überhaupt. Hardware war irrwitzig langsam und teuer. Viele Unternehmen sind mit Oracle groß geworden und haben sich eine riesige Anwendungslandschaft rund um (eine) zentrale Oracle-Datenbank(en) aufgebaut. Die Anwendungen bauen teilweise sehr intensiv auf Oracle-Features auf, die lange vor einer Standardisierung von SQL entstanden sind und nur mit massivem Aufwand auf andere Datenbanken übertragbar wären.

In Oracle sind im Laufe der Zeit unglaubliche viele Ressourcen geflossen, wodurch im Laufe der Zeit ein ebenso hochperformantes wie kompliziertes Stück Software entstanden ist.

Rückblickend würde man es natürlich anders machen, aber hinterher ist man immer schlauer.
Heutzutage würdest du dir keine zentrale Datenbank mit dutzenden direkt darauf zugreifenden Anwendungen mehr aufbauen, die permanent ein Flaschenhals werden kann. Du würdest - je nach Anwendungsfall - eine Datenbank pro Anwendung nutzen, andere Architektur-Pattern verwenden, dich aus dem großen Fundus der NoSQL-Datenbanken bedienen und vieles mehr.

Wenn du mit moderner Hardware und MariaDB/PostgreSQL (letzteres würde ich bevorzugen) mit einem sauberen Datenmodell in Performance-Grenzen läufst, die man nicht mehr mit Wald-und-Wiesen-Maßnahmen wie Query-Optimierung und Indizes in den Griff kriegst, dann - Gratulation! Dein Laden läuft so gut, dass du auch entsprechend Ressourcen in die Hand nehmen kannst, um deine Anwendung(en) jenseits der Grenzen einer SQL-Datenbankinstanz zu skalieren.
Da stimmt natürlich viel, aber auch eine Postgres ( die ich SEHR schätze ) hat erst in den letzten Jahren ordentlich Boden gutgemacht.

Und in einigen Dingen kann sie nicht mit Oracle oder auch DB2 mithalten. Master/Master Setups, oder allgemein Cluster über RZ Grenzen hinweg. Und das ist sicher nur die Spitze, aus dem Grund hab ich damit zu tun.
Natürlich kann ich alles irgendwie hinbiegen. Aber auch als Anwendungsentwickler freue ich mich auf eine Plattform auf die ich mich stützen kann, und ich zum Kunden sagen kann "nimm DB XY und alles wird gut" und ich nicht darauf vertrauen muss, dass der Kunde brauchbares IT Personal hat.