Von Verfluchtnochmal_5987108 am Fr, 22. Mai 2020 um 20:32 #
Immer noch lächerlicher Dreck im Hinblick das ich hier aktuelle mariadb Instanzen habe die auf mysql 3.x Anfang des Jahrtausends zurück gehen ohne solch Kasperletheater
.6.2. Upgrading Data via pg_upgrade
The pg_upgrade module allows an installation to be migrated in-place from one major PostgreSQL version to another. Upgrades can be performed in minutes, particularly with --link mode. It requires steps similar to pg_dumpall above, e.g. starting/stopping the server, running initdb. The pg_upgrade documentation outlines the necessary steps.
Von Verfluchtnochmal_5987108 am Sa, 23. Mai 2020 um 12:41 #
In einer Kindergarten IT die seit 12 Jahren ohne neu aufsetzen für knapp 1000 Kunden ihren Dienst tut und wo keine Schwachköpfe rumlaufen die mit 2 jährlichen dist-upgrades überfordert sind
Was sagt das aus, sind das Professionelle, wohl kaum sonst würden Sie nicht Dich brauchen. Auch für DAUs kann man eine "Kindergarten IT" anbieten und keiner merkt was.
Ansonsten gäbe auch keine Manager die ihre IT Ausrüstung im Media Markt hollen und dann sich wundern, das es kaum Support gibt, wenn die Bürorechner nicht mehr richtig laufen wollen.
Wenn ich das lese was Du von Dir gibst, bezweifle ich mal an Deiner Kompetenz. In einer Sicherheitsumgebung wird kein Fendora eingesetzt, eher Debian, Free- oder OpenBSD, wer dabei auf ein BS aus einem Rolling Release setzt, muß schon wahnsinnig sein oder wenig Kompetenz besitzen. Zeig' mir mal andere Software aus dem Bereich, bei der das so gemacht wird, wie bei Dir.
Ich muß mir nur mal die Sicherheitsmeldungen anschauen, dort taucht fast täglich Fendora mit einer Meldung auf. Also bestimmt kein zuverlässiges System, für eine solche Anwendung.
Von Verfluchtnochmal_5987108 am Do, 28. Mai 2020 um 11:57 #
Was kann Fedora für die Schwachsinnigkeit von Pro-Linux sich bei Sicherheitslücken eines Pakets eine Distribution aus dem Arsch zu ziehen auf dass lustige wie du glauben Fedora hätte die bugs in die upstream Software extra rein gepatcht
Kritisiert wird der „Zwang zum Update“ nach spätestens 13 Monaten und die zu häufigen Updates. Dies garantiert zwar jederzeit sehr aktuelle Software, bringt aber auch viele Änderungen mit sich und der langfristige Support fehlt. Wikipedia
Die idealen Vorraussetzungen für ein BS bei einem produktiven System, wie einer Firewall.
Von Verfluchtnochmal_5987108 am Fr, 29. Mai 2020 um 18:16 #
Mag für jemanden der keinen blassen Dunst hat was eine Firewall ist so erscheinen! Das einzige was die Kiste braucht sind 2 Netzwerkanschlüsse, eine shell und ein iptables ruleset
Was genau soll denn da ein Update kaput machen?
Simpler Reboot wie bei einem ordinären Kernel update und nach 5 bis 10 Sekunden ist alles wieder da... schulterzuck
Von Verfluchtnochmal_5987108 am Fr, 29. Mai 2020 um 18:17 #
Abgesehen davon erzähl deinen Nachbarn was über Fedora dist-upgrades und nicht jemandem der auf seinen Servern 22 in Folge mit maximal 25 Sekunden Downtime gemacht hat
Das glaubt Dir keiner! Du bist ein agressiver schwachkopf der wohl zu fachartzt gehen sollte (wegen deinen eingebildeten Kunden und deiner autoagression)
Einer der positiven Aspekte des nahenden Endes von Pro-Linux ist, dass ich deine selbstgerecht-aggressiven, überflüssigen und uninteressanten Ergüsse nicht mehr sehen muss.
mysql hatte dafür um 2006 rum deutlich weniger funktionen als pgsql (z.B. pl/sql). pgsql hat eher den anspruch an das grosse vorbild oracle. ob das aktuell noch gültig ist weis ich nicht.
und wenn wir von lächerlichem "kasperltheater" im datenbankumfeld reden - schau was oracle macht, dagegen ist pgsql eine 3minuten sache - fertig
allein das thema korrekte oracle-lizensierung einer standard-edition in virtualisierten esx-umgebungen kann einem als neuling tage recherche kosten.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 23. Mai 2020 um 13:11.
Beide Datenbanken habe ihre Daseinsberechtigung. Wenn ich eine webapp nutzen würde wo es täglich 100 Tausende User gibt die sich anmelden wollen, würde ich mariadb nehmen. Jedoch wenn ich komplizierte BI SQL Querys mache, dann bevorzuge ich definitiv Postgress. Also ich liebe bei Systeme
Von Verfluchtnochmal_5987108 am Mi, 27. Mai 2020 um 17:29 #
Und du hast ein Problem dein Halbwissen von vor 20 Jahren zu aktualisieren! PHP 7.4/8.0 haben mit damals wenig zu tun und welche Programmiersprache soll das sein die nicht mit MySQL reden kann?
ich vermute das problem hast du bei pgsql bis heute.
im oracle-umfeld ist das nichts anderes: der saubere weg ist ein export und reimport. klar gibt es auch andere möglichkeiten - diese benötige aber entsprechende vorbereitungen.
wobei ich das auch für vertretbar halte: ein dist-upgrade muss ich so oderso vorbereiten, im zweifel setze ich tendenziell eher ein neues system auf, und switche. Aber gut - ich habe auch keine 1000 kundensysteme zu betreuen, selbst die 1000 mitarbeiter sind _weit_ entfernt
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 24. Mai 2020 um 20:52.
Von Verfluchtnochmal_5987108 am Mo, 25. Mai 2020 um 01:39 #
Bevor ich ein System neu aufsetze bohre ich mir ein Loch ins Knie, die Vorbereitung eines dist-upgrades sind genauso trivial als das dist-upgrade selbst
Nicht umsonst wurden hier alle Systeme 2008 mit Fedora 9 installiert und laufen aktuell auf Fedora 31, das letzte Upgrade war in einem halben Tag durch vom Router bis zum letzten Webserver
Würd ich ganz sicher so nicht machen (insbesondere nicht bei externen kundensystemen), wir setzen bewusst auf Oracle Enterprise-Linux mit 10Jahre+ Support. Ich installiere lieber die 20 Produktiv-Systeme alle 10Jahre manuell neu auf, als mir durch ein Distupgrade irgendwelche Probleme ans Land zu ziehen, und wenns am ende an einer externen Lib liegt die nicht mehr kompatibel ist pp. etc.
Unter SuSE hatte ich Beispielsweise vor Jahren eine "falsch" cpu-optimierte unixodbc-version so das sporadisch crashs bei sql-querys auf einer db2 (db2 treiber kam von ibm) kam. Die Fehlerursache war nur schwer zu eruieren, mit einem recompile der srpm auf i386 basis liefs dann stabil. Ubuntu kam vor Jahren mit defekten XEN-Kernel-Support, so das die VMs sporadisch crashten....
Aber sicher wirst Du bei Deinem Setting genau wissen was Du machst !
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 25. Mai 2020 um 02:04.
Von Verfluchtnochmal_5987108 am Mo, 25. Mai 2020 um 03:11 #
Und wo sind das externe Systeme? Mensch wir kennen das Zeug in und auswendig und mit einem softwarestack der 5 Jahre oder älter ist kannst du mich jagen
Anyways, nach 12 Jahren und 22 dist-upgrades ist die einzige Erklärung die ich für Probleme anderer habe Unfähigkeit kombiniert mit externen Dependencies
Dafür das du hier so oft auf die Kake gehauen hast, finde ich ziemlich erbärmlich das du keine LTS Distri im Produktivumfeld nutzt, sondern jedes halbe Jahr unnötige Risiken eines dist-upgrade eingehst. Im Professionellen Umfeld hättest du mit dieser Herangehensweise keine Chance zu bestehen.
Von Verfluchtnochmal_5987108 am Mo, 25. Mai 2020 um 23:41 #
Well, wenn du Professionalität mit 10 Jahre den Finger in den Arsch stecken verwechselst und so wenig Ahnung von dem hast was du tust dass ein triviales dist-upgrade für dich ein Risiko ist mag das so sein
Deshlab hat er was gegen postgres, er ubgradete ausversehen sein fedora (mit db) und war dann sauer das postgres nicht mehr lief, tja wer nicht lesen kann ist nicht nur mit fedora klar im nachteil.
Von Verfluchtnochmal_5987108 am Mi, 27. Mai 2020 um 17:32 #
Im Gegensatz zu dir kleinem Trottel testen wir hier Updates in dem wir die auf klonen laufen lassen und dieses PostgreSQL Verhalten hat mich davon abgehalten es jemals benutzen zu wollen eben weil ich lesen kann
Von Verfluchtnochmal_5987108 am Do, 28. Mai 2020 um 11:52 #
Klar, aber ich bin sicher nicht so dumm hier einen Firmennamen zu nennen auf dass wieder irgendein Trottel bei Kunden anruft mit "mimimimi der war böse zu mir"
Wenn das Dein Problem ist würde ich mal Deine Einstellung überdenken, wie Du Dich anderen gegenüber gibst. Vorallem das schwachsinnigste Argument, das ich je gehört habe.
Immer noch lächerlicher Dreck im Hinblick das ich hier aktuelle mariadb Instanzen habe die auf mysql 3.x Anfang des Jahrtausends zurück gehen ohne solch Kasperletheater
.6.2. Upgrading Data via pg_upgrade
The pg_upgrade module allows an installation to be migrated in-place from one major PostgreSQL version to another. Upgrades can be performed in minutes, particularly with --link mode. It requires steps similar to pg_dumpall above, e.g. starting/stopping the server, running initdb. The pg_upgrade documentation outlines the necessary steps.
Das passt ja zu Dir, mysql und fedora, will ja gar nicht wissen in was fuer einer kindergarten IT du arbeitest...
In einer Kindergarten IT die seit 12 Jahren ohne neu aufsetzen für knapp 1000 Kunden ihren Dienst tut und wo keine Schwachköpfe rumlaufen die mit 2 jährlichen dist-upgrades überfordert sind
Ansonsten gäbe auch keine Manager die ihre IT Ausrüstung im Media Markt hollen und dann sich wundern, das es kaum Support gibt, wenn die Bürorechner nicht mehr richtig laufen wollen.
Reines b2b, Schwachköpfe wie du will man nicht als Kunde wenn man sich aussuchen kann was man machen will und mit wem
Ich muß mir nur mal die Sicherheitsmeldungen anschauen, dort taucht fast täglich Fendora mit einer Meldung auf. Also bestimmt kein zuverlässiges System, für eine solche Anwendung.
Was kann Fedora für die Schwachsinnigkeit von Pro-Linux sich bei Sicherheitslücken eines Pakets eine Distribution aus dem Arsch zu ziehen auf dass lustige wie du glauben Fedora hätte die bugs in die upstream Software extra rein gepatcht
Geht das auch in verständlichem Deutsch?
Was verstehst du kleiner Trottel nicht? Nichts auf der Liste ist Fedora spezifisch
Zu deppat zu wissen was ein rolling release eigentlich ist und zu deppat Fedora zu schreiben aber von Kompetenz sprechen
Die idealen Vorraussetzungen für ein BS bei einem produktiven System, wie einer Firewall.
Mag für jemanden der keinen blassen Dunst hat was eine Firewall ist so erscheinen! Das einzige was die Kiste braucht sind 2 Netzwerkanschlüsse, eine shell und ein iptables ruleset
Was genau soll denn da ein Update kaput machen?
Simpler Reboot wie bei einem ordinären Kernel update und nach 5 bis 10 Sekunden ist alles wieder da... schulterzuck
Abgesehen davon erzähl deinen Nachbarn was über Fedora dist-upgrades und nicht jemandem der auf seinen Servern 22 in Folge mit maximal 25 Sekunden Downtime gemacht hat
Das glaubt Dir keiner! Du bist ein agressiver schwachkopf der wohl zu fachartzt gehen sollte (wegen deinen eingebildeten Kunden und deiner autoagression)
Einer der positiven Aspekte des nahenden Endes von Pro-Linux ist, dass ich deine selbstgerecht-aggressiven, überflüssigen und uninteressanten Ergüsse nicht mehr sehen muss.
Ich dachte, dass genau dafür die Plattform archiviert wird.
mysql hatte dafür um 2006 rum deutlich weniger funktionen als pgsql (z.B. pl/sql). pgsql hat eher den anspruch an das grosse vorbild oracle. ob das aktuell noch gültig ist weis ich nicht.
und wenn wir von lächerlichem "kasperltheater" im datenbankumfeld reden - schau was oracle macht, dagegen ist pgsql eine 3minuten sache - fertig
allein das thema korrekte oracle-lizensierung einer standard-edition in virtualisierten esx-umgebungen kann einem als neuling tage recherche kosten.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 23. Mai 2020 um 13:11.Beide Datenbanken habe ihre Daseinsberechtigung. Wenn ich eine webapp nutzen würde wo es täglich 100 Tausende User gibt die sich anmelden wollen, würde ich mariadb nehmen. Jedoch wenn ich komplizierte BI SQL Querys mache, dann bevorzuge ich definitiv Postgress. Also ich liebe bei Systeme
Ich habe halt ein Problem mit Software die Daten welche sie selbst geschrieben hat nicht ohne Händchen halten lesen kann
Nein Du hast probleme eine andere sprache zu lernen wie php..deshalb auch deine mysql verliebtheit...bastler halt
Und du hast ein Problem dein Halbwissen von vor 20 Jahren zu aktualisieren! PHP 7.4/8.0 haben mit damals wenig zu tun und welche Programmiersprache soll das sein die nicht mit MySQL reden kann?
2006 warst du halt der gefickte nach einem dist-upgrade weil ohne dump/restore gar nichts ging und du den dump vorher machen musstest
Da wo ich herkomme werden für upgrades Dienste nicht vom Netz genommen
ich vermute das problem hast du bei pgsql bis heute.
im oracle-umfeld ist das nichts anderes: der saubere weg ist ein export und reimport. klar gibt es auch andere möglichkeiten - diese benötige aber entsprechende vorbereitungen.
wobei ich das auch für vertretbar halte: ein dist-upgrade muss ich so oderso vorbereiten, im zweifel setze ich tendenziell eher ein neues system auf, und switche. Aber gut - ich habe auch keine 1000 kundensysteme zu betreuen, selbst die 1000 mitarbeiter sind _weit_ entfernt
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 24. Mai 2020 um 20:52.Bevor ich ein System neu aufsetze bohre ich mir ein Loch ins Knie, die Vorbereitung eines dist-upgrades sind genauso trivial als das dist-upgrade selbst
Nicht umsonst wurden hier alle Systeme 2008 mit Fedora 9 installiert und laufen aktuell auf Fedora 31, das letzte Upgrade war in einem halben Tag durch vom Router bis zum letzten Webserver
Würd ich ganz sicher so nicht machen (insbesondere nicht bei externen kundensystemen), wir setzen bewusst auf Oracle Enterprise-Linux mit 10Jahre+ Support.
Ich installiere lieber die 20 Produktiv-Systeme alle 10Jahre manuell neu auf, als mir durch ein Distupgrade irgendwelche Probleme ans Land zu ziehen, und wenns am ende an einer externen Lib liegt die nicht mehr kompatibel ist pp. etc.
Unter SuSE hatte ich Beispielsweise vor Jahren eine "falsch" cpu-optimierte unixodbc-version so das sporadisch crashs bei sql-querys auf einer db2 (db2 treiber kam von ibm) kam. Die Fehlerursache war nur schwer zu eruieren, mit einem recompile der srpm auf i386 basis liefs dann stabil.
Ubuntu kam vor Jahren mit defekten XEN-Kernel-Support, so das die VMs sporadisch crashten....
Aber sicher wirst Du bei Deinem Setting genau wissen was Du machst !
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 25. Mai 2020 um 02:04.Natürlich weiß ich genau was ich mache, was ich allerdings nicht weiß von welchen externen Kundensystemen du sprichst
Meine Server, meine Software, meine Binaries, meine switches, meine Router, mein Hardware und Software stack
SaaS
ich meinte gelesen zu haben das ihr 1000 Kundensysteme betreibt.
Du solltest richtig lesen! Wir kosten knapp 1000 Kunden auf UNSEREN Systemen
das hatte ich so gemeint ...
Und wo sind das externe Systeme? Mensch wir kennen das Zeug in und auswendig und mit einem softwarestack der 5 Jahre oder älter ist kannst du mich jagen
Anyways, nach 12 Jahren und 22 dist-upgrades ist die einzige Erklärung die ich für Probleme anderer habe Unfähigkeit kombiniert mit externen Dependencies
Schlaf wird überbewertet
Dafür das du hier so oft auf die Kake gehauen hast, finde ich ziemlich erbärmlich das du keine LTS Distri im Produktivumfeld nutzt, sondern jedes halbe Jahr unnötige Risiken eines dist-upgrade eingehst. Im Professionellen Umfeld hättest du mit dieser Herangehensweise keine Chance zu bestehen.
Well, wenn du Professionalität mit 10 Jahre den Finger in den Arsch stecken verwechselst und so wenig Ahnung von dem hast was du tust dass ein triviales dist-upgrade für dich ein Risiko ist mag das so sein
Deshlab hat er was gegen postgres, er ubgradete ausversehen sein fedora (mit db) und war dann sauer das postgres nicht mehr lief, tja wer nicht lesen kann ist nicht nur mit fedora klar im nachteil.
Im Gegensatz zu dir kleinem Trottel testen wir hier Updates in dem wir die auf klonen laufen lassen und dieses PostgreSQL Verhalten hat mich davon abgehalten es jemals benutzen zu wollen eben weil ich lesen kann
Gibt es auch eine Möglichkeit, Deine Softwarelösungen mal anzusehen, oder ist das nur einem ausgewählten Kreis vorbestimmt?
Klar, aber ich bin sicher nicht so dumm hier einen Firmennamen zu nennen auf dass wieder irgendein Trottel bei Kunden anruft mit "mimimimi der war böse zu mir"
Wenn das Dein Problem ist würde ich mal Deine Einstellung überdenken, wie Du Dich anderen gegenüber gibst. Vorallem das schwachsinnigste Argument, das ich je gehört habe.